--- Log for 28.11.113 Server: sendak.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 21 days and 18 hours ago 00.03.51 Quit Zagor (Quit: Clint excited) 00.08.24 Quit cmhobbs (Ping timeout: 265 seconds) 00.16.02 # \o/ 00.16.05 Quit pamaury (Ping timeout: 272 seconds) 00.16.21 # I've got queue_* functions working with pthreads 00.17.15 # (that, among other work, might enable us to re-use our playback core in other applications/non-"legacy" UIs) 00.17.55 Quit JdGordon| (Ping timeout: 248 seconds) 00.17.56 Quit Narod () 00.18.07 # Nice! 00.18.36 Quit Elfish (Read error: Operation timed out) 00.18.47 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 00.19.04 # I found that there areN't relly nice message/event queue APIs out there 00.24.33 Quit pamaury (Ping timeout: 245 seconds) 00.30.29 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 00.31.11 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 00.35.21 Quit kugel (Ping timeout: 272 seconds) 00.40.58 Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) 00.42.56 Quit bertrik (Remote host closed the connection) 00.55.42 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131122094025]) 01.00.06 Join Water [0] (~chatzilla@adsl-68-253-225-181.dsl.dytnoh.ameritech.net) 01.00.36 Quit Water (Client Quit) 01.02.12 Quit Elfish (Ping timeout: 240 seconds) 01.13.18 Quit [7] (Ping timeout: 246 seconds) 01.21.47 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 01.24.15 Nick [Saint] is now known as Brendan_Fraser (~saint@rockbox/user/saint) 01.24.30 Nick Brendan_Fraser is now known as [Saint] (~saint@rockbox/user/saint) 01.30.36 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 01.33.18 Quit stripwax (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 01.35.15 Join treaki_ [0] (57543ee721@p4FF4A1FD.dip0.t-ipconnect.de) 01.38.07 Quit treaki__ (Ping timeout: 252 seconds) 01.40.37 Quit ps-auxw (Ping timeout: 260 seconds) 01.41.29 *** Saving seen data "./dancer.seen" 02.02.24 Quit timofonic4 (Quit: WeeChat 0.4.2) 02.30.11 Quit zoktar (Quit: -) 03.35.13 Join Strife89 [0] (~Strife89@adsl-98-80-219-190.mcn.bellsouth.net) 03.41.32 *** Saving seen data "./dancer.seen" 03.43.14 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 03.51.34 # pamaury: Thanks for the LCD explanation. (I had read the datasheet.) 04.00.51 Quit amiconn (Disconnected by services) 04.00.51 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.00.53 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.00.54 Quit pixelma (Disconnected by services) 04.00.54 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.00.56 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.08.47 # Re Issue 1, the white flash, it might be worth keeping in mind that though yes on restore from display low power state it is short, on boot (after 'Executiing') it is longer. At the point of that boot white flash (and instead of it) we are still getting occasional hang with black screen requiring reset. I have a hunch this is related to power button use and will test further to find a reproducable case. 04.10.04 # Clearly the flash iteself is easy to fix by ensuring the LC is black before enabling backlight. 04.16.47 # Re Issue 2, the corruption, I beleive this is not confined to the (now removed) power up on restore from low power. It also can happen on the initial power-up, as reported by MrJoe in the forum. It seems to vary with unit, and I have not seen it on the identical model of ZEN to MrJoe's, or the other two units I've tried. 04.21.59 # Re Issue 3, LCD stays black and device unresponsive, I do think it is related to the LCD because here it occurred mostly following the (now fixed) LCD getting stuck white. What's odd about that one is that the state of the LCD (or a cause thereof) is apparently affecting the ooutcome AFTER the reboot. That suggests reboot's initialisation of the device state is incomplete. 04.22.04 # Bye for now. 04.27.51 # <[Saint]> Its always nice when people tell other people how clearly easy to fix something is. 04.44.41 Join JdGordon1 [0] (~jonno@ppp118-209-200-27.lns20.mel6.internode.on.net) 04.44.47 Quit JdGordon1 (Changing host) 04.44.47 Join JdGordon1 [0] (~jonno@rockbox/developer/JdGordon) 04.46.21 Quit JdGordon| (Ping timeout: 252 seconds) 04.59.24 Quit pixelma (Disconnected by services) 04.59.24 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.59.26 Quit amiconn (Disconnected by services) 04.59.26 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.59.26 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.59.28 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 05.02.18 Quit TheSeven (Disconnected by services) 05.02.31 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.12.21 Quit Strife89 (Ping timeout: 248 seconds) 05.13.09 Join JdGordon| [0] (~jonno@ppp118-209-137-34.lns20.mel6.internode.on.net) 05.13.09 Quit JdGordon| (Changing host) 05.13.09 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 05.16.18 Quit JdGordon1 (Ping timeout: 265 seconds) 05.29.39 Quit amayer (Quit: Leaving) 05.41.34 *** Saving seen data "./dancer.seen" 06.03.01 Quit rudi_s (Ping timeout: 248 seconds) 06.07.37 Join rudi_s [0] (31580@ircbox.informatik.uni-erlangen.de) 06.08.50 Quit [Saint] (Remote host closed the connection) 06.14.34 Join [Saint] [0] (~saint@rockbox/user/saint) 06.22.13 Quit mortalis (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 06.22.27 Join mortalis [0] (~kvirc@213.33.220.118) 07.00.14 Quit JdGordon (Ping timeout: 250 seconds) 07.10.40 Join JdGord|w [0] (cb1380e2@gateway/web/freenode/ip.203.19.128.226) 07.41.35 *** Saving seen data "./dancer.seen" 08.24.26 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 08.24.58 Join LinusN [0] (linus@giant.haxx.se) 08.27.01 # chrisjj: You know, patches are welcome. As a side note, I agree with pamaury here - the fact that behavior varies between units suggests timing issue. 08.31.03 Join ender` [0] (krneki@foo.eternallybored.org) 08.36.32 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) 08.45.38 Join kiwicam [0] (~quassel@121.99.176.30) 08.49.04 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 09.14.27 Join petur [0] (5bb7304d@rockbox/developer/petur) 09.41.37 *** No seen item changed, no save performed. 10.48.35 Join lebellium [0] (~chatzilla@80.215.9.224) 10.53.15 # lebellium: do you have this firmware for YP-CP3? I might look into it how much it is different from ref design when I am bored with mips stuff 10.54.36 # wodz: they should be all here: http://www.anythingbutipod.com/forum/showthread.php?t=32690 10.54.47 # ok, thanks 10.54.58 # this player seems to be hard to get 10.55.40 # wodz: it was only released in China and Russia. And I managed to convince the Product Manager to release it in France too. 10.56.17 # is still it on stock? 10.57.02 # No, it's discontinued since 2010 10.59.41 # They stopped the production in April 2010 10.59.57 # I just found old emails again 11.00.21 # '" * CP3 (end of production in Apr.) 11.00.24 # 1. Spelling error (Mirco SD Card ) > Will be fixed next firmware within this month. 11.00.25 # 2. Function for Video screen size > Cann't apply it in CP3 due to main chip performance. " 11.00.56 # I just can't believe it. Is the rockships really so shitty that it can't handle video playback with the right screen ratio?! 11.01.36 # Hehe, as I stated earlier you should read 2) as 'Rockchip' didn't released enough specs for us and we are hesitant to push or to figure out ourselves 11.01.45 # *release 11.03.46 # Video decoding is done on ZSP500 dsp. This is quite a beast - 4-issue with tight loops support 1cycle mac and other goodies running at up to 150MHz 11.05.07 # there is also hw scaler integrated in lcdif and YUV<->lcd hw converter 11.05.58 # The point is that AFAIK decoders for dsp are shipped in binary form with SDK and lcdif part is poorly documented in datasheet 11.06.40 # oh, and there is no free ZSP500 SDK nor toolchain (although AFAIK the one shipped by LSI is gcc based) 11.07.19 # It's a bit too technical for me :D 11.08.24 # If you are interested I can explain it better probably 11.12.06 # is the RK27 port still in active development? 11.14.05 # lebellium: That depends how do you define active development. I have a few half-finished things on the table, I poke here and there but the easy parts are done and the harder one need more time then I have 11.14.41 # the harder parts like NAND? 11.15.05 # The two big are USB and FTL 11.15.13 # lowlevel nand is figured out 11.15.34 # well, mostly. I don't know how to use DMA but OF doesn't use it either 11.16.11 # Ah FTL.... pamaury and lorenzo have the same issue on imx233 I guess 11.16.44 # And DSP is not used at all. I made it run small snippets of hand-assembled code during devcon in London but thats all 11.18.11 # lebellium: There are 2 or 3 versions of FTL used on rk27xx depending on SDK version. I mostly understand how the version I have on my player works. I thing RO support is a matter of a week of free time. 11.20.02 # RO support? 11.20.08 # read only 11.20.34 # ah 11.20.36 # Writes are done though some software implemented cache and this bit is unclear for me 11.20.37 # sorry^^ 11.25.41 # funny, hxediting the CP3 firmware file, I can read S.A.M.A.U.N.G. Samsung fail? :D 11.27.29 # :-) 11.27.44 # lebellium: On IHIFI firmware i found "fuck" string :P 11.28.20 # nice 11.28.21 # there is wide spread mistake where one field in nand struct is called 'vonder' instead of 'vendor' 11.28.52 # mortalis: btw. how is your work on 'new bricks' going? 11.30.37 # wodz: That was easy. Sound works even with dummy_codec. LCD also works. Only minor things left - keymaps, battery curve, plugins. 11.31.03 # nice 11.31.20 # "C.o.n.n.e.c.t.e.d. .t.o. .T.V.-.o.u.t..." eh what TV-Out? There is none on CP3 :) 11.33.10 # lebellium: Its leftover from SDK - some chips from rk27xx family have composite output 11.33.29 # ah 11.41.38 *** No seen item changed, no save performed. 11.46.00 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.48.14 # wodz: "You know, patches are welcome". I didn't know that. I'd assumed that while this port is in hot beta, code changes best be left to Amaury. Please tell me if I'm wrong, pamaury. 11.49.25 # chrisjj: We work collaboratively by definition. If you have a fix you will save pamaury's time for other things 11.50.19 # especially since I have a lot of work and thus not so much time to hack 11.51.59 Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 11.53.38 # Thanks. 11.57.12 # Maybe try to increase the spi delay 12.12.32 # actually you also try to delete it completely 12.25.06 # pamaury: going through std_analyzers.cpp do I assume correctly that I have to name ClockAnalyzer class for rk27xx differently? 12.25.27 # yeah 12.25.43 # actually it would make sense to rename the whole file std_analysers_imx233.cpp 12.25.53 # probably 12.25.56 # and create another one for rk27xx 12.26.07 # and rename the classes too 12.26.46 # though for clocks, it would make sense to have a generic class to display the clock tree that you can specialise with target specific code to actually read the clocks 12.26.52 # I recall vaguely there is some mechanism in c++ to trap class in particular namespace 12.26.58 # this way you don't have to write the UI twice 12.27.02 # yeah 12.27.13 # put everything in namespace Blabla { } 12.28.53 # pamaury: Another thing - if you have register with defined fields (and values) in qeditor there is this part called Meaning. AFAIK it is always empty. From where it is supposed to get description? 12.29.49 # the intended meaning was to read the value and it the desc file provides some named value, find out which one it is 12.30.03 # I don't know if I implemented it or not ^^ 12.30.23 # pamaury: every target names clocks differently and this are derived differently. I don't think there is easy way to generalize that 12.30.45 # yes you can, just have a look at it's done for the imx233 12.30.57 # pamaury: ah, so it is supposed to work when inspecting reg dump, right? 12.31.25 # a clock tree is easy: you have nodes and when you derive from a parent, you can be on/off and have multiplier + divisor, that handles virtually all cases 12.31.25 # wodz: yeah 12.32.07 # oh actually I implemented it 12.32.17 # so it should work, but you have to provide named values 12.33.44 # Will try to dive into it maybe. Not knowing c++ is the problem in my case :P 12.34.55 # yeah sorry for that, but writing GUI is just much simpler with Qt 12.35.38 # I am not blaming you 12.35.50 # learn c++, that's worth it I guess :) 12.36.11 # I tried a few times and failed. I feel much stronger in asm world 12.37.35 # C++ is a terrible language anyway; there is much worse though so I still prefer to write code in C++ than in most other languages 12.39.22 # pamaury: If I add class Rk27xxClockAnalyser derived from Analyser which will have SupportSoc() method acting properly on rk27xx in soc name will it just magically work? 12.39.51 # not quite 12.40.12 # you need to register it this way: 12.40.23 # static TmplAnalyserFactory< MyClockAnalyser > g_myclock_factory(true, "My Clock Analyser"); 12.41.03 # ah, thats what it is for 12.41.15 # yeah ^^ 12.43.23 # pamaury: Did you build ui registered with analyzer by hand or with qtdesigner? 12.44.25 # by hand 12.45.48 # all the UI was made by hand 12.49.34 # pamaury: How to load reg description file to hwstub_shell in order to call DUMPER.dump_all() 12.51.01 # ah pass it as an arg 12.52.41 # yeah 12.56.32 Quit pamaury (Read error: Connection reset by peer) 12.57.25 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.58.25 Quit wodz (Quit: Leaving) 13.01.20 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 13.10.10 Join JdGordon1 [0] (~jonno@ppp118-209-214-17.lns20.mel6.internode.on.net) 13.10.10 Quit JdGordon1 (Changing host) 13.10.10 Join JdGordon1 [0] (~jonno@rockbox/developer/JdGordon) 13.10.32 Quit Guest81512 (Ping timeout: 245 seconds) 13.10.35 Quit JdGordon| (Ping timeout: 252 seconds) 13.24.01 Join JdGordon| [0] (~jonno@ppp118-209-188-24.lns20.mel6.internode.on.net) 13.24.01 Quit JdGordon| (Changing host) 13.24.01 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 13.24.36 Quit JdGordon1 (Ping timeout: 248 seconds) 13.24.50 # Is there some news about RButil v1.4 and RB 3.14 releases schedule? 13.29.13 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 13.30.22 # RButil 1.3.1 is now 1 years old 13.37.35 Quit JdGordon| (Ping timeout: 240 seconds) 13.39.40 Join JdGordon| [0] (~jonno@ppp118-209-237-85.lns20.mel6.internode.on.net) 13.39.50 Quit JdGordon| (Changing host) 13.39.50 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 13.41.41 Quit ikeboy (Remote host closed the connection) 13.41.42 *** Saving seen data "./dancer.seen" 13.53.05 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 14.00.09 Quit ikeboy (Quit: ikeboy) 14.09.00 Join krabador [0] (~krabador_@unaffiliated/krabador) 14.26.35 Quit thegeek (Read error: Operation timed out) 14.54.26 Quit mortalis (Ping timeout: 272 seconds) 15.01.50 Join pretty_function [0] (~sigBART@123.252.213.156) 15.04.59 # what needs added to RButil? 15.06.34 # update the changelog :) 15.14.58 Join Narod [0] (~Narod@p5DDDB4BD.dip0.t-ipconnect.de) 15.23.22 Quit kevku (Ping timeout: 260 seconds) 15.41.47 *** Saving seen data "./dancer.seen" 16.05.40 Quit pretty_function (Remote host closed the connection) 16.23.21 Quit krabador (Quit: Sto andando via) 16.29.20 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 16.30.21 Join markun [0] (~markun@rockbox/developer/markun) 16.42.36 Join Jinx [0] (~Jinx@unaffiliated/jinx) 16.42.36 Part Jinx 16.45.00 Join cmhobbs [0] (~cmhobbs@ip70-178-52-92.ks.ks.cox.net) 16.45.00 Quit cmhobbs (Changing host) 16.45.00 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 16.51.57 Quit einhirn (Read error: Connection reset by peer) 16.55.45 Join einhirn [0] (~Miranda@p4FF890C6.dip0.t-ipconnect.de) 17.00.02 Quit einhirn (Ping timeout: 252 seconds) 17.05.29 Quit Zagor (Quit: Clint excited) 17.16.25 Quit ender| (Ping timeout: 256 seconds) 17.16.25 Quit ender` (Ping timeout: 252 seconds) 17.26.16 Join lebellium_ [0] (~chatzilla@80.215.9.224) 17.29.42 Quit lebellium (Ping timeout: 240 seconds) 17.30.02 Quit lebellium_ (Read error: Connection reset by peer) 17.30.16 Join lebellium [0] (~chatzilla@80.215.9.224) 17.41.50 *** Saving seen data "./dancer.seen" 17.42.41 Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) 17.43.16 Quit cmhobbs (Ping timeout: 248 seconds) 17.49.09 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 17.51.05 Quit petur (Ping timeout: 250 seconds) 17.52.30 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 17.52.30 Quit n1s (Changing host) 17.52.31 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.53.50 Join ender` [0] (~ender@foo.eternallybored.org) 18.04.02 Part LinusN 18.04.11 Join LinusN [0] (linus@giant.haxx.se) 18.05.37 Part LinusN 18.08.29 Quit zoktar (Ping timeout: 245 seconds) 18.18.52 Join pretty_function [0] (~sigBART@123.252.213.156) 18.23.42 Join lorenzo92 [0] (~chatzilla@2a02:27e8:10:746:0:dacc:0:4) 18.26.10 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 18.44.47 Join cmhobbs [0] (~cmhobbs@ip70-178-52-92.ks.ks.cox.net) 18.44.54 Quit cmhobbs (Changing host) 18.44.54 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 18.54.18 Quit y4n (Read error: Connection reset by peer) 18.55.00 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 19.02.01 Quit lorenzo92 (Ping timeout: 252 seconds) 19.07.10 Quit pretty_function (Remote host closed the connection) 19.28.44 Join lorenzo92 [0] (~chatzilla@2a02:27e8:10:746:0:dacc:0:1) 19.29.41 Quit lorenzo92 (Client Quit) 19.29.59 Join lorenzo92 [0] (~chatzilla@2a02:27e8:10:746:0:dacc:0:1) 19.41.54 *** Saving seen data "./dancer.seen" 20.04.02 # pamaury: re the ZEN wrong colours side-issue http://forums.rockbox.org/index.php/topic,13462.msg221673.html#msg221673 I added a note suggesting the cause is spurious BGR mode. 20.05.57 # chrisjj: the problem is that I don't understand this bit: logical would tell I should set the opposite value but if I do, they the colours at inverted. But i've never ran into this issue of colours inversion since I've published the code. I take it as a sign that the init code has a timing problem and the lcd doesn't correctly interpret the commands 20.06.12 # *are inverted 20.07.29 # pamaury: which value are you writing to this bit? 20.08.05 # hum, let me see 20.09.10 # I set the BGR bit 20.11.12 # I think the bit is simply misnamed: the doc says that 0 exchange R and B and 1 is bypass, so it's more a RGB bit than a BGR bit ^^ 20.11.39 # I love it when you guys speak Engineer. 20.11.52 # It's like music to my ears. 20.17.18 # OK, so you are writing "1", meaning bypass (I agree with you about the misnaming!), meaning that provided you are sending in the order R, G, B, we should see correct colours. 20.18.02 # I see two possible mechanisms of this failure. 20.20.21 # #1 The BGR bit is initially "0" (invert), for some reason coded initialisation fails i.e. the BGR bit write does not occur, and so the unit is left with BGR "0", giving wrong colours. 20.23.02 # #2 The BGR bit initialisation to "1" (bypass) succeeds, but the pixel data sequence transmission is faulty, containing a single additional or missing byte, causing the gun pattern to be shifted over the pixel boundary i.e. first byte missing: R1G1B1 R2G2B2 R3G3B3 -> G1B1R2 G2B2R3 G3B3R4. 20.25.09 # I hope that #2 makes sense. I can't suggest what is the specific cause in our case, but I have seen it happen elsewhere, and you can see I think how it could be happening to us, esp. since we already suspect some timing sensitivity. 20.25.32 # #2 is very very unlikely, early in the port I had problem synchronisation the lcdif with the data stream so the display would shift randomly and the results were never wrongs colours: it was either a correct but shifting screen or a complete mess (depending on how bad the synchronisation was ^^). #1 is much more likely 20.26.10 # The pixel data is sent by the lcd block whereas the init data is sent over bit-banged SPI. I very much trust the LCD block rather than the bit-banged SPI 20.27.33 # OK, I hear you, but do consider that definitely a single BYTE addition/deletion will cause wrong colours, and a shift that would be too small to spot. 20.29.04 # wouldn't that screw up the individual pixel data completely? 20.29.13 # Well, maybe that would be possible but that would mean the hardware is broken then: the display is refresh 50 times per second, both the DMA and lcd block the number of bytes to send, if one byte was added every frame I think that would qualify as a serious hardware bug 20.29.20 # *refreshed 20.30.10 # No it wouldn't screw up the individual pixel data completely. 20.30.16 # that could be the case if we were doing partial refresh because then the number of bytes would not be a multiple of 2 and I've ran into issue with this previously. But here we refresh the entire screen so it's ok 20.31.03 # Not necessarily a hardware bug. Last time I saw it, the cause was a software bug - an out-by-one error in the DMA block start register. 20.31.45 # When I say "missing byte", I mean only missing in the sequence. The total number of bytes is unchanged becasue and extra one gets sent at the end. 20.31.56 # in some players we have bumped into hardware bugs that the OF just didn't trigger 20.33.03 # pamaury: re multiple of 2, I suggested a single byte but actually two bytes will have a very similar effect. 20.33.08 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 20.33.11 # right one color channel would end up slightly shifted in relation to the other two and all colors jumbled 20.33.19 # Furthermore, #1 would explain both colour problem and black screen 20.34.20 # nis: Precisely. If we could pause on the start screen, we might see the shift. 20.35.34 # pamaury: I agree #1 could cause both, but it would be just ask likely to hit the TB or SS bits in the same register, causing flip or mirror - and I have never seen either in the thousands of inits I have seen. 20.37.13 Join pamaury_ [0] (~quassel@rockbox/developer/pamaury) 20.39.58 Quit pamaury (Ping timeout: 272 seconds) 20.44.47 Quit JdGordon| (Ping timeout: 240 seconds) 20.46.27 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.46.51 Quit pamaury_ (Ping timeout: 246 seconds) 20.47.03 Join JdGordon| [0] (~jonno@ppp118-209-154-168.lns20.mel6.internode.on.net) 20.47.03 Quit JdGordon| (Changing host) 20.47.03 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 20.52.36 Quit pamaury (Ping timeout: 248 seconds) 20.53.40 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131125215016]) 21.03.41 Quit y4n (Quit: Do you like hurting other people?) 21.05.15 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 21.20.02 Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) 21.20.32 # chrisjj: pausing on start screen is as easy as adding while(1); in code 21.21.38 # pamaury: Why do you init using bit-bang spi? Doesn't lcdif block have bypass mode to send commands to lcd? All lcdifs I saw have something like this. 21.21.46 Quit pamaury (Ping timeout: 272 seconds) 21.23.19 Join itoikenza [0] (uid15992@gateway/web/irccloud.com/x-hwefzcrlzqrnfcqk) 21.41.57 *** Saving seen data "./dancer.seen" 21.42.54 # Can anyone recommend an portable amp? 21.51.52 Quit Narod () 21.58.40 # wodz: thanks, but I meant pause the existing code. 22.01.48 # The wiki says "When you want to save power, like when in USB mode, you call cpu_idle_mode():" Can anyone tell me why particularly USB mode? 22.03.16 # Where does it say that? 22.03.32 # It sounds like an old bit dating from the days of hardware USB-ATA bridges 22.04.52 # http://www.rockbox.org/wiki/DynamicCPUFrequency 22.05.49 Quit bluebrother (Read error: Connection reset by peer) 22.05.57 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 22.07.02 # Yes, hardware USB 22.07.19 # Where we do basically absolutely nothing until disconnect 22.08.37 Quit fs-bluebot (Ping timeout: 264 seconds) 22.09.02 # Ah, thanks. I suspected as much, on seeing nearby "the USB thread grants the USB chip control of the hard drive" :) 22.10.04 Join fs-bluebot [0] (~fs-bluebo@g225252153.adsl.alicedsl.de) 22.10.38 # Has anyone given thought as to how in general such documentation issues are to be dealt with going forward? 22.14.42 # How to kill the mood at a programmers' party: mention documentation! :) 22.20.50 # chrisjj: The documentation IS good thing we know and we are definitely lacking in this area. 22.32.45 # defintely, chrisjj, haha 22.32.56 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 22.33.17 # about this topic, I was wondering these days about drawing some diagrams 22.34.22 # as well as commenting more the crucial functions... 22.44.56 # chrisjj: I use bit bang SPI because there is no other way, the SPI bus is not shared with the other lcd lines 22.48.46 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 22.54.48 Join Strife89 [0] (~Strife89@adsl-98-80-237-111.mcn.bellsouth.net) 22.56.45 # pamaury: that was my question actually 22.57.31 # ah sorry, misread :) 23.03.39 Quit wodz (Quit: Leaving) 23.16.13 Quit lorenzo92 (Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]) 23.20.00 Quit n1s (Quit: Ex-Chat) 23.26.29 Join kugel [0] (~kugel@91-66-52-103-dynip.superkabel.de) 23.26.29 Quit kugel (Changing host) 23.26.30 Join kugel [0] (~kugel@rockbox/developer/kugel) 23.27.30 # Diagrams would be good, but the possible more important thing is the question of where to put them... Anyway, back to code :) 23.28.42 Quit kevku (Ping timeout: 260 seconds) 23.36.17 Quit ender` (Quit: The only reason some people get lost in thought is because it's unfamiliar territory. -- Paul Fix) 23.41.58 *** Saving seen data "./dancer.seen" 23.49.20 # Sorry, that must have come over as rude. I meant I must get back to code here. I'd really like to talk about RB documentation next time. Thanks. 23.49.58 # yw 23.58.12 Quit itoikenza ()