--- Log for 26.03.110 Server: verne.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 2 hours ago 00.01.08 # okay, how long would the translations stuff take? 00.01.13 # Probably not too long 00.01.19 # ender`: http://amiconn.dyndns.org/~jens/rockbox-aweb.png 00.01.59 # New commit by 03funman (r25336): Make storage alignement use cache alignement macros ... 00.03.02 # xiainx: maybe you can split the rest of the summer into different improvements for existing services. But make sure to pick specific tasks :-) 00.03.30 # yeah, so what exactly has to be fixed with the translations? 00.03.44 # New commit by 03funman (r25337): Accept expressions in CACHE_OVERLAP() macro 00.05.39 # xiainx: for the core translations i am not really sure what needs fixing, maybe you should try it a bit, and see if you find something missing ? :-) 00.06.13 # Okay, so some testing and bug fixing 00.06.28 # for example i think there is no way to start a new translation for languages not already existing in rockbox 00.07.09 # and ofcourse the rbutil transaltions, bluebrother should be able to tell you more about that :-) 00.07.18 Join funman [0] (~fun@rockbox/developer/funman) 00.07.27 # I would like to discuss about what to do this summer as a project i have 2 ideas in mind 1. Audio codec optimisation or 2. Improved video playback 00.07.42 # i am not able to decide which one to do.. 00.08.06 # RoronoaZoro: nice, do you have expirience in this area ? 00.08.38 # amiconn: if we're going exotic: http://eternallybored.org/imgs/old/rockbox1.png :) 00.09.13 # I know C and Assembly on x86 and DSP... not much in Audio/Video Codec Theory. 00.09.38 # apps/plugins/mpegplayer.c:862 : i'm not sure why an uncached address is used there 00.10.00 # could it be that the buffer is shared between CPU & COP ? 00.10.07 # well, the basic code for rbutil translation is dead simple. It's less than 200 LOC right now, and the most time I've spent was to understand how the simplexml in php works 00.10.38 # i had talked to saratoga about it he said i could read about MDCT and FFT and i have done that part but i am still not able to decide on one 00.11.42 # Okay, and does it need to be improved in some way to add something? 00.11.45 # Or is it fine as is? 00.12.03 # ender`: Pfft, x86 is boring ;) 00.12.07 # 00:11 -logbot(~rockbox@giant.haxx.se)- I have never seen 'jhmikes' 00.12.12 # who else could answer? 00.12.24 # RoronoaZoro: so codec optimisations is diving really deep into the codecs and optimising specifc parts (like fft) with better code/ asm code. The Video project is a bit defferent. 00.13.08 # It does work. It's ugly. It misses a status overview. It does not produce diff files (like translate.rockbox.org does). 00.13.17 # its more the devloping of a multi-codec able mpegplayer, and ofcourse porting work (optimising too, but probably not as much as for codecs) 00.13.46 # funman: Line 862 reads /* Draw the movie duration */ here 00.13.51 # Okay, so there are a couple of improvements to make 00.14.20 # amiconn: ah it's apps/plugins/mpegplayer/disk_buf.c (there's no plugins/mpegplayer.c !) 00.14.53 # RoronoaZoro: do you have any rockboxable mp3player ? 00.15.16 # I had discussion on the irc yesterday about video playback and i am basically starting to understand what is to be done. 00.15.17 # no 00.15.33 # sure. It's a basic version I've put together in just a couple of hours. 00.15.39 # bluebrother & domonoky: I have to run right now, but thanks for all your help, I will be back to talk some more about this later! :) 00.16.11 # RoronoaZoro: so you will have to buy one for this project :-) 00.16.34 # i was planning to have one by summers 00.17.00 # amiconn: with lack of comment (in the code) i was about to use #if NUM_CORES > 1, which would enable it only for PP, like it was before I defined PROC_NEEDS_CACHEALIGN for nano2g 00.17.33 Quit pamaury (Quit: Page closed) 00.19.02 # domonoky: you said Video project is bit different can you tell me more as to what can i keep as my goals for summer 00.19.53 # if i decide on it 00.20.04 # i mean its different, because the video project is not only optimisations, part of it is also to create a way to have multiple codecs in mpegplayer 00.20.25 Quit xiainx (Ping timeout: 276 seconds) 00.21.14 # and porting work of a new video codec. like extracting it from a different project, adapting it to rockboxs interface, maybe make it fixed point, etc 00.21.22 # funman: PROC_NEEDS_CACHEALIGN is only defined for PP anyway 00.21.35 # not since r25336 00.22.31 # cache alignement is useful for DMA 00.23.40 # But it's not required, or is it? 00.24.36 # hm not strictly 00.25.23 # That means NEEDS_STORAGE_ALIGN is a bit misleading 00.25.52 Quit GeekShadow (Ping timeout: 265 seconds) 00.26.06 # so for the Video project, what is expected to be known from me .... so that once i know that much i can understand and decide the goals 00.27.05 # according to ata-pp5020.c:ata_dma_setup() reads need to be aligned on 16 bytes, writes on 4 bytes. 00.27.37 # Perhaps it's nothing to do with cache lines size? 00.27.53 Part toffe82 00.28.04 # /* Require cacheline alignment for reads to prevent interference. */ 00.28.04 # /* Require cacheline alignment for reads to prevent interference. */ 00.28.33 # like i know about the basic video decoding stuff but have not read much on the codec specific decoding 00.29.02 # RoronoaZoro: I don't think you need to know much in particular. But you'll need to be competent in C, and be motivated to learn about the details of the codecs you want to work with. 00.29.43 # you should also have done enough research in advance to propose a reasonable project and time line 00.29.59 # that project is particularly open ended since most of us aren't sure which codecs are reasonable to implement 00.30.07 # r25103 added storage alignement for nano2g but there's no rationale 00.30.28 # ok 00.30.49 # RoronoaZoro: What do you find more interesting? Video or audio? (you said you weren't sure which to do). 00.32.31 # New commit by 03funman (r25338): fix red 00.32.45 # i liked the Video Decoding stuff when i read it... 00.34.08 # RoronoaZoro: But the best way to impress us in your application is to start work on it now - i.e. look at the existing mpegplayer code, try and understand it, and look for potential video-related source code to port to Rockbox. 00.35.18 Quit domonoky (Read error: Connection reset by peer) 00.35.33 # ok 00.35.59 # looking online there are many vendors selling ARM optimized codecs with performance figures provided, and papers on porting decoders (xvid's, etc) to ARM cores 00.36.15 # i think some research should clear up whats reasonable 00.36.23 # this might also be interesting: http://s-space.snu.ac.kr/bitstream/10371/6178/3/OpenMax%20Based%20MPEG4%20SP%20Video%20Decoder%20for%20ARM926EJ-S%20Platform.pdf 00.39.24 Quit S_a_i_n_t (Ping timeout: 265 seconds) 00.40.17 # i have already started to see different decoders and have about 2 papers and 3 sites 00.41.02 # i have been doing this since yesterday 00.47.08 Quit liar (Ping timeout: 258 seconds) 00.48.58 # its probably worth emailing the people who have done arm optimized open source decoders in those papers and ask them if they provide the source 00.49.03 # or maybe check their websites first 00.49.16 # xvid is GPL IIRC, so they'll probably be willing to give it to you 00.50.08 Quit ender` (Quit: I like work: it fascinates me. I can sit and look at it for hours. -- Jerome K. Jerome) 00.51.44 Join JdGordon [0] (~7bf38c1f@gateway/web/freenode/x-efsqsrikgsjjtruk) 00.54.38 # ok 00.54.52 Quit RadicalR (Ping timeout: 265 seconds) 00.55.32 # so i can start on it today itself... 00.56.18 # saratoga: That paper said they developed the decoder "using Xvid as a reference" - so it sounds like they rewrote it. But yes, it's of course worth asking. 00.58.51 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 00.59.07 # re implementation might have been done because it must have been better than porting it .... each possibility can be considered while writing a decoder 00.59.17 # funman: looks good, except I would prefer not to call it STORAGE_NEEDS_ALIGN - it's not actually *needed*, it's just desirable for performance. the PROC_NEEDS_CACHEALIGN one is actually mandatory :0 00.59.24 # STORAGE_WANTS_ALIGN? 01.02.22 # that's what amiconn also suggested, now i'm not sure how to separate PROC_NEEDS_CACHEALIGN & STORAGE_WANTS_ALIGN 01.06.19 # oh right I know, just make them use CACHEALIGN_BITS regardless PROC_NEEDS_CACHEALIGN 01.09.31 Quit DataGhost (Ping timeout: 240 seconds) 01.11.09 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.205) 01.11.53 # New commit by 03funman (r25339): Use STORAGE_WANTS_ALIGN to make clear it's not a strict necessity ... 01.11.53 Join xiainx [0] (~xiainx@modemcable091.119-201-24.mc.videotron.ca) 01.13.43 Quit komputes (Remote host closed the connection) 01.16.09 Nick animAgus is now known as _silentAssassin (~mrigesh@iws3.iiita.ac.in) 01.17.29 Nick fidencio[AWAY] is now known as fidencio (~fidencio@li113-135.members.linode.com) 01.18.27 # I wonder about the green delta for nano2g, there was no red in r25336-7-8 01.18.30 *** Saving seen data "./dancer.seen" 01.19.20 Quit funman (Quit: free(random());) 01.22.50 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.244) 01.24.26 Quit rasher (Ping timeout: 248 seconds) 01.24.29 Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) 01.24.29 Quit rasher (Changing host) 01.24.29 Join rasher [0] (~rasher@rockbox/developer/rasher) 01.24.51 Quit Adubb (Read error: Connection reset by peer) 01.24.58 Quit Bagder (Ping timeout: 248 seconds) 01.25.19 Quit S_a_i_n_t (Ping timeout: 265 seconds) 01.25.30 Join Bagder [0] (~daniel@rockbox/developer/bagder) 01.29.05 Nick fidencio is now known as fidencio[AWAY] (~fidencio@li113-135.members.linode.com) 01.30.00 Join naag [0] (~harish@210.212.160.101) 01.34.16 Quit naag (Ping timeout: 258 seconds) 01.43.47 Join CaptainKewl [0] (jds@207-237-107-203.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 01.50.38 Quit perfectdrug (Read error: Connection reset by peer) 02.07.52 Join Hillshum [0] (~hillshum@75-165-244-84.slkc.qwest.net) 02.15.07 Join CGL [0] (~CGL@190.79.148.8) 02.18.22 Quit aholic (Read error: Connection reset by peer) 02.21.12 Quit planetbeing (Quit: planetbeing) 02.22.32 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 02.24.52 Quit RoronoaZoro (Ping timeout: 258 seconds) 02.30.37 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 02.35.52 Join RoronoaZoro [0] (~vijayss@202.3.77.11) 02.45.19 Quit kadoban_ (Remote host closed the connection) 02.45.43 Join kadoban_ [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 02.52.32 Join DV [0] (~DV@218.248.65.244) 02.54.18 Join komputes [0] (~komputes@ubuntu/member/komputes) 03.15.18 Quit kadoban_ (Remote host closed the connection) 03.15.45 Join kadoban_ [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 03.18.32 *** Saving seen data "./dancer.seen" 03.20.15 Quit Darkknight512 (Remote host closed the connection) 03.22.15 Join Lss__ [0] (~Lss@cm48.omega219.maxonline.com.sg) 03.23.03 Quit Hillshum (Ping timeout: 260 seconds) 03.25.11 Join Hillshum [0] (~hillshum@75-165-244-84.slkc.qwest.net) 03.25.41 Quit Lss (Ping timeout: 268 seconds) 03.25.53 Quit kadoban_ (Read error: Connection reset by peer) 03.26.25 Join kadoban_ [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 03.35.26 Join Strife89 [0] (~michael@168.16.238.226) 03.35.38 Part RoronoaZoro ("Leaving") 03.37.57 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.0.244) 03.56.28 Quit kadoban_ (Remote host closed the connection) 03.56.55 Join kadoban_ [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 04.13.06 Join sejanis [0] (~63400f75@giant.haxx.se) 04.14.15 # anyone tried to format a iriver h10 and install just rockbox? 04.15.38 Join Barahir [0] (~jonathan@gssn-5f7544e8.pool.mediaWays.net) 04.18.06 Quit sejanis (Quit: CGI:IRC (EOF)) 04.19.12 Quit Barahir_ (Ping timeout: 264 seconds) 04.21.42 Quit TheSeven (Disconnected by services) 04.21.55 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.22.05 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.25.22 Quit SpyBot (Ping timeout: 258 seconds) 04.25.49 Join SpyBot [0] (~piespy@stgt-5d849a2f.pool.mediaWays.net) 04.28.31 Quit komputes (Ping timeout: 260 seconds) 04.31.33 Join JdGordon| [0] (~jonno@175.35.128.245) 04.43.58 Join Rob2222 [0] (~Miranda@p4FDCB4BF.dip.t-dialin.net) 04.44.20 Join Adubb [0] (~aldubuc@67.201.160.144) 04.44.23 Quit xiainx (Quit: Good Bye) 04.47.57 Quit Rob2223 (Ping timeout: 265 seconds) 04.50.32 # which h10 model 04.50.41 # 5/6gig or the bigger ones 04.53.53 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 04.59.24 Quit kadoban_ (Remote host closed the connection) 04.59.51 Join kadoban_ [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 05.04.26 Quit JdGordon| (Quit: Bye) 05.10.27 Quit Strife89 (Read error: Connection reset by peer) 05.10.56 Join Strife89 [0] (~michael@168.16.238.226) 05.18.35 *** Saving seen data "./dancer.seen" 05.22.44 Quit n17ikh (Ping timeout: 265 seconds) 05.28.17 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 05.29.41 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 05.31.01 Quit planetbeing (Ping timeout: 246 seconds) 05.31.01 Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 05.32.46 Join funman [0] (~fun@rockbox/developer/funman) 05.34.09 # linux can see my fuze over usb! (sometimes.. i must miss some initialization) : usb 2-9: device descriptor read/64, error -62 (ETIME) 05.34.37 # That's nice, I guess. 05.34.40 # v2? 05.35.16 # no, v1. rockbox doesn't run on v2 05.35.32 # Ah, sorry. I thought you were talking about the OF. 05.35.38 # Hence, my question. 05.35.58 # uh oh, funman's got insomnia again, lookout!! 05.36.04 # Congrats on cracking the clip though. And with that, I'll bow out of this channel. 05.36.11 # Since this is for developers. 05.36.51 # FlynDice: eh, lack of write support on Clip+ cause me nightmares, please save me !! :) 05.36.57 Quit S_a_i_n_t (Ping timeout: 260 seconds) 05.37.48 # does the phrase "gerbil on a wheel" translate to french? ;-) 05.37.54 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.244) 05.38.58 # yeah, keep running ^^ 05.39.05 # yep 05.41.33 Quit Horscht (Quit: Verlassend) 05.43.45 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 05.44.46 Quit Adubb (Read error: Connection reset by peer) 05.45.07 Join Adubb [0] (~aldubuc@67.201.160.144) 05.46.38 Quit bluebrother (Disconnected by services) 05.46.39 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 05.47.07 Quit arbingordon (Ping timeout: 246 seconds) 05.48.50 # Could someone have a look at http://bugs.freedesktop.org/show_bug.cgi?id=22569 to help them out? 05.49.01 # (getting Rockbox support in udev/hal/whatever) 05.49.40 # is audio playback stopped on usb connection ? (not when only charging at least) 05.56.13 Quit Strife89 (Read error: Connection reset by peer) 05.59.19 # funman: BTW I have seen some codec issues by now. Sometimes it stops playing and the codec thread hogs cpu (100% boost) 06.01.11 # other threads still work ? (button/backlight) 06.01.23 # Yeah. 06.02.02 # do you have high bitrate files ? (flac/ape) 06.02.12 Quit Zarggg_ (Read error: Connection reset by peer) 06.02.26 # Torne: If you happen to see this...just wondering how your iPod is going so far with the ass-half-of-iram-zero-ing shutdown. 06.02.28 # mp3 only, may be 320kbps though (didn't check) 06.03.03 # iirc high bitrates files made playback problems more frequent 06.04.02 # When I changed UI language during codec hang, the UI hung too until I connected with the debugger, saw that it was waiting for the codec to unload and manually set the variable it was waiting on from 1 to 0 using gdb over jtag. 06.06.23 Join Strife89 [0] (~michael@168.16.238.226) 06.13.23 # funman: Another issue I'd like to debug first are display / keypad glitches. 06.13.55 # My gut feeling is that it's an interaction between both display update and keypad read using DBOP. At first glance the code seems fine though... 06.14.27 # hm i thought we had cleared that once for all :( 06.14.45 # what's the problem? 06.17.20 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 06.18.30 # funman: In debug menu show hw info keypad barely responds at all. Sometimes I have to press a key dozens of times before it gets recognized. 06.19.30 # And I sometimes get short display glitches which looks like either a pixel didn't get sent (whole or part of the screen moves about one pixel left) 06.19.31 # dbop_debug() is only read in I/O ports, not in hw info 06.19.51 # dbop_debug() only reads the variable anyway :) 06.20.00 # oh :) 06.20.43 # Or like a partial refresh doesn't work and garbage data gets sent ot the lcd 06.22.06 # bertrik and kugel are your men for dbop 06.23.23 # mpegplayer would be good to stress the lcd but it doesn't run on 2MB 06.24.09 # Like here in the upper part of the screen: http://uguu.de/~ranma/S6001018.AVI 06.25.57 # is it really *one* pixel? 06.26.41 # hm there were some talks about statusbar 06.26.59 # try disabling it 06.29.01 # Well, not sure if it's exactly one pixel, but sometimes the whole screen seems to shift a tiny bit to the left for one update. 06.29.06 # ranma: isn't the freedesktop problem that rockbox uses the mtp id of the c200 OF ? 06.29.10 # rasher: ^ 06.29.36 # Yeah, looks like it should use the rockbox id as said on http://bugs.freedesktop.org/show_bug.cgi?id=20717 06.29.43 Quit togetic (Quit: WeeChat 0.3.0) 06.29.50 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 06.30.09 # ranma: e200v2/fuze have a delay before reading a button in dbop-as3525.c 06.31.07 # Yep, I've seen that, but haven't got around to trying it with the delay yet. But today I'm going to do a bit of debugging on that. 06.31.25 # But, first I'm taking a shower :) (Ugh, 14:30 already...) 06.32.23 Quit planetbeing (Ping timeout: 264 seconds) 06.32.24 Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 06.32.39 Join togetic [0] (~togetic@unaffiliated/ibuffy) 06.35.21 # hm can't tell what happens with USB : sometimes I get an interrupt for both input & output control endpoints, sometimes I get something in dmesg (device descriptor read timeout), sometimes nothing at all. I don't think I forgot to setup a register so I assume it's a timing problem 06.36.39 # Do you have a patch I can test? 06.37.24 # sure, let me try one last thing 06.37.25 Nick ranma is now known as ranma|brb (ranma@mx.tdiedrich.de) 06.39.16 Quit CGL (Quit: Saliendo) 06.41.07 # ranma|brb: http://pastie.org/887829 (apply the sansafuze.h diff to sansac200v2.h) 06.42.36 # funman: that was fixed. The more general freedesktop problem still exists 06.47.22 Join naag [0] (~harish@210.212.160.101) 06.58.04 Part naag 07.07.35 Nick ranma|brb is now known as ranma (ranma@mx.tdiedrich.de) 07.12.57 Join DerPapst [0] (~DerPapst@p4FE8F66E.dip.t-dialin.net) 07.18.37 *** Saving seen data "./dancer.seen" 07.21.08 # ranma: /"clear soft disconnect" : should be USB_DEV_CTRL not USB_DEV_CFG 07.24.24 # Ok, I was just building it. BTW I think turning on UVDD is unecessary as that should be only needed if you want to connect usb peripherals to the sansa... 07.25.34 # oh right, power comes from the host 07.25.48 # i'm mostly doing the same thing than OF / linux 07.26.21 # hoping to understand in the process 07.26.26 # Hmm, I get a reboot loop and sometimes data abort. 07.26.48 # how much audiobuffer is left? 07.29.58 # Is that recorded somewhere during build? Firmware just reboots directly after the rockbox logo, so... 07.30.36 # you can make the diff between audiobufend & audiobuf in rockbox.map 07.30.48 # not sure if usb would steal from audiobuffer though 07.31.52 # 604396 Bytes 07.32.20 # Oo that's a lot 07.33.44 # hm I get more than 1MB on normal clipv1 build .. 07.34.19 # ah but debug menu shows ~500kB for buffering thread 07.35.27 # Hmm, with while(1) in usb_init it still doesn't work. I think it may be beacuse of the PLL thing in system-init that was in the patch. 07.36.21 # try CGU_COUNTB = 0xff; before ? 07.36.30 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 07.36.30 Quit Zagor (Changing host) 07.36.30 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 07.37.05 # amiconn: RE fuze refreshing: i don't think making the system folder read-only still works. i'll try again though 07.50.33 # funman: Hmm, the problem is unrelated to your usb patch, I must have accidentally broken something in my tree here. 07.53.01 Nick ranma is now known as ranma|away (ranma@mx.tdiedrich.de) 08.11.05 # New commit by 03funman (r25340): Clip+: fix battery voltage reading when charging : use ADC_RTCSUP like e200v1 08.21.18 Join DV_ [0] (~DV@218.248.65.244) 08.22.08 Quit DV (Read error: Connection reset by peer) 08.30.37 Quit DV_ (Ping timeout: 276 seconds) 08.31.37 Join ender` [0] (krneki@foo.eternallybored.org) 08.35.42 Quit Bagder (Remote host closed the connection) 08.36.43 Join Bagder [0] (~daniel@rockbox/developer/bagder) 08.36.55 # hmm voltage alternate between 75 & 81% in the battery debug screen 08.38.43 Quit DerPapst (Quit: Leaving.) 08.42.19 Quit JdGordon (Changing host) 08.42.19 Join JdGordon [0] (~7bf38c1f@rockbox/developer/JdGordon) 08.49.47 Join mitk [0] (~mitk@195.117.162.130) 08.50.18 Join DerPapst [0] (~DerPapst@p4FE8F66E.dip.t-dialin.net) 08.52.12 Quit DerPapst (Client Quit) 08.57.08 Quit JdGordon (Quit: Page closed) 08.57.33 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 09.00.41 Join petur2 [0] (~petur@rockbox/developer/petur) 09.17.06 Join naag [0] (~harish@210.212.160.101) 09.18.40 *** Saving seen data "./dancer.seen" 09.19.35 Join flydutch [0] (~flydutch@host83-164-dynamic.15-87-r.retail.telecomitalia.it) 09.21.46 Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de) 09.27.21 Quit phanboy4 (Read error: Connection reset by peer) 09.29.21 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 09.30.28 Part naag 09.31.54 Join naag [0] (~harish@210.212.160.101) 09.32.03 Part naag 09.32.05 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 09.33.06 Join naag [0] (~harish@210.212.160.101) 09.34.26 Quit stripwax (Quit: http://miranda-im.org) 09.37.49 Join Professional [0] (~69@unaffiliated/shani) 09.53.58 # New commit by 03bluebrother (r25341): Fix uic warning. 10.09.19 Quit Professional (Ping timeout: 264 seconds) 10.10.15 Part naag 10.11.50 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.13.23 Join swilde [0] (~wilde@aktaia.intevation.org) 10.18.24 Join Professional [0] (~69@unaffiliated/shani) 10.20.07 Nick petur2 is now known as petur (~petur@rockbox/developer/petur) 10.37.59 Join TheSeven|Mobile [0] (~theseven@rockbox/developer/TheSeven) 10.38.32 Join B4gder [0] (~daniel@rockbox/developer/bagder) 10.41.16 Quit blairb (Quit: Leaving) 10.45.40 Quit Professional (Ping timeout: 246 seconds) 10.46.00 Join Professional [0] (~69@unaffiliated/shani) 10.48.57 Quit DerPapst (Ping timeout: 265 seconds) 10.50.45 Quit Strife89 (Quit: Going home soon) 10.54.22 Quit Professional (Remote host closed the connection) 10.58.40 Join LinusN [0] (~linus@rockbox/developer/LinusN) 10.59.35 Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) 11.03.05 Join kugel [0] (~kugel@rockbox/developer/kugel) 11.06.53 Join Kitr88 [0] (Kitr88@BSN-182-36-109.dial-up.dsl.siol.net) 11.08.19 # S_a_i_n_t: works fine so far :) 11.10.09 Quit Kitar|st (Ping timeout: 268 seconds) 11.18.42 *** Saving seen data "./dancer.seen" 11.28.02 Nick ranma|away is now known as ranma (ranma@mx.tdiedrich.de) 11.28.13 Quit RadicalR (Quit: Nettalk6 - www.ntalk.de) 11.39.46 # RTCSUP looks fine when not charging though 11.40.22 Quit planetbeing (Quit: planetbeing) 11.54.48 Join _Dhiraj [0] (~7371398d@gateway/web/freenode/x-fjeczxzeckeflucc) 11.56.20 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 11.56.28 Quit TheSeven|Mobile (Ping timeout: 260 seconds) 11.57.46 # ehh TBLCF was ok when debugging bootloader. Trying to debug rockbox itself shows how slow it is :-/ 12.04.27 Quit funman (Quit: free(random());) 12.17.35 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 12.25.30 Quit kugel (Ping timeout: 264 seconds) 12.41.17 # New commit by 03funman (r25342): Fuzev2: fix build, use suited bitmap tool 12.41.34 Quit liar (Quit: brb) 12.43.32 Join xiainx [0] (~xiainx@modemcable091.119-201-24.mc.videotron.ca) 12.45.19 Join mt_ [0] (~mtee@41.233.137.78) 12.46.19 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 12.46.43 Quit mt (Ping timeout: 258 seconds) 12.46.44 Nick mt_ is now known as mt (~mtee@41.233.137.78) 12.47.55 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 12.55.58 Join m3dlg [0] (~m3dlg@bb-87-81-252-83.ukonline.co.uk) 12.58.51 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 12.59.07 Quit yawny_ (Remote host closed the connection) 12.59.08 Quit yawny (Remote host closed the connection) 13.05.30 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 13.06.11 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.06.20 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 13.18.45 *** Saving seen data "./dancer.seen" 13.22.03 Quit xiainx (Ping timeout: 276 seconds) 13.22.53 Join perfectdrug [0] (~marko@p5B0EDA51.dip.t-dialin.net) 13.25.01 Join anewuser [0] (anewuser@unaffiliated/anewuser) 13.29.28 Join salty-horse [0] (~ori@109.65.48.140) 13.35.06 # <_Dhiraj> Hi! I wanted to work upon the Text to Speech as part of GSOC 13.35.12 # <_Dhiraj> How should I proceed? 13.36.06 # <_Dhiraj> Planning o use eSpeak right now 13.36.10 # <_Dhiraj> *to 13.37.14 # Welcome! 13.39.33 # Do you have a player that runs rockbox? 13.41.28 # wasn't there something about licensing with espeak (and Rockbox)? 13.42.05 # gplv3 13.42.15 # <_Dhiraj> I have vlc 13.42.37 Quit anewuser () 13.42.57 # <_Dhiraj> Is there a licensing issue with espeak? 13.43.01 # yes. 13.43.08 # It is GPLv3, we are GPLv2 13.43.28 # so including espeak in the rockbox core would change our license to GPLv3 13.43.38 # <_Dhiraj> ohk 13.44.06 # <_Dhiraj> then how about flite? 13.44.11 # Or we use an older version of espeak, before they changed the license. 13.44.45 # <_Dhiraj> But then the older version wouldn't be supported later? 13.45.13 # _Dhiraj: I think gevaerts meant a digital audio player that can run Rockbox, not which program you use on your PC ;) 13.45.14 # What do you mean by "supported" ? 13.45.39 # <_Dhiraj> I mean the community wouldn't look to its development, bugs etc. 13.46.01 # <_Dhiraj> So would have to be completely continued by our communiy I guess 13.46.56 # how big a problem that is depends on a lot of things 13.49.02 # so.. don't rule it out, but something different might be worth considering too 13.50.02 # <_Dhiraj> pixelma: I was just going through some page which stated vlc with reference to rockbox 13.50.39 # <_Dhiraj> pixelma: Which audio players are supported? 13.51.50 # <_Dhiraj> I haven't really used Rockbox but have used espeak in a different project 13.54.34 # there's a list on the our project's homepage... ;) ;) 13.54.42 # -the 13.57.47 Quit xavieran (Ping timeout: 260 seconds) 13.59.01 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 14.02.55 # <_Dhiraj> pixelma: I don't have a player 14.03.03 # <_Dhiraj> How can I move forward/ 14.03.04 # <_Dhiraj> ? 14.08.09 # gevaerts: [resume yesterday's beginning of conversation] 1) are you working on usb host ? 2) do you still think it might a good idea to switch to blocking/nonblocking version of usb_drv{send,recv} ? 14.12.06 # _Dhiraj: maybe you could have a look at some simulators, I could *imagine* that especially the ones of software codec devices (anything but Archos devices) already give a good impression, especially if it comes to the current voice system and playback. I can't tell from a code point of view though 14.13.20 # <_Dhiraj> pixelma: Ok. Thanks! 14.18.17 Join RoronoaZoro [0] (~vijayss@202.3.77.149) 14.18.42 # pamaury: (a) no. I once started on ohci, but I didn't get further than a set of register definitions (firmware/export/ohci.h). (b) cleaning up the send and recv functions is a good idea I think. The current asymmetry isn't too nice 14.18.51 Part RoronoaZoro 14.22.48 Join xiainx [0] (xiainx@wpa106019.Wireless.McGill.CA) 14.25.54 Quit Luca_S (Quit: CGI:IRC) 14.26.13 Join RoronoaZoro [0] (~vijayss@202.3.77.149) 14.27.43 Quit xiainx (Ping timeout: 276 seconds) 14.34.25 Join Schmogel [0] (~Miranda@p3EE22D3F.dip0.t-ipconnect.de) 14.36.30 Join webguest28 [0] (~8984fa0e@giant.haxx.se) 14.38.59 Part RoronoaZoro ("Leaving") 14.39.28 Quit kugel (Ping timeout: 265 seconds) 14.42.06 # Torne: Awesome ;D I have high hopes for this... 14.52.51 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 14.53.39 # <_Dhiraj> \quit Bye! 14.54.10 Quit _Dhiraj (Quit: bye) 14.55.04 Quit webguest28 (Quit: CGI:IRC (Ping timeout)) 14.59.46 # shortcut files don't have an icon 15.00.23 # salty-horse: edit your .icons file. 15.01.31 # you're saying it's in rockbox but not in my installations? 15.01.54 # no, I'm saying "edit your .icons file" 15.01.58 # I don't see it in filetypes.c 15.02.08 # Its in the "icons" folder in .rockbox 15.02.26 # on the DAP, not in the source 15.02.37 # I have such a file? 15.02.38 Nick fidencio[AWAY] is now known as fidencio (~fidencio@li113-135.members.linode.com) 15.02.42 # oh 15.02.47 # you should do... 15.03.52 # make it include "link:X" where X is a number from 0 to 31 (for the main iconset) or 0 to ? (for the viewers iconset you're using. 15.04.46 # if you're using an icon from the main iconset, it needs to be "link:*X" 15.04.59 # the * tells it to use the main iconset. 15.05.22 # I don't have .rockbox/.icons at all. I have a dir called .rockbox/icons/ 15.05.51 # *inside* the "icons" dir? 15.06.43 # tango_small_viewers.icons to be specific. 15.07.35 # the only dot files in .rockbox are: .glyphcache, .playlist_control 15.08.12 # GAH! .icons is the extension! look in .rockbox/icons/tango_small_viewers.icons 15.08.36 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 15.09.25 # Once you open the file, you'll see the syntax is pretty easy and you'll know what you need to do to add more extensions to it. 15.09.28 # oh! but I only have icons/tango_small_viewers.bmp 15.09.29 # no *.icons file 15.09.59 # That's weird...its in the source. 15.10.16 # Maybe it doesn't build with it for some reason. 15.10.17 # S_a_i_n_t, I'd rather like it added to the default cabbie theme so everyone would have it 15.10.35 # I may be using an old version (a month old, or so) 15.10.49 # that shouldn't make a difference. 15.11.14 # Just copy the tango_small_viewers.icons file to the "icons" dir on your DAP 15.11.27 # then edit it appropriately. 15.12.18 # but I don't have such a file anywhere. there's only a sample doc/sample.icons 15.12.18 # docs/ 15.13.08 # S_a_i_n_t, do *you* have icons for shortcut (.link) files with the default cabbie theme? 15.13.29 # I use my own iconset 15.14.55 # then I'll file a bug against cabbie 15.15.25 # There is already a bug regarding viewer icons. 15.15.31 # I lodged it myself ;) 15.15.51 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 15.16.21 # link please? 15.17.28 # FS#10981 15.17.36 # regarding mpio hd200 in order to incorporate dualboot rockbox bootloader into flash I have to hack original firmware and do firmware update. The process is simple - a) put rockbox bootloader at specified offset into original firmware file b) take first 8 bytes from rockbox bootloader and copy it to the very begining of the firmware file. The process itself is very similar to this used in h100/300 but without any encryption/decryption/checksum generation. 15.17.36 # So should I write little separate utility do patch of or should I hack mkboot ? 15.17.37 # http://www.rockbox.org/tracker/task/10981?string=viewer+icons+applied&project=1&search_in_comments=1&search_in_details=1&search_for_all=1&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= 15.18.49 *** Saving seen data "./dancer.seen" 15.19.39 # salty-horse: As you can see from FS#10981, there is problems with a *lot* more than just .link file icons ;) 15.20.43 # *the ugly grey background in the screendump is to make the weirdness of the 'strange black squares instead of icons' stand out better. 15.21.20 # thanks 15.21.54 # but what's that got to do with "Cabbie is missing a .link icon"? :) 15.22.10 # because cabbie doesn't have explicitly specified viewer icons 15.22.15 # viewers.config 15.22.20 # all themes use that file. 15.22.37 Quit wodz (Quit: Leaving) 15.27.53 # so my issue is covered by that bug? I just want to know if I need to file a separate one or not :) 15.28.23 # salty-horse: FS#10981 covers your bug, yes. 15.29.10 # No way of telling when it'll be looked at however. 15.31.51 # then I'll add a comment, so that issue won't get lost 15.32.11 # It won't get lost...its on the tracker. 15.32.28 # That's what the tracker is for ;) 15.32.47 # I meant my mini-issue, which you say may not be related to the bug you filed 15.33.15 # I didn;t say it "may not be related"...its directly related to it. 15.33.40 # Display of icons in general is slightly broken. 15.35.00 # Do any themes even use the file types colors functionality? Or does that even still exist? 15.36.33 # I'm not sure of themes are allowed to include colours for filetypes anymore..I think it was decided that should be up to the user to set. 15.36.59 # s/of/if/ 15.37.24 # It's something that has to be set by editing a text file 15.37.53 # It doesn't really seem like a user setting. 15.38.10 # It can be set on-device 15.38.20 # Quite easily in fact. 15.39.14 # Where? 15.39.31 # I forget exactly how (I don;t use filetype colours) but its definitely in the manual. 15.39.43 # S_a_i_n_t, sorry. I misread your "No way of telling when it'll be looked at however." as "No way of telling until it'll be looked at" 15.39.51 # filetype colors is a allowed theme setting. 15.39.58 # I don't think that's easily settable through the menu 15.40.45 # There's something in the manual about it, I think the text editor understands the syntax of the .colours file..and does some magic 15.40.51 # ...something like that. 15.41.13 # except loading a colours file (or however it's called). I can't remember seeing a theme that uses it 15.41.32 # The manually explicitly says ".colours file belonging to a theme .cfg" 15.41.42 # So the manual at least suggests they're to be treated as part of a theme 15.42.07 # but IMO that could be something a theme can include - in contrast to e.g. the language setting 15.42.13 # It's also only mentioned in one line in the text editor section of the manual 15.42.16 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.42.27 # Basically, nobody probably even knows this feature exists. 15.42.47 # I think very few people use it. 15.42.52 # But considering colours need to be compatible with the backdrop image used, they should always be either reset to default (use foreground color) or explicitly set by themes 15.42.54 # Just like everything else 15.43.01 # probably for that reason, or maybe not. 15.43.31 Join toffe82 [0] (~chatzilla@12.169.218.14) 15.44.43 # I think there is quite a few features rockbox has that people would be surprised existed to be honest... 15.45.02 Quit mitk (Quit: Leaving) 15.45.07 # When *most* people read the manual, its probably only to find out one specific piece of info. 15.45.21 # As opposed to actually "reading the manual" 15.45.51 # Well, this is a core feature that's only briefly mentioned in a plugin description 15.45.58 # And not demonstrated in the default theme 15.46.18 # I knew I saw it *somewhere* though ;) 15.46.39 # * Llorean thinks it might be nice if, for example, we slightly used filetype colors by making music/supported files one shade of gray brighter than other files in the default theme. 15.46.52 # pixelma: Speaking of the manual, are you able to produce a Clip+ image for it? Does an SVG already exist somewhere (I noticed the different Clip+ image on the download pages). 15.47.03 # I do seem to remember a conversation along the lines of "it should be up to the user to set filetype colours...*if* they want to" 15.47.31 # But you're right, they should be more *aware* of it as a feature. 15.47.32 # linuxstb: I believe Zagor committed a Clip+ small png from an svg in the patch tracker 15.47.55 # S_a_i_n_t: By that very same logic, it should be up to them to set the foreground 15.48.00 # Yet themes must set it, to prevent unreadability. 15.48.01 # s/they/people - users/ 15.48.27 # I think themers just set colours that work to begin with. 15.48.35 # * linuxstb thinks things would be much simpler if we didn't give users all this choice about independently setting different theme-related elements... 15.48.37 # Well, that's what I do. 15.48.58 Quit kugel (Remote host closed the connection) 15.49.03 # linuxstb: Agreed, honestly 15.49.08 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.49.41 # can anyone confirm this on other devices? http://www.rockbox.org/tracker/task/11146 15.50.10 # Like, dark text on a dark background won't work for any text...not just specific filetypes...So themers set a decent contrast between the two 15.50.32 # linuxstb: At the very least though, themes on the theme sight should basically "reset" to default all theme settings they don't explicitly set a value for of their own 15.50.40 # That way themes are more or less always applied to a known state. 15.50.55 # Filetype colours, if not required by themes now, means there's an unknown state in the visual appearance that can affect usability 15.50.58 # there's a theme sight? ;) 15.50.58 # Personally, none of my themes ever include a .colours file as I think thats up to the user to set to their preference, not mine. 15.51.07 # Wouldn't it just be easier to move all theme-related stuff out of the main .cfg file, and have a ".theme" file storing it all? 15.51.07 # I think it's still mostly okay if users set such things after the theme is loaded. 15.51.19 # linuxstb: It might help. 15.51.45 # That way, you don't have to worry about defaults - loading a .theme will always reset everything to defaults. 15.52.36 # S_a_i_n_t: But here's the thing. If Theme A sets filetype colors, and Theme B just assumes they're default. Theme A sets them dark, Theme B *is* dark, so dark colors are hard/impossible to see... what happens if you load Theme A then Theme B 15.53.00 # there is a "save theme" which will be a cfg though in the end 15.53.07 # If a user wants custom colors, they'll have a .colours file around defining them. So they can load their theme then load the .colours file, simple enough 15.53.59 # Wouldn;t it be easier to default those values while changing themes if its not set by the theme? 15.54.01 # pixelma: I think treating themes like a normal .cfg is the complication. If we move away from that, I imagine things being much simpler. (perhaps less powerful, but that may be a good thing...) 15.54.52 # S_a_i_n_t: There's not really a system for "default if not set by a file" plus, since a theme is just a .cfg, any time *any* .cfg file loaded without a .colours set would then default it 15.55.06 # S_a_i_n_t: The easiest would be for theme authors to explicitly set colours, even if what they explicitly set is "no colours" 15.55.38 # Llorean: And then we get a new theme feature, which older themes don't set to a default, and more complications... 15.55.39 # All my themes include "filetype colours: -" 15.57.51 # S_a_i_n_t: And that's exactly what I was saying they should do. 15.57.55 # You set it. 15.58.16 # linuxstb: Yeah. I honestly don't know why we don't have a separate .theme file. I'm sure it's come up in the past. 15.58.18 # Yes, well...kinda. I set it to "not set" 15.58.38 # There's no "kinda" about it. 15.58.39 # Llorean: I believe that conversation has come up, yes. 15.58.40 # You set it to a value 15.58.44 # The value is "default" 15.59.03 # I'd be opposed to e.g. losing the ability to set colours easily on the device, as they can look so much different on different devices and compared to the sim 15.59.26 # I guess a plugin could help there though 15.59.36 # I'd say a theme editor plugin would not be amis. 15.59.45 # Isn't a theme plugin in the works somewhere? 15.59.51 # pixelma: I don't think we would have to lose the settings - they could just get saved to the current ".theme" file. 15.59.58 # Just the existing setting menus, plus perhaps a "preview" button that shows you a sample of the selected .wps + colors in list, so you could see if it's readable/usable 16.00.19 # linuxstb: Well, moving the settings away from the user might be beneficial too, you said 16.00.55 # linuxstb: I thought that#s what your "less choice" boils down to 16.01.28 # * linuxstb isn't sure what he meant any more then... ;) 16.02.39 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 16.02.40 # S_a_i_n_t: I haven't heard about someone working on a theme editor plugin 16.03.16 # I'm fairly sure its been talked about, perhaps somewhere in GSoC discussion... 16.03.28 # I'm sure I remember seeing *something* about it. 16.03.46 # I think it's the fact that if theme settings are part of a .cfg, you can't clear all values to a default before loading it. So all I think I'm suggesting is to explictly store all theme settings in a .theme file, and ignore them if they appear in a .cfg The .cfg would just reference a .theme 16.04.28 # That seems like a good starting point at least, since nothing is lost there. 16.04.35 # S_a_i_n_t: Maybe you're thinking of the theme editor PC app 16.04.37 # so that would mean loading two files? 16.05.33 # Llorean: Hmmmm, possibly, I'm sure I saw mention of an "on-device" editor. But I could be wrong. 16.05.35 # Well, you load the .cfg, then it loads the .wps, the .sbs, the .rwps, and the .colours 16.05.39 # pixelma: Yes. Although we already load many files (main .cfg, .wps, .rwps etc etc) 16.05.40 # It would definitle be handy. 16.05.41 # Adding the .theme to the end of that list isn't a big deal 16.05.52 Nick fidencio is now known as fidencio[AWAY] (~fidencio@li113-135.members.linode.com) 16.12.21 Join hebz0rl [0] (~hebz0rl@dslb-088-067-205-197.pools.arcor-ip.net) 16.13.02 Quit toffe82 (Read error: Connection reset by peer) 16.13.45 Quit jgarvey (Quit: Leaving) 16.14.04 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 16.34.05 Quit leavittx (Read error: Operation timed out) 16.34.34 Join fyrestorm [0] (~nnscript@static-71-249-251-152.nycmny.east.verizon.net) 16.35.56 Join leavittx [0] (~leavittx@89.221.199.187) 16.39.23 Quit hebz0rl (Quit: Ex-Chat) 16.41.56 Join hebz0rl [0] (~hebz0rl@dslb-088-067-205-197.pools.arcor-ip.net) 16.53.54 Quit petur (Quit: connection reset by beer!) 16.58.38 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 16.58.47 # linuxstb: the flyspray task for the clip+ is here http://www.rockbox.org/tracker/task/11048 everything needed for the manual should be there 16.59.41 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 17.00.26 Quit bluebroth3r (Read error: Operation timed out) 17.02.05 # perfectdrug: Thanks. So I just need to drop those files into the write place, and that's it? 17.02.11 # s/write/right/ 17.02.30 # i hope so, you may have to check the naming though 17.02.32 Join komputes [0] (~komputes@ubuntu/member/komputes) 17.03.30 # perfectdrug: OK, I'll try and do that this evening, if no-one gets there first. 17.04.58 # linuxstb: fine:) i did my best to provide all files necessary, hope everything is right 17.08.05 Quit kaniini (Remote host closed the connection) 17.11.07 Join perfectdrug1 [0] (~marko@p5B0EDA51.dip.t-dialin.net) 17.11.08 Quit perfectdrug (Read error: Connection reset by peer) 17.17.43 Quit FlynDice (Remote host closed the connection) 17.18.06 Quit pamaury (Quit: Quitte) 17.18.50 *** Saving seen data "./dancer.seen" 17.21.29 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 17.27.00 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.29.30 Quit robin0800 (Remote host closed the connection) 17.38.52 Quit ender` (Read error: Connection reset by peer) 17.39.26 Join ender` [0] (krneki@foo.eternallybored.org) 17.40.32 Nick fidencio[AWAY] is now known as fidencio (~fidencio@li113-135.members.linode.com) 17.42.28 Quit B4gder (Quit: It is time to say moo) 17.42.53 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 17.43.58 Quit Guest3190 (Ping timeout: 258 seconds) 17.49.15 Quit Luca_S (Quit: CGI:IRC) 18.00.29 # New commit by 03FlynDice (r25343): sd-as3525v2.c Organize construction of MCI_COMMAND so it is more apparent which bits are being set and why. ... 18.11.38 # New commit by 03dave (r25344): Add Clip+ player image from FS#11048 by Marko Pahlke 18.12.16 # perfectdrug1: Your images seemed fine - they're now committed, thanks. 18.19.35 Join mitk [0] (~mitk@chello089078013146.chello.pl) 18.20.08 Join CGL [0] (~CGL@190.79.148.8) 18.21.18 # linuxstb: awesome:) 18.22.47 # perfectdrug1: I assume you're already in the CREDITS ? (I didn't check) 18.23.10 # * linuxstb sees that perfectdrug1 is 18.23.11 # yes I am thanks 18.23.52 Join feisar [0] (jljhook@irkki.fi) 18.24.20 Nick feisar is now known as Guest6244 (jljhook@irkki.fi) 18.26.27 # New commit by 03dave (r25345): Update copyright year to 2010 18.26.55 Quit Hillshum (Ping timeout: 264 seconds) 18.29.29 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 18.31.48 Join phanboy_iv [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 18.33.51 Quit phanboy4 (Ping timeout: 265 seconds) 18.35.42 Part LinusN 18.36.51 Quit GHF (Read error: Connection reset by peer) 18.37.37 Join GHF [0] (~meow@unaffiliated/ghf) 18.41.15 Quit phanboy_iv (Ping timeout: 245 seconds) 18.42.16 Quit _silentAssassin (Ping timeout: 264 seconds) 18.49.26 Join Edwerd [0] (~ed32@bzq-79-176-202-141.red.bezeqint.net) 18.49.40 # i have a quastion about clipV2 18.49.49 # i cant update the database 18.49.59 # becuase it aint developed yet 18.50.09 # that it can write files to the system 18.50.13 # "read only" 18.50.25 # or i have a specific problem with my clipV2 18.51.47 # As far as I know rockbox doesn't have write support yet on the clip v2 18.52.05 # because of that i cant update the database ? 18.52.15 # or create or whatever ? 18.52.23 # yes 18.52.45 # is there any way i can create the database through my pc ? 18.52.51 # and upload it to the player ? 18.52.56 # yes 18.53.38 # how ? 18.54.06 # i will be very much obliged if you could help me with that :) 18.54.26 Quit jgarvey (Quit: Leaving) 18.54.34 # kugel 18.54.35 # ? 18.56.36 Quit liar (Ping timeout: 258 seconds) 18.58.21 # any one can instruct me on how to create a database file on my pc ? 19.00.58 # Edwerd: you can use the database tool which you can build from svn 19.01.17 # no time to guide you through it now though 19.02.57 # can you give me a link for the tool ? 19.03.40 Quit GHF (Ping timeout: 246 seconds) 19.04.41 # You'll need to compile it, from the Rockbox source code. 19.04.45 Join GHF [0] (~meow@unaffiliated/ghf) 19.06.16 Quit kugel (Ping timeout: 264 seconds) 19.06.57 # where do i put the data base files 19.06.59 # ? 19.07.42 # in witch directory in .rockbox 19.08.52 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 19.12.17 # Just in .rockbox 19.14.25 # omfg 19.14.34 # he wont turn on 19.14.40 # wont even charge 19.14.46 # what could have caused this ? 19.15.06 Join Davide-NYC [0] (~chatzilla@user-12ld9nk.cable.mindspring.com) 19.16.09 # What did you do? 19.16.12 # it worked moments ago 19.16.25 # i've installed rockbox 19.16.32 # the latest build for clipv2 19.16.37 # and it worked just fine 19.16.46 # i've used some software for sourceforge 19.16.52 # to create the database files 19.17.06 # and put em on the .rockbox directory 19.17.12 # then it updated the files 19.17.17 # and it wont turn on 19.17.21 # since then 19.17.32 # Is it off topic to talk about "Rockbox as an Application" in this channel? 19.17.42 # Edwerd: Please, don't use the enter key as punctuation. Try to write clear and complete statements 19.17.46 # Davide-NYC: It's Rockbox... 19.17.57 # Edwerd: hold the power button to off for 15 secs 19.18.12 # Has there been any discussion about attempting to port some form of RB to Palm's WebOS? 19.18.31 # It is a linux based, SDL ready platform that is very open to developers. 19.18.54 *** Saving seen data "./dancer.seen" 19.19.03 # Edwerd: when you start it up again press the << button and you should get to OF 19.19.11 # I have had the phone for almost 9 months and absolutely love it. 19.19.11 # :) 19.19.20 # the 15 seconds solution worked for me 19.19.26 # and the database works aswell 19.19.27 # Davide-NYC: most people here are of the opinion that the exact target is a relatively minor portion of the total work, so we don't care too much about it 19.19.30 # thank you guys :) 19.19.46 # Davide-NYC: Really, the first step should almost certainly be porting it to a full PC app. 19.19.56 # Once that's done, target-specific ports for a lot of things become somewhat easier. 19.20.36 # gevaerts: Llorean: I see. 19.21.11 # Has there been any work in this direction recently? 19.21.15 # No. 19.21.17 Join _silentAssassin [0] (~mrigesh@iws3.iiita.ac.in) 19.21.21 # Davide-NYC: It's a GSOC project 19.21.31 # a project idea anyway :) 19.21.31 # Waddap Nick. 19.21.32 # s/project/project suggestion/ 19.22.40 # FWIW, the game community (gameloft etc) claims that porting to WebOS is particularly easy. It may be worth taking a quick look. How is the simulator not a PC app? 19.23.51 # It's a PC app 19.23.54 # Davide-NYC: it is a PC app, but it's full of hacks 19.23.54 # It's not "Rockbox as an App" 19.25.00 # Then it's just "The Rockbox App" 19.25.08 # no. It's a hack :) 19.25.16 # LOL 19.28.16 Join Xerion_ [0] (~xerion@82-170-197-160.ip.telfort.nl) 19.28.28 Quit Xerion (Ping timeout: 264 seconds) 19.28.34 Nick Xerion_ is now known as Xerion (~xerion@82-170-197-160.ip.telfort.nl) 19.28.56 Quit Davide-NYC (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 19.30.10 Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) 19.30.29 # lol i've created the database and says some error with a playlist writing or something 19.30.48 # but i've managed to creat the database manually 19.33.52 Quit flydutch (Quit: /* empty */) 19.45.14 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.46.13 Join xiainx [0] (~xiainx@modemcable091.119-201-24.mc.videotron.ca) 19.46.36 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 19.46.46 Quit planetbeing (Client Quit) 19.49.56 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 19.55.22 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.1.115) 19.55.32 Quit S_a_i_n_t (Ping timeout: 265 seconds) 20.01.43 # Is there some reason rbutil doesn't try to download OF images when they're necessary? 20.07.59 # copyright fears, and also the OF Urls might change. 20.08.25 # Could it at least provide the last known link? 20.08.40 # "please click this link, save the file in the same folder as rbutil, and click OK to continue" or something 20.08.50 # We could have the OF URLs on www.rockbox.org, with a script to test them nightly. 20.09.07 Quit kugel (Ping timeout: 246 seconds) 20.09.10 # Right now, for players that require an OF image people often need to know to look in the manual install section. 20.09.21 # Which, by the way, is a URL that might change. ;) 20.11.30 Join kugel [0] (~kugel@rockbox/developer/kugel) 20.22.50 # rbutil shows a message with the neccessary urls (sometimes pointing to the wiki= 20.24.43 Join liar [0] (~liar@213162066156.public.t-mobile.at) 20.26.11 Join shivkrish [0] (~980f5b02@giant.haxx.se) 20.29.50 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 20.32.20 Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 20.33.10 Join BHSPitLappy [0] (~BHSPitLap@unaffiliated/bhspitmonkey) 20.34.11 Quit BHSPitLappy (Read error: Connection reset by peer) 20.34.29 Join BHSPitMini [0] (~BHSPitMon@adsl-66-141-186-193.dsl.rcsntx.swbell.net) 20.35.19 Quit jgarvey (Quit: Leaving) 20.37.59 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 20.39.26 Join petur [0] (~petur@rockbox/developer/petur) 20.53.47 Quit BHSPitMini (Ping timeout: 276 seconds) 20.56.42 Join intrados [0] (~intrados@d149-67-101-219.col.wideopenwest.com) 20.58.25 Quit moos (Ping timeout: 246 seconds) 20.58.31 Quit intrados (Client Quit) 21.03.03 Join Darkknight512 [0] (~Darkknigh@CPE00212968356c-CM00186845dd46.cpe.net.cable.rogers.com) 21.12.25 Quit Xerion (Quit: ) 21.13.30 Join moos [0] (moos@rockbox/staff/moos) 21.18.17 Quit hebz0rl (Quit: Ex-Chat) 21.18.57 *** Saving seen data "./dancer.seen" 21.18.58 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 21.18.58 Quit pixelma (Disconnected by services) 21.19.11 Quit amiconn (Disconnected by services) 21.19.14 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 21.19.17 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 21.19.36 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 21.23.26 Quit fyrestorm (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) 21.24.21 Quit Battousai (Read error: Operation timed out) 21.25.26 Join buz_ [0] (~buz@80-218-218-243.dclient.hispeed.ch) 21.25.37 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 21.27.24 # i am experimenting with rockbox on a clip+. works beautifully so far. only thing I cannot quite get to work is the database. its sitting there for 5min now saying it found 0... 21.28.55 Join Battousai [0] (~bryan@gentoo/developer/battousai) 21.29.21 Join Hans-Martin [0] (~hmm@i577BF72E.versanet.de) 21.30.35 Join froggyman [0] (~me@unaffiliated/froggyman) 21.31.00 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 21.32.13 # hi folks, after my old PNA went belly-up (GPS won't work anymore) I would like to use it for the rest of its lifetime as a rockbox media player. I know there have been efforts in teh past to run rockbox as an app on WM5+6 (by saratoga), but there's nothing on the web site. 21.32.29 # I could invest some time into this, but I'd prefer not to start from scratch. 21.33.01 # I have some experience with cross-compiling for CE (aka WM) using the MinGW compiler 21.33.02 Quit planetbeing (Ping timeout: 240 seconds) 21.33.03 Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 21.33.46 # Hans-Martin: The simulators already run as SDL apps. Assuming there's SDL for WinMo, adapting one of them to your purposes might be a starting point, though ideally there's a lot of things that would need to work differently for the ideal rockbox as an app 21.34.45 # buz_: there's no write support yet, hence you cannot create the database on target 21.34.59 # * kugel thinks rockbox should handle no-write-support better 21.39.05 # hm, I think I take a look at it. 21.41.34 Join robin0800 [0] (~robin0800@general-ld-216.t-mobile.co.uk) 21.47.51 Quit Zagor (Quit: Clint excited) 21.48.26 Join Halborr [0] (~chatzilla@dhcp-51-27-149-24.cf-res.cfu.net) 21.49.06 Quit xiainx (Ping timeout: 264 seconds) 21.50.49 Quit moos (Ping timeout: 245 seconds) 21.50.57 Join xiainx [0] (xiainx@wpa106060.Wireless.McGill.CA) 21.52.29 Join moos [0] (moos@rockbox/staff/moos) 21.57.22 Quit robin0800 (Remote host closed the connection) 21.57.37 Quit evilnick_B (Quit: Page closed) 22.05.38 Join Strife89 [0] (~michael@adsl-220-102-96.mcn.bellsouth.net) 22.08.34 # hey does anyone know what the notation (1<<4) means? 22.09.16 # well, it's standard C... 22.10.39 # sorry if it's a stupid question 22.10.46 # Halborr: its a one shifted by four bits :-) 22.11.04 # *shifted left* 22.11.10 # ah 22.11.27 # thank you *to google!* 22.11.42 # Well, this isn't really a C support channel 22.12.36 # yeah, sorry. I was just looking at the rockbox code and wondered what that meant. I've got a long-term project of understanding at least part of the code in rockbox (in order to contribute later) 22.16.56 # Halborr: I'd recommend either ##c, #rockbox-community, or a good reference manual. We really want to keep things on-topic in #rockbox 22.18.00 # Will do. I figured it was okay since there wasn't much (any?) traffic. 22.18.44 # Halborr: The channel's logged, so we discourage unrelated traffic independent of time so that there's less noise in the logs for people reading through them to see if they've missed anything important. 22.19.21 Nick fidencio is now known as fidencio[AWAY] (~fidencio@li113-135.members.linode.com) 22.19.48 # Ah. 22.25.34 Join webguest11 [0] (~63c44038@giant.haxx.se) 22.27.55 Quit webguest11 (Client Quit) 22.28.12 Join webguest87 [0] (~4b68a024@giant.haxx.se) 22.29.20 Quit webguest87 (Client Quit) 22.29.31 # kugel: ah that makes sense. maybe giving an error would be useful, though. also, failing a db, a feature to just play all songs in shuffle would be a big step for me (i mostly use the clip in shuffle mode all) 22.29.57 # you can d that, can't you? 22.30.06 # do* 22.30.21 # not sure, have not figured out how to say the least :) 22.30.38 # If you have a music folder, just "insert shuffled" it. 22.30.41 # It's pretty easy. 22.31.03 # ok, ill give that a shot 22.31.14 # buz_: We're paddling as fast as we can, please be patient... 22.31.30 Join Alexandru_Criste [0] (acr@79.112.10.234) 22.31.30 # otherwise i like what i hear, maybe placebo but it seems to have better soundquality 22.33.19 # buz_: I believe you are correct though, you cannot shuffle between multiple directories as it stands now. I beleive write support will remedy this. 22.33.51 # i may just drop all files into one directory then :) 22.34.03 # I hink that would work 22.34.09 # think even 22.34.29 # FlynDice: If you just have all your music organized like \Music\Artist\Album\Song.mp3 (note the top single folder) you can just insert the single folder. 22.35.02 # If you have it all as individual folders in the root (which is quite cluttered anyway), yes you'll need to insert every folder individually, or use the "create playlist" option, and then shuffle that playlist (which is still quite quick) 22.35.21 # so recursing down trees works? even better then 22.35.28 # yes, recursing is on by default 22.35.36 # thanks guys 22.36.09 # the clip was in bad need of a better eq - any place to send a few beers to? 22.37.14 # ideally the database and other features should be conditional on write support working 22.38.04 # Agreed 22.38.05 # buz_: you can donate to the project through the paypal button on rockbox.org 22.38.18 # How many features really require write? Database and dircache and? 22.38.22 # probably will 22.39.03 # resume 22.39.41 # Does resume present any weird behaviour or does it just say "nothing to resume"? 22.39.46 # saving settings 22.39.56 Quit pamaury (Quit: Page closed) 22.40.53 # I don't know if you could readily disable settings, though. ;) 22.41.05 # I guess the weird behaviour there is when you stop playback. You'll get the "can't write playlist.control (or however it is called exactly)" if I remembercorrectly 22.41.48 # Maybe the message could be clarified to "unable to write resume data" or something? 22.41.52 # Something more user understandable? 22.41.56 # Llorean: You probobly understand this better than me I can only go on what I observe. On my clip+ right now I cannot insert an entire directory and have the player play music. I can do that on my e200v2 and fuze. I am guessing write support will enable this. 22.42.27 # I can play from a directory in shuffle mode though 22.42.33 # in the GSoC project list I read Rockbox as an Application and I would like to know more about the project 22.42.36 # That's very strange. And no, I'd have no clue why. :) 22.42.44 # could anyone point me in any direction? 22.42.47 # Alexandru_Criste: What questions did you have? 22.43.17 # what is the main goal of the project? 22.43.31 # To run Rockbox as an application... 22.43.33 # Alexandru_Criste: the goal is to get rockbox running as an application on another embedded operating system 22.44.05 # and this would be acomplished by porting the Rockbox code? 22.45.02 # * domonoky thinks the biggest work for this project, would be to change the sdl simulator to be more similar to real targets, and adapt it to a specific embedded os (android for example) 22.45.02 # yes 22.45.06 # Alexandru_Criste: Right now Rockbox makes a lot of assumptions based on the fact that it is also the operating system. As well, has provisions for its plugin architecture and memory use and file access that don't necessarily make the same sense when run as an application within another OS 22.45.26 # New commit by 03alle (r25346): Remove the unneeded appendix declaration. It's already present in appendix.tex and does not make any sense here (=at the end) anyway. 22.45.38 # domonoky: imo getting the sim to compile in the target tree isn't really that hard, but getting it to compile and also run in a useful way is a LOT of work :) 22.45.54 # FlynDice: I think inserting and other playlist manipulation updates the playlist control file which it can't without write support 22.46.06 # domonoky: I wouldn't describe it like that. I would describe it as separating Rockbox's application part more from its kernel, so that it can run on other kernels. 22.46.19 # the Rockbox code is written in C/C++ 22.46.21 # right? 22.46.24 # C 22.46.25 # Not C++ 22.46.29 # C and Asm :-) 22.46.50 # Alexandru_Criste: right now rockbox is an operating system that only runs one program (which is also rockbox), eventually it would be nice to be able to run it on other operating systems as a program 22.46.56 # Asm won't be an issue for this project though 22.46.58 # pixelma: Yes, that's what I think is going on but I haven't tried to dig into the code... 22.47.37 # from what I read the preffered platform is Android 22.47.41 # domonoky: i.e. creating a clearer API between apps/ and firmware/, and then implementing the firmware/ part as a wrapper for different target OSes. 22.47.55 # I've been working on Android for some time 22.47.56 # linuxstb: sounds good :-) 22.48.03 # Alexandru_Criste: There's not too much of a "preferred" platform. It's just one of the most obvious/significant candidates. 22.48.14 # I didn't had the chance working on NDK 22.48.18 # but I read about it 22.48.32 # we don't really have a prefered platform, but android is probably one of the easiest to work on 22.48.35 # One other problem with the simulator is that several bits of it are basically hacked together, like e.g. the threading support 22.49.04 # and I am not so sure that Android OS let's you use the hardware directly 22.49.10 # imo even things like threading aren't so important for this project, the goal is really to get something working so that people can use it and see how to improve it 22.49.37 # right now its impossible for another person to work on rockbox as an app without also being a core rockbox developer since we haven't yet really decided how rockbox as an app should work 22.50.06 # Alexandru_Criste: android lets you do things in plain C using the ndk, if you want to 22.50.22 # yes,but there are limitations 22.50.30 # not really, no 22.50.30 # you have the player already implemented 22.50.55 # Alexandru_Criste: you need (a) access to the screen, (b) the ability to output sound, and (c) the ability to read buttons and the touchscreen 22.51.06 # I'm assuming that those are possible 22.51.10 # afaik all of those things can be done from c code, using sdl on android 22.51.14 # you have all those 22.51.20 # but on a higher level 22.51.32 # I tried to modify the MediaRecorder 22.51.33 # gevaerts: + d) storage access :-) 22.51.39 # the highest level may involve some java stuff on androd 22.51.43 # Well yes, this is where "as an application" comes in 22.51.48 # to enable RTSP streaming 22.51.52 # But for Android, wouldn't a better approach be to write the higher-level code in Java, and just use Rockbox's playback engine and codecs? (hasn't someone even done that already?) 22.51.52 # and got to an dead end 22.51.54 # we don't stream anything 22.52.17 # linuxstb: ideally the sdl people already did that and we can start with their code and maybe go from there later . . . 22.52.22 # no no 22.52.23 # I know 22.52.24 # Alexandru_Criste: that's not a proof that it really is a dead end though... 22.52.26 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 22.52.31 # I was just talking about the posibilities 22.52.46 # linuxstb: i think rewriting the gui in java, is a too big project. java warppers for drawing etc should be enough. 22.52.48 # i don't think this project involves adding any new features to rockbox playback 22.52.59 # it should just get the current ones working 22.53.01 # linuxstb: that might be useful later on, to be done after the rest actually works :) 22.53.08 # for GSOC the network stack might as well not exist in android 22.53.29 # I agree, let's get the playing native music done first 22.53.30 Join kaniini [0] (~quassel@dyn75-70.yok.fi) 22.53.39 # or local perhaps 22.53.46 # once you have a proof of concept port, i'm sure other people will take interest 22.53.52 # to use the sdk/ndk 22.53.57 # to create a player 22.54.11 # it's not very hard 22.54.32 # i would phrase it more as using the sdk/ndk/sdl to get an existing player working on android 22.54.35 # it's not about "to create a player" 22.54.39 # one with very complicated requirements 22.54.43 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.170) 22.54.57 # But I think even a project that gets Rockbox running as a real application on a Linux desktop (in a clean way that allows more ports) would be a successful summer. 22.55.13 # i think once we had something usable on android others would take interest, like that guy who wrote the simple android player using our codecs 22.55.19 Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) 22.55.20 # The hard bit shouldn't be the android/maemo/something specific bits, it's getting the rockbox code itself in a good shape to run as an application, i.e. with an OS running under it 22.55.23 # i'm sure he'd be very intertested if a rockbox port existed 22.55.56 Quit CGL (Quit: Saliendo) 22.55.56 # gevaerts: well i have an ancient patch for doing that now, although its a bit ugly 22.57.25 Quit S_a_i_n_t_ (Ping timeout: 268 seconds) 22.58.11 # Alexandru_Criste: I think the important thing is that this shouldn't be thought of as an Android project - it's a project to work with the Rockbox code to separate the application part of it in a clean way, and then perhaps port it to Android as a secondary task. 22.59.31 # how can I access the repository? 22.59.52 # http://www.rockbox.org/wiki/UsingSVN 23.00.32 # linuxstb: i was able to compile rockbox for linux/sdl under the target tree years ago 23.00.47 # imo that should be less then the primary objective or this project is not much use 23.00.49 # saratoga: Yes, but there's a lot more to it than that. 23.01.11 # saratoga: there's more than compiling under linux/sdl in the generic part as far as I can see 23.01.15 # yes but if the primary objective is something we've already shown to not be very useful, i think it will be a dull project 23.01.24 # imo without the port whatever changes are made will simply rot 23.02.08 # we can't just separate things without giving rise to a new port and expect others to do the rest, we must have a proof of concept application port 23.02.22 # otherwise this exercise will be for nothing like my attempt at rockbox as an app 23.02.33 # I don't think it would rot at all - I for one would use a proper Rockbox app for my main desktop linux player, which is my proposal for a first step, ignoring any embedded OSes. 23.03.08 Quit shivkrish (Quit: CGI:IRC) 23.04.15 # why don't you use the sim now? 23.04.37 # saratoga: getting things to compile from proper locations is really just the beginning. You'd basically get the same code as the sims have now after that, and running the sim on n900 takes lots of CPU and stutters. That really shouldn't happen on a 500MHz armv7 23.05.10 # sure but if you have a useful device, you can make incremental improvements until it doesn't 23.05.16 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 23.05.22 # people already run our sim on various linux phones 23.05.23 # saratoga: I do sometimes. But it's things like not having access to my full filesystem (unless I setup symlinks), having a small screen, etc. 23.05.36 # linuxstb: those things could quite easily be fixed 23.05.43 # the screen res is just a define in a config file 23.06.16 # saratoga: Yes. But if RaaA existed, they wouldn't need fixing, so I would use that - that's my point. 23.06.35 # saratoga: all those small things probably add up time fast.. 23.06.59 # And ports to actual targets is going to be relatively easy (and fun - meaning lots of people will want to do it) once the infrastructure is there. 23.07.07 # yes of course, but i mean the changes right now are quite simple, imo the real problems with using rockbox as a media player on a PC are much more fundimental and unlikely to be addressed by this project 23.07.28 # * gevaerts still thinks that the very first goal (possibly even before the target tree work) should be to use a real cooperative threading library 23.07.30 # if using rockbox as a media player was as simple as changing the resolution someone would already be doing that right now 23.07.53 # i really dont' think messing with the threading is a good idea for this project, at least not initially 23.08.04 # the moto porters already showed that what we have is tolerable if poor 23.08.12 # we have bigger problems then some inefficiency 23.08.17 # gevaerts: if we use sdl for drawing, why not use its threads as well? 23.08.33 # kugel: have you looked at how the sim does threading? 23.08.45 # a third party threading library only makes sense if we drop the other sdl bits as well, doesn't it? 23.09.08 # in the long term we should probably just use whatever libraries the OS API provides right? 23.09.19 # i assume these embedded systems have some prefered threading tools 23.09.31 # I don't think so, no 23.09.42 # so they just give you processes and nothing else? 23.09.44 # we probably wont easily get around the need of cooperative sheduling. 23.09.47 # do OSes provide cooperative threading? 23.10.05 # rockbox heavily relies on the cooperative bit 23.10.20 # * domonoky would just write a custom sheduler like the rockbox one, and run it in one host thread. 23.10.23 # kernels don't provide cooperative threading because they don't need to. libc provides building blocks you can use 23.10.45 # You can do cooperative threading with multiple host threads 23.10.46 # well any OS that provides preemptive should also be able to provide cooperative provided its latency isn't too high and we don't need to directly touch hardware registers and interrupts 23.10.48 Quit mitk (Quit: Leaving) 23.10.48 # But there are libraries around that build on those libc mechanisms to give you something pretty close to what native rockbox does 23.10.49 # and there are some advantages to doing so 23.11.08 # saratoga: What fundamental problems are you talking about? Are they different on a PC than something like an Android device? 23.11.22 # well on a PC our interface sucks for using a mouse IMO 23.11.26 # You just put a semaphore on each thread.. 23.11.35 # Torne: is that really efficient? 23.11.36 # saratoga: Touchscreen WPS buttons help with that a lot 23.11.36 # and we can't dynamically resize windows which is also annoyinjg 23.11.37 # and inside yield() you pick a thread to run, signal its semaphore, then wait on your own semaphore 23.11.39 # Though the file tree still sucks 23.11.41 # gevaerts: it's not horrible 23.11.47 Join webguest77 [0] (~4b692026@giant.haxx.se) 23.11.49 # it helps but its still pretty bad imo 23.11.52 # gevaerts: and it gives you the ability to "pop outside" the scheduler for a while 23.12.01 # gevaerts: to do synchronous OS calls or whatever 23.12.10 # or to pretend to be an interrupt handler, or so on 23.12.13 # Heck, just adding a right click to be the "context menu" button would be a vast improvement for sims if it's not. 23.12.17 # This is how the Symbian emulator works, for reference ;) 23.12.25 Quit _silentAssassin (Remote host closed the connection) 23.12.31 # though we also have preemption 23.12.32 Join EBG [0] (~chatzilla@67-61-163-190.cpe.cableone.net) 23.12.38 # implemented using a further nasty trick ;) 23.12.41 # New commit by 03alle (r25347): Correct quotation marks; simplify the viewport display example 23.12.41 # saratoga: That's the same as integrating with any host UI framework. 23.13.01 # Torne: the rockbox sim does this as well (except for the useful bits :), and I've seen it elsewhere too 23.13.10 # gevaerts: yeah. it's really not htaat bad an idea 23.13.10 # IMO rockbox is never going to be all that great on a mouse based OS as long as we have the current menu system 23.13.12 Quit webguest77 (Client Quit) 23.13.14 # gevaerts: it works properly in debuggers :) 23.13.22 # Torne: "we have preemption"? 23.13.28 Quit EBG (Client Quit) 23.13.33 # kugel: sorry, different we. Symbian. 23.13.44 # the menus work great on button based devices, and can probably be made to work pretty well on touch devices, but they're just plain odd on a PC 23.13.49 # For a simulator it's definitely good enough, but for a real app I'd really go for the most efficient threading possible 23.14.33 # gevaerts: well yes as an eventual goal 23.14.36 # but that's hard.. 23.14.45 # you would need to start by surrounding almost the entire OS with a preemption mutex :) 23.14.58 # then break it off a bit at a time 23.15.16 # s/the most efficient threading/the most efficient cooperative threading/ :) 23.15.41 # I'm not convinced that preemptive threading is a good idea on native targets, and I don't think having both is a good idea 23.15.48 # Oh 23.16.02 # Well, you can do that too, you just need the relevant asm magic to context switch 23.16.11 # but then you have a problem if you need to call blocking OS functions 23.16.20 # * domonoky mentions that rockbox sheduler on target is not only cooperative, but als has some custom dynamic prioritys.. dont know if that is important for the app part. 23.16.24 # you probably still need more than one thread. 23.16.36 # I've very briefly looked at http://www.gnu.org/software/pth/ and I think it should work 23.17.26 Join _silentAssassin [0] (~mrigesh@iws3.iiita.ac.in) 23.18.11 # saratoga: I'm not talking about Rockbox being a great PC music player. I'm just saying that if the first step of RaaA is to make it run as a PC app, which can be used as an easy-to-debug platform to solve other issues, that's not a waste of time, or something that would rot if taken no further. 23.19.00 *** Saving seen data "./dancer.seen" 23.19.01 # g'nite... 23.19.08 Part Hans-Martin 23.20.06 # from what I understand Rockbox currently has some kernel functions 23.20.07 # right? 23.20.14 # its a complete os, so yeah 23.20.22 # so I suppose it's based on a linux kernel 23.20.35 # no 23.20.52 # we're an os, not a linux application 23.21.03 # rockbox has its own rockbox kernel :-) 23.21.15 # if we ran on linux directly that would make this a LOT easier 23.21.38 # right now the only parts that run on unix or windows are the sim, and they're ugly 23.21.42 # Torne: there's also makecontext()/swapcontext(), but those are apparently gone from recent POSIX 23.21.57 Part domonoky 23.22.07 # I thought the application started from a modified linux kernel 23.22.14 # so you just wrote the kernel 23.22.23 # all the kernel 23.22.27 # gevaerts: we could always use the multicore code 23.22.28 # from nothing? 23.22.32 # Alexandru_Criste: yes 23.22.48 # gevaerts: to get it into two threads, so the UI is isolated from codec 23.22.57 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 23.22.58 # Alexandru_Criste: The whole thing is custom, nothing to do with linux 23.23.02 # Alexandru_Criste: From the top of the Rockbox home page - "Rockbox is an open source firmware for mp3 players, written from scratch. " 23.23.14 # how dependent is the application code from it's kernel? 23.23.55 # very :) 23.23.56 # Alexandru_Criste: At the moment it's very closely tied - that's the main task for RaaA. 23.25.20 # was going to suggest a note on our front page about this, but its already there: "Rockbox is an open source firmware for mp3 players, written from scratch. " 23.25.36 # * scorche has booked his trip over to europe 23.26.37 # so the main task is lowering the coupling between the application and the kernel 23.26.58 # and then porting the application under another kernel\ 23.26.59 # yup, though actually implementing the support to run the application on *some* OS is important too 23.27.12 # i don't know about reducing coupling, but certainly porting 23.27.26 # and is it feasable under a 3 months term? 23.27.51 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 23.29.33 # Alexandru_Criste: What's feasible is for you to put in your project proposal. 23.30.11 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 23.31.36 Join salty_horse [0] (~ori@bzq-109-65-48-140.red.bezeqint.net) 23.31.54 Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 23.33.27 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 23.33.32 Quit planetbeing (Ping timeout: 258 seconds) 23.33.32 Nick planetbeing__ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 23.34.06 # gevaerts: it looks like pth uses make/swapcontext 23.34.37 Quit planetbeing_ (Ping timeout: 252 seconds) 23.35.08 # kugel: I think that despite what posix *now* says, it's still reasonable to use those if you really want cooperative threading 23.36.14 Quit salty-horse (Ping timeout: 276 seconds) 23.36.37 # i still want the rockbox test driver project 23.36.45 # i think that could have a huge impact on the quality of our code 23.38.11 Quit petur (Quit: Zzzzz) 23.38.47 # saratoga: that's basically isolating the playback engine, right? 23.39.09 # that or else not isolating it but adding a scripting interface 23.39.26 # but isolating it is probably best 23.44.34 Quit S_a_i_n_t (Read error: Connection reset by peer) 23.45.32 # what's the problem with tacking our thread library onto a single OS thread? 23.45.57 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.4) 23.46.27 # it's simply, but I guess it's only simple because we can do asm tricks we cannot do on a OS? 23.46.31 # simple* 23.46.54 # You can do asm tricks on an OS, but those would basically reimplement make/swapcontext 23.48.37 Quit _silentAssassin (Remote host closed the connection) 23.49.40 Quit froggyman (Quit: ta ta) 23.49.47 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.95) 23.49.52 # kugel: our thread library only has it implemneted for arm/mips/sh/coldfire, is the main one ;) 23.50.13 Quit S_a_i_n_t (Ping timeout: 240 seconds) 23.52.08 # don't we rely on being able to disable interrupts in some places? 23.52.41 # (which requires supervisor mode which AFAIK won't have as on app?) 23.52.52 # you don't really need to disable interrupts 23.52.56 # outside drivers? 23.53.09 # since you also aren'y handling them, as an app 23.53.10 # :) 23.57.25 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net)