--- Log for 01.01.115 Server: tepper.freenode.net Channel: #rockbox --- Nick: logbot- Version: Dancer V4.16 Started: 11 days and 11 hours ago 00.00.42 Quit igitoor (Changing host) 00.00.42 Join igitoor [0] (igitur@unaffiliated/contempt) 00.27.11 Nick [Franklin] is now known as [HappyNewYear] (~franklin@unaffiliated/franklin) 00.27.40 Nick [HappyNewYear] is now known as [Franklin] (~franklin@unaffiliated/franklin) 00.27.57 Nick [Franklin] is now known as [HappyNewYear] (~franklin@unaffiliated/franklin) 00.47.41 *** Saving seen data "./dancer.seen" 01.00.28 Quit shmibs (Quit: obythur!) 01.02.53 Join shmibs [0] (~shmibs@198.52.217.65) 01.03.05 Quit [HappyNewYear] (Ping timeout: 264 seconds) 01.11.45 Join [HappyNewYear] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) 01.18.15 Join pystar89 [0] (~pystar89@ip-176-199-76-43.hsi06.unitymediagroup.de) 01.29.22 Quit ZincAlloy (Quit: Leaving.) 01.29.25 Join zoktar_ [0] (~zoktar@78-72-45-32-no186.tbcn.telia.com) 01.31.01 Quit zoktar_ (Changing host) 01.31.01 Join zoktar_ [0] (~zoktar@unaffiliated/zoktar) 01.35.58 Quit zoktar (*.net *.split) 01.35.58 Nick zoktar_ is now known as zoktar (~zoktar@unaffiliated/zoktar) 01.50.25 Quit burgobianco (Remote host closed the connection) 01.52.51 Quit AlexP (Remote host closed the connection) 01.54.34 Join burgobianco [0] (~viskestel@li607-220.members.linode.com) 01.54.47 Quit [HappyNewYear] (Ping timeout: 245 seconds) 02.03.37 Join [HappyNewYear] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) 02.04.10 # <[HappyNewYear]> Happy new year, everybody! 02.10.11 Quit [HappyNewYear] (Changing host) 02.10.11 Join [HappyNewYear] [0] (~franklin@unaffiliated/franklin) 02.17.06 Nick [HappyNewYear] is now known as [Franklin] (~franklin@unaffiliated/franklin) 02.17.52 Nick [Franklin] is now known as [HappyNewYear] (~franklin@unaffiliated/franklin) 02.18.00 Nick [HappyNewYear] is now known as [Franklin] (~franklin@unaffiliated/franklin) 02.26.06 # happy new year guys! wishing you all the best in hunting the usb bug for nano2g :) 02.26.36 Join Strife89 [0] (~Strife89@adsl-98-80-237-4.mcn.bellsouth.net) 02.47.43 *** Saving seen data "./dancer.seen" 03.03.59 # <[Franklin]> foolsh: do you want to help me define some more units for unitconv? 03.08.35 Quit pamaury (Ping timeout: 240 seconds) 03.47.12 Join krabador [0] (~krabador_@unaffiliated/krabador) 03.53.24 Join Riviera [0] (Riviera@2a03:b0c0:1:d0::10:b001) 03.55.43 # [Franklin]: Sure, but right now, I'm going to go lay down and feel the room spin with my eyes closed 04.04.58 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 04.14.44 Quit tchan (Quit: WeeChat 1.0.1) 04.26.54 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 04.39.33 Quit lebellium_ (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20141222200458]) 04.47.46 *** Saving seen data "./dancer.seen" 04.53.30 Quit Scall (Ping timeout: 265 seconds) 04.59.18 Join Scall [0] (~chat@unaffiliated/scall) 05.13.00 Quit [Franklin] (Ping timeout: 255 seconds) 05.13.21 Join JdGordon [0] (~jonno@ppp118-209-187-163.lns20.mel8.internode.on.net) 05.13.21 Quit JdGordon (Changing host) 05.13.21 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 05.15.15 Quit JdGordon_ (Ping timeout: 255 seconds) 05.23.19 Quit TheSeven (Ping timeout: 272 seconds) 05.24.35 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.39.15 Quit krabador (Quit: Take the time.) 05.57.44 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 05.58.43 Quit JdGordon (Ping timeout: 250 seconds) 06.00.10 # Happy New Year! 06.15.20 Quit Provel (Quit: Provel) 06.18.42 Join Provel [0] (~Provel@75-132-21-111.dhcp.stls.mo.charter.com) 06.47.50 *** Saving seen data "./dancer.seen" 07.29.45 Join ungali [0] (~ungali@S010600226b6da694.cg.shawcable.net) 07.29.46 Quit ungali (Changing host) 07.29.46 Join ungali [0] (~ungali@unaffiliated/ungali) 07.48.08 Quit Provel (Ping timeout: 256 seconds) 07.49.01 Join Provel [0] (~Provel@75-132-21-111.dhcp.stls.mo.charter.com) 08.37.18 Quit JdGordon_ (Ping timeout: 245 seconds) 08.47.52 *** Saving seen data "./dancer.seen" 08.55.08 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 09.33.08 Quit Strife89 (Ping timeout: 244 seconds) 10.10.33 Quit ungali (Quit: ungali) 10.47.53 *** Saving seen data "./dancer.seen" 10.59.25 Quit Zambezi (Ping timeout: 244 seconds) 11.14.07 Join Zambezi [0] (Zulu@bnc.from.dotbnc.com) 11.52.23 Join sobukus [0] (~thomas@nemato.nesselzelle.de) 11.53.15 # I seem to have trouble with rtfm ... can I get some printf-style debugging of a plugin on the console with the UI simulator? 11.56.33 # * sobukus idling around 12.08.53 Join AlexP [0] (~alex@rockbox/staff/AlexP) 12.24.34 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.36.17 # happy new year everyone :) 12.47.54 *** Saving seen data "./dancer.seen" 12.54.02 Join lorenzo92 [0] (~chatzilla@host24-106-dynamic.117-80-r.retail.telecomitalia.it) 12.54.23 # guys, happy new year !!! :) 13.00.49 # kugel: do you think we still need mount bindings to /.rockbox and /Playlists ? 13.02.57 # also, don't forget g#707 13.03.02 # 3Gerrit review #707 at http://gerrit.rockbox.org/r/707 : 3yp-r0: improve the charging code by Lorenzo Miori 13.22.03 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 13.25.08 # lorenzo92: you got a hint about how to debug plugin code in the simulator? 13.26.55 # well, if you just need to do some printfs, do them 13.26.57 # it works 13.27.08 # Hm, fprintf(stderr, ... did nothing 13.27.22 # huh! It should work indeed 13.27.24 # I though I remember it did. 13.28.28 # otherwise, you might also want to enable logf when configure is run + #define LOGF_ENABLED in the source code you want to debug. Every logf("printf format") will be then hopefully displayed in the console 13.28.44 # I'm not really in the simulator business, but it should work 13.31.58 # DEBUGF() certainly works with out-of-the-box simulator builds 13.32.05 # Hm, undef reference to logf ... rb->debugf also doesn't work. 13.32.29 # It just does nothing. Something is strange since I updated my source tree. I think I remember having debug output before. 13.33.12 # in the last days I also remember not seeing logf() output from main code even when enabled sim + logf during configure 13.33.24 # I haven't investigated though since debugf() worked 13.33.52 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 13.34.24 # Hm, I'll figure it out. 13.35.06 # * sobukus thanks for hints and leaves keyboard 13.35.15 # On a plain sim build with no extra options, printf(), fprintf(stdout). fprintf(stderr), and DEBUGF() all work 13.36.13 # gevaerts: OK, thanks for that data point, too. 13.36.37 # I can definitely agree, printf works fine on hosted targets 13.36.54 # gevaerts: do you know by chance how to enable dircache in a simulator build? It's usually disabled in firmware/export/config.h for sims 13.37.13 # thomasjfox: I'm not sure you can 13.37.30 # Isn't that fairly intricatly linked to the underlying FAT implementation? 13.37.34 # crap. I'm pretty sure I've spotted a bad bug and wanted to verify it 13.38.36 # IIRC pamaury once built a sim with disk image support 13.38.43 # Doing that might help 13.39.48 # or I wait for jhMikeS to wake up and ask about his code refactoring ;) 13.40.45 # I think "struct dircache_runinfo" lacks the "static" keyword. Therefore it might contain all kinds of random memory 13.41.01 # I noticed that while looking through all buflib users calling core_alloc 13.41.19 # Especially it will contain a random value for the shrink callback 13.41.57 # Hmmm? 13.42.06 # see firmware/common/dircache.c 13.42.12 # Why would that need static? 13.42.19 # otherwise that memory is not initialized to zero 13.42.31 # That's a global 13.43.26 # ah crap. Tripped over that again 13.43.27 # thanks! 13.43.55 # Static wouldn't *hurt* of course, it doesn't need to be visible elsewhere 13.44.24 # yep 13.44.40 # * thomasjfox doesn't like implicit initialization 13.44.57 # * gevaerts does :) 13.46.20 # gevaerts: yeah but there were problems with disk support in the sim, though I still think it would be very useful to have this 13.46.33 Join davek [0] (~chatzilla@adsl-99-102-47-137.dsl.chcgil.sbcglobal.net) 13.52.16 # Build Server message: 3New build round started. Revision 812406f, 255 builds, 28 clients. 14.08.09 Join Misanthropos [0] (~Misanthro@frnk-4d009d76.pool.mediaWays.net) 14.18.37 Join pimaster [0] (~pimaster@23.94.33.215) 14.25.45 # * lorenzo92 also testing bluetooth module on YPR1 and gets some possibly HCI commands out of a test program (chip init + UART) 14.33.27 Join ZincAlloy [0] (~Adium@pD9EEAE60.dip0.t-ipconnect.de) 14.37.42 # having support for bluetooth in rockbox would be nice, a few devices have bluetooth 14.47.58 *** No seen item changed, no save performed. 14.50.53 Quit Misanthropos (Ping timeout: 244 seconds) 15.00.25 # nice 15.00.56 # I see it completely doable, and I also found a lightweight lib implementing the useful stuff like HCI and some higher protocols 15.02.28 # +1 on bluetooth. And I guess DLNA would be nice to have as well 15.05.40 Quit davek (Quit: ChatZilla 0.9.87 [Iceape 2.7.12/20130119143918]) 15.05.41 # do you know whether or not the other devices are using UART-like interfaces to the bt chip? SPI might be used as well 15.06.40 # the thing is that depending on devices, it's implemented completely differently, if I remember correctly: 15.07.06 # - zen x-fi 3: uart but uses a AT-like protocol, so don't have a HCI interface, much higher level 15.07.25 # - samsung i-don't-remembe-which-one: HCI over uart 15.07.56 # also if you have HCI, you can implement any profile (up to hardware support and wiring) but for high levels it's not the case 15.09.55 Join ender` [0] (krneki@foo.eternallybored.org) 15.11.05 # I don't have the time right now, but the API must clearly be thought to handle both cases. For example, the public API would be high level, with one part to enumerate/connect with devices and then some functions for supported profiles. 15.11.17 # And then a generic implementation based on HCI for the HCI chips 15.20.15 Quit AlexP (Remote host closed the connection) 15.44.56 Join RiD [0] (~RiD@bl22-61-11.dsl.telepac.pt) 15.49.05 # pamaury: thanks for the info! I can sketch something on gerrit later, in the meantime maybe it would be cool also to continue regarding USB 15.49.22 # yeah usb is the priority 15.51.55 # pamaury: chances to know if the samsung mod. i-don't-remembe-which-one is a BCMxxx? 15.52.41 # (oh c'mon look, http://www.freshnrebel.com/it/prodotti/rockbox/) 15.53.04 # speaker set called rockbox 15.53.38 # lorenzo92: http://www.rockbox.org/wiki/SamsungYPT10 15.53.44 # it's a BCM2048 15.53.53 # it's not the only device with bluetooth 15.54.14 # http://www.rockbox.org/wiki/SamsungP2Port 15.54.19 # BCM2048 too 15.54.52 # definitely, HCI over UART. I have found the complete datasheet for BCM2070 (the one in R1, doesn't have FM tuner inside) 15.55.12 # http://www.rockbox.org/wiki/SamsungT9Port but I don't know the chip 15.55.12 # but they are similar in power up pins for example (read similar as same) 15.55.17 # http://www.rockbox.org/wiki/CowonS9Info 15.55.26 # CSR-41814 15.56.27 # I guess most of those are HCI of UART, with a few custom commands to change UART speed and you need to upload the firmware on startup 15.59.21 # are you sure that I need to upload a firmware? hum it seems to me that BCM2070 has an eeprom, and it doesn't appear to exist a firmware file in the rootfs: I might be wrong. 16.00.57 # i'm now reading T9 schematics 16.04.01 # T9: BTTZ0502SA 16.04.54 # wiki is now informed of this ;) 16.05.54 # pamaury: it seems that BCM2070 does UART speed autodetecting because I read the same characters both using 9k6 and 115k2 16.07.35 # I'm just guessing, it depends on the chip 16.07.47 # yes, indeed ;) 16.08.14 Join lebellium [0] (~chatzilla@i16-les01-ntr-212-194-176-149.sfr.lns.abo.bbox.fr) 16.08.48 # lebellium: did you just feel interesting topics? :P 16.11.01 # ? Haven't read the logs yet :) 16.11.11 # pamaury: aha look http://www.ayelec.com/files/wordocs/samsung%20presentation.pdf the BTTxx named chip contains a CSR - xxx device 16.28.01 # hmm, "Haas Surround" directly in the "Sound settings" menu feels like overkill (regarding g#922) 16.28.03 # lorenzo92: okay I read the logs ;) BTW, I will probably buy a YP-T9 in a few time 16.28.07 # 3Gerrit review #922 at http://gerrit.rockbox.org/r/922 : 3three new DSPs by Chiwen Chang 16.28.07 # and Happy New Year :) 16.28.19 # thanks ;) 16.28.47 Join Misanthropos [0] (~Misanthro@frnk-4d010369.pool.mediaWays.net) 16.29.09 # also "haas surround" doesn't give many google results in case people want to learn about it... 16.42.35 Quit Misanthropos (Ping timeout: 240 seconds) 16.48.00 *** Saving seen data "./dancer.seen" 17.00.53 Join [Franklin] [0] (~franklin@unaffiliated/franklin) 17.01.15 # <[Franklin]> hey guys, happy new year! 17.05.14 # [Franklin]: same to you :) 17.05.22 # [Franklin]: here's a good start: http://build.rockbox.org/shownewlog.cgi?rev=812406f;type=cowond2#prob1 17.07.43 # <[Franklin]> looking into it 17.08.28 # the logic looks funny :) "xx == !yy". And "xx != !zz" 17.08.32 # <[Franklin]> yeah 17.10.27 # <[Franklin]> xx != !yy 17.10.54 # <[Franklin]> I think foolsh meant x != y :) 17.11.15 # <[Franklin]> also, I think it should be CONFIG_KEYPAD, not CONFIG_KEYMAP :) 17.12.30 # ha, I didn't even spot that one. 17.12.43 # <[Franklin]> I didn't 'til just now :) 17.12.51 # <[Franklin]> anyway, pushed as G#1093 17.12.56 # 3Gerrit review #1093 at http://gerrit.rockbox.org/r/1093 : 3XWorld: fix some typos in keymaps.h by Franklin Wei 17.13.07 # <[Franklin]> First Gerrit change of 2015 :D 17.13.15 Join Strife89 [0] (~Strife89@adsl-98-80-237-4.mcn.bellsouth.net) 17.14.07 # [Franklin]: did you compile test a f.e. Cowon sim? 17.14.15 Join ploco [0] (dce9b7f9@gateway/web/freenode/ip.220.233.183.249) 17.14.29 # <[Franklin]> I will now 17.15.02 # <[Franklin]> hardware, not sim 17.15.10 # thomasjfox: Try google "Haas Effect" 17.15.22 # <[Franklin]> it'll be a while 17.15.23 # ploco: ha, you read the logs ;) 17.16.17 # ploco: I'm not sure mortal users will make the connection between "haas surround" and "haas effect" 17.17.15 # <[Franklin]> "haas sound" 17.17.24 # <[Franklin]> gives the same top result 17.17.32 # [Franklin]: http://pastebin.com/bHY5p9Si 17.17.49 # <[Franklin]> with G#1093 applied? 17.17.52 # yep 17.17.53 # 3Gerrit review #1093 at http://gerrit.rockbox.org/r/1093 : 3XWorld: fix some typos in keymaps.h by Franklin Wei 17.18.04 # <[Franklin]> weird 17.18.07 # ccache + "make -j8" really speeds up the build 17.18.21 # <[Franklin]> This is my first D2 build 17.18.29 # <[Franklin]> plus beta's down 17.19.35 # <[Franklin]> thomasjfox: I see the error 17.19.47 # <[Franklin]> it's OR'ing the results of the inequalities 17.19.59 # <[Franklin]> so it always evaluates as true 17.20.08 # <[Franklin]> it should be AND'ing them instead, I think 17.21.07 # right 17.22.17 # with the AND change, it compiles without error 17.22.21 # <[Franklin]> ok, pushed it 17.23.01 # I'll try a DX50 sim next 17.24.51 # ok, DX50 chokes because of missing Android SDK. Back to D2... 17.26.54 # ONDAVX777 is fine, too 17.26.58 # I'll push it 17.28.23 # Build Server message: 3New build round started. Revision b0277e4, 255 builds, 28 clients. 17.31.41 # thomasjfox: btw, those Dsps does free memory when disable now. 17.32.34 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 17.32.35 # ploco: I've seen it. Pretty cool 17.32.46 # anyway, I've got to run, friends just visited 17.33.19 # sure. I'm off to bed too. 17.33.23 # g8 17.33.29 Quit ploco (Quit: Page closed) 17.35.09 # [Franklin]: I'll hope the build will be fine now ;) cu 17.35.22 # <[Franklin]> thomasjfox: bb and HNY! 17.35.29 Join RiD [0] (~RiD@bl22-61-11.dsl.telepac.pt) 17.35.39 Join rela [0] (~x@pdpc/supporter/active/rela) 17.36.12 Quit thomasjfox (Quit: Konversation terminated!) 17.36.29 # Build Server message: 3Build round completed after 486 seconds. 17.37.03 # <[Franklin]> ok, all green except for the usual suspects :) 17.40.28 Join AlexP [0] (~alex@rockbox/staff/AlexP) 17.45.43 # gah 17.45.48 # * foolsh hangs his head 17.46.06 # still have to rewrite that 17.46.40 # <[Franklin]> foolsh: fixed ;) 17.48.59 Join scorche [0] (~scorche@rockbox/administrator/scorche) 17.51.38 Quit scorche`` (Ping timeout: 256 seconds) 17.54.24 # <[Franklin]> there's 3 kind of "gallons" >: 17.54.51 # <[Franklin]> I'll just do US gallons for now, because that's all I care :) 17.55.46 # I would suggest only the most popular archaic units, or else the useful plugin you're writing starts to fall in to the useless catagory ;) 17.55.58 # <[Franklin]> lol 17.56.28 # <[Franklin]> hey, at least pounds are base-16 :) 17.56.44 # <[Franklin]> sort of 18.02.43 Quit [Franklin] (Ping timeout: 245 seconds) 18.04.58 Join [Franklin] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) 18.37.02 # gevaerts: do you have any why config.h defines USB_STATUS_BY_EVENT for bootloader usb ? 18.37.07 # *any idea 18.37.38 # and also why this check is enclosed in SWCODEC ???? 18.43.05 # also it seems to me that HAVE_BOOTLOADER_USB_MODE implies HAVE_USBSTACK 18.43.09 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 18.45.06 Join RiD [0] (~RiD@bl22-61-11.dsl.telepac.pt) 18.48.03 *** Saving seen data "./dancer.seen" 18.50.54 # I really feel we are lacking "soc config files" 18.51.33 # we end up having plenty of things duplicated in all target config files or in config.h where they do not belong 18.51.56 # and soc header files are not included in config.h which make then useless for some purposes 19.11.21 # also I'm a bit puzzled by the use of usb_powered() in powermgmt.c and CURRENT_USB 19.11.36 # most targets define CURRENT_USB as 500mA, and it is used for current estimation 19.14.02 # also usb_powered() is highly miss-named, if I understand correctly it means "POWERED state", aka "usb is inserted but for charging only" 19.51.06 Quit [Franklin] (Ping timeout: 245 seconds) 19.56.07 Join [Franklin] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) 20.20.42 Join bertrik [0] (~bertrik@92.69.210.6) 20.20.43 Quit bertrik (Changing host) 20.20.43 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 20.26.53 Quit [Franklin] (Ping timeout: 245 seconds) 20.32.25 Join [Franklin] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) 20.37.05 Nick bertrik is now known as bertrik_trein (~bertrik@rockbox/developer/bertrik) 20.37.47 Nick [Franklin] is now known as [HappyNewYear201 (~franklin@cpe-071-071-039-006.triad.res.rr.com) 20.37.54 Nick [HappyNewYear201 is now known as [Happy2015] (~franklin@cpe-071-071-039-006.triad.res.rr.com) 20.38.12 Quit [Happy2015] (Changing host) 20.38.12 Join [Happy2015] [0] (~franklin@unaffiliated/franklin) 20.38.24 Nick [Happy2015] is now known as [HappyNewYear] (~franklin@unaffiliated/franklin) 20.41.15 Quit bertrik_trein (Ping timeout: 240 seconds) 20.48.07 *** Saving seen data "./dancer.seen" 20.53.01 # gevaerts: ping 20.57.29 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 21.00.16 Quit advcomp2019__ (Ping timeout: 245 seconds) 21.12.00 Join bertrik_trein [0] (~bertrik@92.69.210.6) 21.12.26 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 21.16.53 Join RiD [0] (~RiD@bl22-61-11.dsl.telepac.pt) 21.39.16 Quit bertrik_trein (Quit: Lost terminal) 21.52.54 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 21.55.44 Quit rela (Ping timeout: 265 seconds) 21.56.22 Quit Jinx (Quit: reboot) 21.59.11 Quit [HappyNewYear] (Ping timeout: 244 seconds) 22.02.45 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 22.04.49 Join [HappyNewYear] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) 22.04.54 Join krabador [0] (~krabador_@unaffiliated/krabador) 22.06.59 # please let me know if anything is fishy with my buildclient or nightly/android builds, the HDD on which that stuff was running has failed a few days ago 22.07.32 # everything should be back to normal now, but if anything is still acting up, please notify me 22.07.41 Join rela [0] (~x@pdpc/supporter/active/rela) 22.12.50 Quit rela (Ping timeout: 272 seconds) 22.25.43 Quit [HappyNewYear] (Changing host) 22.25.43 Join [HappyNewYear] [0] (~franklin@unaffiliated/franklin) 22.37.36 Join einhirn [0] (~Miranda@p4FC10912.dip0.t-ipconnect.de) 22.40.40 Quit krabador (Quit: Take the time.) 22.48.08 *** Saving seen data "./dancer.seen" 22.48.51 Quit [HappyNewYear] (Ping timeout: 240 seconds) 22.55.18 Quit lorenzo92 (Ping timeout: 264 seconds) 23.01.48 Quit Strife89 (Ping timeout: 250 seconds) 23.03.08 Join AlwaysHi- [0] (~AlwaysHig@104.131.156.164) 23.03.26 Join soap_ [0] (~soap@rockbox/staff/soap) 23.03.42 Join Scromple_ [0] (~Simon@27.127.199.230) 23.03.42 Quit Scr0mple (Read error: Connection reset by peer) 23.04.02 Quit Zambezi (Ping timeout: 250 seconds) 23.04.36 Join skx_netb [0] (~sakax@unaffiliated/sakax) 23.05.30 # pamaury: pong? 23.05.45 Quit Scall (Ping timeout: 256 seconds) 23.05.45 Quit sakax (Ping timeout: 256 seconds) 23.05.45 Quit AlwaysHigh (Ping timeout: 256 seconds) 23.05.45 Quit soap (Ping timeout: 256 seconds) 23.05.46 Join lebellium_ [0] (~chatzilla@i16-les01-ntr-212-194-176-149.sfr.lns.abo.bbox.fr) 23.05.48 Quit thomasjfox (Ping timeout: 264 seconds) 23.05.48 Join Zambezi_ [0] (Zulu@bnc.from.dotbnc.com) 23.05.58 Join Scall- [0] (~chat@unaffiliated/scall) 23.05.59 Nick Scall- is now known as Scall (~chat@unaffiliated/scall) 23.06.00 # I have a few thoughts on USB, I'd like your opinion 23.06.18 Join HoloIRCUser1 [0] (~holoirc@ip-83-134-240-226.dsl.scarlet.be) 23.06.29 # first, I don't understand what usb_powered() means in the current code 23.06.33 Nick HoloIRCUser1 is now known as HoloIRCUser1hf (~holoirc@ip-83-134-240-226.dsl.scarlet.be) 23.06.41 # it returns true if usb_state == USB_POWERED 23.07.04 # versus usb_inserted() which checks for usb_state == USB_POWERED or USB_INSERTED 23.07.57 # the problem is that my understand of usb.c is that USB_POWERED is now only a transitional state when a host is present, or a permanent state when charging only, so it does not represent the usb "powering state" 23.08.05 Part HoloIRCUser1hf 23.08.34 # * gevaerts nods 23.09.04 # so my question is: did usb_powered() changed meaning without anyone noticing when usb rework was done ? 23.09.10 Quit lebellium (Ping timeout: 250 seconds) 23.09.11 Nick lebellium_ is now known as lebellium (~chatzilla@i16-les01-ntr-212-194-176-149.sfr.lns.abo.bbox.fr) 23.09.52 # Hmmm 23.10.41 # Not that many things call usb_powered() 23.10.55 # yeah which brings my second question 23.11.01 # It probably did subtly change 23.11.12 # the only use of usb_powered() is strange 23.11.23 # There's another one, in apps/main.c 23.11.38 # Oh, and in battery_bench 23.11.42 # yeah, this one I don't understand, maybe there is something subtle there 23.12.04 # the one in the plugin clearly shows that usb_powered() seems to have changed meaning 23.12.13 # Well 23.12.15 Quit bluebrother (Disconnected by services) 23.12.20 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 23.12.27 # I don't think it's changed meaning as such 23.12.39 # It's just that we got a better way to do things along the way 23.13.31 # what do you mean ? 23.13.55 # I think usb_powered() still returns 1 in exactly the same circumstances it did before 23.14.31 Quit fs-bluebot (Ping timeout: 265 seconds) 23.14.43 # hum, I'm not so sure, or else it's weird because if you plug usb and the usb stack kicks in, the usb_state is USB_INSERTED so usb_powered() returns false even though the device is powered/charging from usb 23.16.07 # Yes, but the bit in powermgmt.c seems to explicitly handle that, I think 23.16.16 Join fs-bluebot [0] (~fs-bluebo@f053155178.adsl.alicedsl.de) 23.17.09 # And that's been untouched for ages 23.17.36 # ok, then the name is really misleading 23.18.05 # it has nothing to do with the powering state 23.18.11 # well not much 23.18.40 # There's also the wps tag that's not documented :) 23.18.48 # [Saint]: what exactly does %bu mean? 23.18.58 # haha 23.19.32 # I'm not saying you're wrong, it's just an inconsistency that predates me, so I don't know... 23.20.52 # I'd just like to get the documentation right, and possibly rename the function :) 23.22.49 # do you have targets in mind which can do usb but cannot charge or be powered from it ? 23.23.03 # One issue with things like USB_INSERTED is that they're a return value from usb_detect() and a state in usb.c, where it means subtly different things 23.23.11 # The archoses, at least 23.23.26 # I built a list of defines here: https://gist.githubusercontent.com/pamaury/b3db692c1880ef97a0f2/raw/f4a2740a351bf8304b6abcb9d5666c4978b1d9e4/usb_defines.txt 23.23.27 # Maybe not the ondios, not sure about those, but definitely the player and the recorder 23.24.41 # strange, the player and recorder don't define HAVE_USBSTACK my tool says 23.25.00 # Ah, you mean software USB? 23.25.32 # ah I forgot about hardware USB again 23.27.38 # <[Saint]> gevaerts: %bu is, iirc, "is USB plugged? " 23.28.14 # [Saint]: what should it return if USB is in mass storage mode? 23.28.29 # (apart from "Who cares? You can't use skins then anyway!") 23.28.44 # <[Saint]> well...you /can/... 23.28.50 # <[Saint]> Just, not reliably. 23.30.24 # pamaury: in the software USB world, your defines list also says some RK27xx things, some ondas, and the ZVMs don't use USB power 23.30.38 # Those might be bugs though 23.30.54 # <[Saint]> gevaerts: regarding your question, I'm not sure it matters... 23.30.59 # <[Saint]> "10:12 JdGordon %bu is being "deprecated".. enter %up 23.30.59 # <[Saint]> 10:12 JdGordon becuase the line lengths are not static" 23.31.06 # <[Saint]> it seems its just a hanger on. 23.31.13 # it looks like a bug, on the other hand, HAVE_USB_POWER is so nearly useless no one noticed 23.31.22 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 23.31.24 # <[Saint]> leave it to do whatever it may or may not do... 23.31.29 # [Saint]: the thing is, we want to figure out what usb_powered is supposed to mean, and since %bu is just that... :) 23.31.48 # <[Saint]> well, I think %up is what you want now. 23.32.16 # <[Saint]> you'd likely have to ask JdGordon, I've lost track of what he considers viable/deprecated. 23.32.35 # <[Saint]> There's a fair few tags that exist still, but /really. shouldn't be used. 23.33.17 # <[Saint]> IIRC he bailed half way through the USB skinning debacle, so I'm not confident about wither. 23.33.38 # [Saint]: that's where you're mistaken. We want to know what usb_powered() means, we don't care about what tags you should or shouldn't use :) 23.33.45 # it seems to mean that the charging source should be left to power_input_status() 23.34.25 # however main targets probably wrongly return POWER_INPUT_MAIN_CHARGER instead of POWER_INPUT_USB_CHARGER 23.34.36 # *many 23.34.54 # Could well be 23.35.42 # well, the doc in power.h is ambiguous, it *seems* to say that main == usb if those are not discernable 23.35.51 # Hmmmm 23.36.13 # pamaury: only the archoses have CURRENT_USB set to something meaningful 23.37.31 # So the powermgmt bit for relevant targets really is usb_inserted() || usb_powered(), where the usb_powered() really is redundant anyway 23.37.31 # I'm not sure the value is *useful* because runcurrent() doc says it estimates the consumption for the run time, clearly it doesn't consume 500mA just to run, or I don't understand the meaning of it 23.37.43 # Well, no 23.37.56 # But it probably assumes the disk is spinning all the time while connected 23.40.11 # hum, if usb_inserted() || usb_powered() is true (which is the case when usb is plugged), then current = CURRENT_USB = 500mA 23.40.24 # so runcurrent() will returns something >= 500mA 23.40.43 # then it does CURRENT_MAX_CHG - runcurrent() 23.40.44 Join [HappyNewYear] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) 23.40.47 Quit ender` (Quit: History is a set of lies agreed upon. -- Napoleon Bonaparte) 23.41.10 # which is 350mA by default 23.41.17 # and the archos don't define it, so it's the default 23.42.20 # Remember that if those are charging, it's not over USB 23.44.11 # hum 23.44.38 # but then the check is just usb_inserted() so my point still holds ? 23.44.51 # (because they don't have HAVE_USB_POWER) 23.45.09 # Good point 23.45.22 # so I don't understand what CURRENT_USB is supposed to represent 23.46.20 # it seems to me it should be "consumption when usb plugged (exclusing charging)" and some target define it as "maximum usb current draw" 23.47.09 # So usb_powered() is irrelevant in powermgmt.c, and can almost certainly be replaced (and maybe should be) by usb_inserted() in the skin engine and battery_bench, so the only remaining case is main.c 23.47.11 # I'm sorry to bother you, I'm just trying to understand this mess :) 23.47.34 # yeah, we should probably remove usb_powered(), now in main.c I don't understand the comment 23.47.34 # I *never* looked into powermgmt, so your guess is as good as mine :) 23.48.11 # I'm not sure I understand the goal of this loop in main.c 23.48.28 # So-called early USB 23.49.05 # it prevents full init if USB is plugged because with threads being created it would be mess 23.49.08 # ? 23.49.18 # also with disk mounting 23.49.25 # It allows USB before the disk has been touched 23.49.30 # ok 23.49.32 # make sense 23.49.40 # Basically the equivalent of bootloader USB on bootloader-less targets 23.49.54 # Which, come to think of it, might be the archoses again :) 23.50.12 # Although it *could* be flashed rockbox on the irivers, not sure about those 23.50.13 # Build Server message: 3New build round started. Revision 9076b43, 255 builds, 28 clients. 23.50.32 # I *think* this usb_powered() is correct: if usb is plugged to a charger only, usb_detect() is also USB_INSERTED and the loop would never stop 23.50.49 # Yes 23.50.50 # but if there is no host (USB_POWERED) then you can safely continue booting 23.52.14 # however this seems slightly buggy because USB_POWERED is also a transitional state 23.52.40 # or does the main loop also needs to ack the SYS_USB_CONNECTED message ? 23.52.51 # No 23.52.53 # I think 23.53.23 # * gevaerts isn't sure 23.53.57 # hum, that's nearly ok but there is a race condition I think: 23.54.26 # 1) when the host is detected, usb_state is set to USB_POWERED and SYS_USB_CONNECTED is broadcast 23.54.29 # Hmmm, it probably does 23.54.43 # It depends on the timeout there I think 23.54.48 # Which is rather risky 23.54.49 # 2) so button_get_w_tmo() returns SYS_USB_CONNECTED and usb gui is started 23.55.14 # but if usb_powered() is seems before the call to the button, or a button is pressed before the timeout, that's a potential disaster 23.57.51 # I suspect you're right 23.58.36 # I thought there was a timeout on host detection, was I wrong ?