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 |
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:00 |
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 | sakax | 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:00 |
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 | foolsh | [Franklin]: Sure, but right now, I'm going to go lay down and feel the room spin with my eyes closed |
04:00 |
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:00 |
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 |
06:00:10 | the-kyle | 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:00 |
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:00 |
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:00 |
09:33:08 | | Quit Strife89 (Ping timeout: 244 seconds) |
10:00 |
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:00 |
11:14:07 | | Join Zambezi [0] (Zulu@bnc.from.dotbnc.com) |
11:52:23 | | Join sobukus [0] (~thomas@nemato.nesselzelle.de) |
11:53:15 | sobukus | 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:00 |
12:08:53 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
12:24:34 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
12:36:17 | pamaury | 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 | lorenzo92 | guys, happy new year !!! :) |
13:00 |
13:00:49 | lorenzo92 | kugel: do you think we still need mount bindings to /.rockbox and /Playlists ? |
13:02:57 | lorenzo92 | also, don't forget g#707 |
13:03:02 | fs-bluebot | Gerrit review #707 at http://gerrit.rockbox.org/r/707 : yp-r0: improve the charging code by Lorenzo Miori |
13:22:03 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
13:25:08 | sobukus | lorenzo92: you got a hint about how to debug plugin code in the simulator? |
13:26:55 | lorenzo92 | well, if you just need to do some printfs, do them |
13:26:57 | lorenzo92 | it works |
13:27:08 | sobukus | Hm, fprintf(stderr, ... did nothing |
13:27:22 | lorenzo92 | huh! It should work indeed |
13:27:24 | sobukus | I though I remember it did. |
13:28:28 | lorenzo92 | 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 | lorenzo92 | I'm not really in the simulator business, but it should work |
13:31:58 | thomasjfox | DEBUGF() certainly works with out-of-the-box simulator builds |
13:32:05 | sobukus | Hm, undef reference to logf ... rb->debugf also doesn't work. |
13:32:29 | sobukus | It just does nothing. Something is strange since I updated my source tree. I think I remember having debug output before. |
13:33:12 | thomasjfox | in the last days I also remember not seeing logf() output from main code even when enabled sim + logf during configure |
13:33:24 | thomasjfox | I haven't investigated though since debugf() worked |
13:33:52 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
13:34:24 | sobukus | Hm, I'll figure it out. |
13:35:06 | * | sobukus thanks for hints and leaves keyboard |
13:35:15 | gevaerts | On a plain sim build with no extra options, printf(), fprintf(stdout). fprintf(stderr), and DEBUGF() all work |
13:36:13 | sobukus | gevaerts: OK, thanks for that data point, too. |
13:36:37 | lorenzo92 | I can definitely agree, printf works fine on hosted targets |
13:36:54 | thomasjfox | 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 | gevaerts | thomasjfox: I'm not sure you can |
13:37:30 | gevaerts | Isn't that fairly intricatly linked to the underlying FAT implementation? |
13:37:34 | thomasjfox | crap. I'm pretty sure I've spotted a bad bug and wanted to verify it |
13:38:36 | gevaerts | IIRC pamaury once built a sim with disk image support |
13:38:43 | gevaerts | Doing that might help |
13:39:48 | thomasjfox | or I wait for jhMikeS to wake up and ask about his code refactoring ;) |
13:40:45 | thomasjfox | I think "struct dircache_runinfo" lacks the "static" keyword. Therefore it might contain all kinds of random memory |
13:41:01 | thomasjfox | I noticed that while looking through all buflib users calling core_alloc |
13:41:19 | thomasjfox | Especially it will contain a random value for the shrink callback |
13:41:57 | gevaerts | Hmmm? |
13:42:06 | thomasjfox | see firmware/common/dircache.c |
13:42:12 | gevaerts | Why would that need static? |
13:42:19 | thomasjfox | otherwise that memory is not initialized to zero |
13:42:31 | gevaerts | That's a global |
13:43:26 | thomasjfox | ah crap. Tripped over that again |
13:43:27 | thomasjfox | thanks! |
13:43:55 | gevaerts | Static wouldn't *hurt* of course, it doesn't need to be visible elsewhere |
13:44:24 | thomasjfox | yep |
13:44:40 | * | thomasjfox doesn't like implicit initialization |
13:44:57 | * | gevaerts does :) |
13:46:20 | pamaury | 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 | fs-bluebot | Build Server message: New build round started. Revision 812406f, 255 builds, 28 clients. |
14:00 |
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 | pamaury | 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 |
15:00:25 | lorenzo92 | nice |
15:00:56 | lorenzo92 | 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 | ZincAlloy | +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 | lorenzo92 | 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 | pamaury | the thing is that depending on devices, it's implemented completely differently, if I remember correctly: |
15:07:06 | pamaury | - zen x-fi 3: uart but uses a AT-like protocol, so don't have a HCI interface, much higher level |
15:07:25 | pamaury | - samsung i-don't-remembe-which-one: HCI over uart |
15:07:56 | pamaury | 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 | pamaury | 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 | pamaury | 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 | lorenzo92 | 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 | pamaury | yeah usb is the priority |
15:51:55 | lorenzo92 | pamaury: chances to know if the samsung mod. i-don't-remembe-which-one is a BCMxxx? |
15:52:41 | lorenzo92 | (oh c'mon look, http://www.freshnrebel.com/it/prodotti/rockbox/) |
15:53:04 | lorenzo92 | speaker set called rockbox |
15:53:38 | pamaury | lorenzo92: http://www.rockbox.org/wiki/SamsungYPT10 |
15:53:44 | pamaury | it's a BCM2048 |
15:53:53 | pamaury | it's not the only device with bluetooth |
15:54:14 | pamaury | http://www.rockbox.org/wiki/SamsungP2Port |
15:54:19 | pamaury | BCM2048 too |
15:54:52 | lorenzo92 | 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 | pamaury | http://www.rockbox.org/wiki/SamsungT9Port but I don't know the chip |
15:55:12 | lorenzo92 | but they are similar in power up pins for example (read similar as same) |
15:55:17 | pamaury | http://www.rockbox.org/wiki/CowonS9Info |
15:55:26 | pamaury | CSR-41814 |
15:56:27 | pamaury | 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 | lorenzo92 | 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 |
16:00:57 | lorenzo92 | i'm now reading T9 schematics |
16:04:01 | lorenzo92 | T9: BTTZ0502SA |
16:04:54 | lorenzo92 | wiki is now informed of this ;) |
16:05:54 | lorenzo92 | pamaury: it seems that BCM2070 does UART speed autodetecting because I read the same characters both using 9k6 and 115k2 |
16:07:35 | pamaury | I'm just guessing, it depends on the chip |
16:07:47 | lorenzo92 | yes, indeed ;) |
16:08:14 | | Join lebellium [0] (~chatzilla@i16-les01-ntr-212-194-176-149.sfr.lns.abo.bbox.fr) |
16:08:48 | lorenzo92 | lebellium: did you just feel interesting topics? :P |
16:11:01 | lebellium | ? Haven't read the logs yet :) |
16:11:11 | lorenzo92 | pamaury: aha look http://www.ayelec.com/files/wordocs/samsung%20presentation.pdf the BTTxx named chip contains a CSR - xxx device |
16:28:01 | thomasjfox | hmm, "Haas Surround" directly in the "Sound settings" menu feels like overkill (regarding g#922) |
16:28:03 | lebellium | lorenzo92: okay I read the logs ;) BTW, I will probably buy a YP-T9 in a few time |
16:28:07 | fs-bluebot | Gerrit review #922 at http://gerrit.rockbox.org/r/922 : three new DSPs by Chiwen Chang |
16:28:07 | lebellium | and Happy New Year :) |
16:28:19 | lorenzo92 | thanks ;) |
16:28:47 | | Join Misanthropos [0] (~Misanthro@frnk-4d010369.pool.mediaWays.net) |
16:29:09 | thomasjfox | 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 |
17:00:53 | | Join [Franklin] [0] (~franklin@unaffiliated/franklin) |
17:01:15 | [Franklin] | hey guys, happy new year! |
17:05:14 | thomasjfox | [Franklin]: same to you :) |
17:05:22 | thomasjfox | [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 | thomasjfox | 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 | thomasjfox | 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 | fs-bluebot | Gerrit review #1093 at http://gerrit.rockbox.org/r/1093 : XWorld: 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 | thomasjfox | [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 | ploco | thomasjfox: Try google "Haas Effect" |
17:15:22 | [Franklin] | it'll be a while |
17:15:23 | thomasjfox | ploco: ha, you read the logs ;) |
17:16:17 | thomasjfox | 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 | thomasjfox | [Franklin]: http://pastebin.com/bHY5p9Si |
17:17:49 | [Franklin] | with G#1093 applied? |
17:17:52 | thomasjfox | yep |
17:17:53 | fs-bluebot | Gerrit review #1093 at http://gerrit.rockbox.org/r/1093 : XWorld: fix some typos in keymaps.h by Franklin Wei |
17:18:04 | [Franklin] | weird |
17:18:07 | thomasjfox | 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 | thomasjfox | right |
17:22:17 | thomasjfox | with the AND change, it compiles without error |
17:22:21 | [Franklin] | ok, pushed it |
17:23:01 | thomasjfox | I'll try a DX50 sim next |
17:24:51 | thomasjfox | ok, DX50 chokes because of missing Android SDK. Back to D2... |
17:26:54 | thomasjfox | ONDAVX777 is fine, too |
17:26:58 | thomasjfox | I'll push it |
17:28:23 | fs-bluebot | Build Server message: New build round started. Revision b0277e4, 255 builds, 28 clients. |
17:31:41 | ploco | 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 | thomasjfox | ploco: I've seen it. Pretty cool |
17:32:46 | thomasjfox | anyway, I've got to run, friends just visited |
17:33:19 | ploco | sure. I'm off to bed too. |
17:33:23 | thomasjfox | g8 |
17:33:29 | | Quit ploco (Quit: Page closed) |
17:35:09 | thomasjfox | [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 | fs-bluebot | Build Server message: Build 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 | foolsh | gah |
17:45:48 | * | foolsh hangs his head |
17:46:06 | foolsh | 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 | foolsh | 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:00 |
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 | pamaury | gevaerts: do you have any why config.h defines USB_STATUS_BY_EVENT for bootloader usb ? |
18:37:07 | pamaury | *any idea |
18:37:38 | pamaury | and also why this check is enclosed in SWCODEC ???? |
18:43:05 | pamaury | 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 | pamaury | I really feel we are lacking "soc config files" |
18:51:33 | pamaury | 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 | pamaury | and soc header files are not included in config.h which make then useless for some purposes |
19:00 |
19:11:21 | pamaury | also I'm a bit puzzled by the use of usb_powered() in powermgmt.c and CURRENT_USB |
19:11:36 | pamaury | most targets define CURRENT_USB as 500mA, and it is used for current estimation |
19:14:02 | pamaury | 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:00 |
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 | pamaury | gevaerts: ping |
20:57:29 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
21:00 |
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:00 |
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 | TheSeven | 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 | TheSeven | 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:00 |
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 | gevaerts | 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 | pamaury | 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 | pamaury | 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 | pamaury | it returns true if usb_state == USB_POWERED |
23:07:04 | pamaury | versus usb_inserted() which checks for usb_state == USB_POWERED or USB_INSERTED |
23:07:57 | pamaury | 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 | pamaury | 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 | gevaerts | Hmmm |
23:10:41 | gevaerts | Not that many things call usb_powered() |
23:10:55 | pamaury | yeah which brings my second question |
23:11:01 | gevaerts | It probably did subtly change |
23:11:12 | pamaury | the only use of usb_powered() is strange |
23:11:23 | gevaerts | There's another one, in apps/main.c |
23:11:38 | gevaerts | Oh, and in battery_bench |
23:11:42 | pamaury | yeah, this one I don't understand, maybe there is something subtle there |
23:12:04 | pamaury | the one in the plugin clearly shows that usb_powered() seems to have changed meaning |
23:12:13 | gevaerts | Well |
23:12:15 | | Quit bluebrother (Disconnected by services) |
23:12:20 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
23:12:27 | gevaerts | I don't think it's changed meaning as such |
23:12:39 | gevaerts | It's just that we got a better way to do things along the way |
23:13:31 | pamaury | what do you mean ? |
23:13:55 | gevaerts | 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 | pamaury | 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 | gevaerts | 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 | gevaerts | And that's been untouched for ages |
23:17:36 | pamaury | ok, then the name is really misleading |
23:18:05 | pamaury | it has nothing to do with the powering state |
23:18:11 | pamaury | well not much |
23:18:40 | gevaerts | There's also the wps tag that's not documented :) |
23:18:48 | gevaerts | [Saint]: what exactly does %bu mean? |
23:18:58 | pamaury | haha |
23:19:32 | gevaerts | I'm not saying you're wrong, it's just an inconsistency that predates me, so I don't know... |
23:20:52 | pamaury | I'd just like to get the documentation right, and possibly rename the function :) |
23:22:49 | pamaury | do you have targets in mind which can do usb but cannot charge or be powered from it ? |
23:23:03 | gevaerts | 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 | gevaerts | The archoses, at least |
23:23:26 | pamaury | I built a list of defines here: https://gist.githubusercontent.com/pamaury/b3db692c1880ef97a0f2/raw/f4a2740a351bf8304b6abcb9d5666c4978b1d9e4/usb_defines.txt |
23:23:27 | gevaerts | Maybe not the ondios, not sure about those, but definitely the player and the recorder |
23:24:41 | pamaury | strange, the player and recorder don't define HAVE_USBSTACK my tool says |
23:25:00 | gevaerts | Ah, you mean software USB? |
23:25:32 | pamaury | ah I forgot about hardware USB again |
23:27:38 | [Saint] | gevaerts: %bu is, iirc, "is USB plugged? <yes|no|fucked if I know>" |
23:28:14 | gevaerts | [Saint]: what should it return if USB is in mass storage mode? |
23:28:29 | gevaerts | (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 | gevaerts | 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 | gevaerts | Those might be bugs though |
23:30:54 | [Saint] | gevaerts: regarding your question, I'm not sure it matters... |
23:30:59 | [Saint] | "10:12JdGordon%bu is being "deprecated".. enter %up |
23:30:59 | [Saint] | 10:12JdGordonbecuase the line lengths are not static" |
23:31:06 | [Saint] | it seems its just a hanger on. |
23:31:13 | pamaury | 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 | gevaerts | [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 | gevaerts | [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 | pamaury | it seems to mean that the charging source should be left to power_input_status() |
23:34:25 | pamaury | however main targets probably wrongly return POWER_INPUT_MAIN_CHARGER instead of POWER_INPUT_USB_CHARGER |
23:34:36 | pamaury | *many |
23:34:54 | gevaerts | Could well be |
23:35:42 | pamaury | well, the doc in power.h is ambiguous, it *seems* to say that main == usb if those are not discernable |
23:35:51 | gevaerts | Hmmmm |
23:36:13 | gevaerts | pamaury: only the archoses have CURRENT_USB set to something meaningful |
23:37:31 | gevaerts | So the powermgmt bit for relevant targets really is usb_inserted() || usb_powered(), where the usb_powered() really is redundant anyway |
23:37:31 | pamaury | 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 | gevaerts | Well, no |
23:37:56 | gevaerts | But it probably assumes the disk is spinning all the time while connected |
23:40:11 | pamaury | hum, if usb_inserted() || usb_powered() is true (which is the case when usb is plugged), then current = CURRENT_USB = 500mA |
23:40:24 | pamaury | so runcurrent() will returns something >= 500mA |
23:40:43 | pamaury | 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 | pamaury | which is 350mA by default |
23:41:17 | pamaury | and the archos don't define it, so it's the default |
23:42:20 | gevaerts | Remember that if those are charging, it's not over USB |
23:44:11 | pamaury | hum |
23:44:38 | pamaury | but then the check is just usb_inserted() so my point still holds ? |
23:44:51 | pamaury | (because they don't have HAVE_USB_POWER) |
23:45:09 | gevaerts | Good point |
23:45:22 | pamaury | so I don't understand what CURRENT_USB is supposed to represent |
23:46:20 | pamaury | 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 | gevaerts | 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 | pamaury | I'm sorry to bother you, I'm just trying to understand this mess :) |
23:47:34 | pamaury | yeah, we should probably remove usb_powered(), now in main.c I don't understand the comment |
23:47:34 | gevaerts | I *never* looked into powermgmt, so your guess is as good as mine :) |
23:48:11 | pamaury | I'm not sure I understand the goal of this loop in main.c |
23:48:28 | gevaerts | So-called early USB |
23:49:05 | pamaury | it prevents full init if USB is plugged because with threads being created it would be mess |
23:49:08 | pamaury | ? |
23:49:18 | pamaury | also with disk mounting |
23:49:25 | gevaerts | It allows USB before the disk has been touched |
23:49:30 | pamaury | ok |
23:49:32 | pamaury | make sense |
23:49:40 | gevaerts | Basically the equivalent of bootloader USB on bootloader-less targets |
23:49:54 | gevaerts | Which, come to think of it, might be the archoses again :) |
23:50:12 | gevaerts | Although it *could* be flashed rockbox on the irivers, not sure about those |
23:50:13 | fs-bluebot | Build Server message: New build round started. Revision 9076b43, 255 builds, 28 clients. |
23:50:32 | pamaury | 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 | gevaerts | Yes |
23:50:50 | pamaury | but if there is no host (USB_POWERED) then you can safely continue booting |
23:52:14 | pamaury | however this seems slightly buggy because USB_POWERED is also a transitional state |
23:52:40 | pamaury | or does the main loop also needs to ack the SYS_USB_CONNECTED message ? |
23:52:51 | gevaerts | No |
23:52:53 | gevaerts | I think |
23:53:23 | * | gevaerts isn't sure |
23:53:57 | pamaury | hum, that's nearly ok but there is a race condition I think: |
23:54:26 | pamaury | 1) when the host is detected, usb_state is set to USB_POWERED and SYS_USB_CONNECTED is broadcast |
23:54:29 | gevaerts | Hmmm, it probably does |
23:54:43 | gevaerts | It depends on the timeout there I think |
23:54:48 | gevaerts | Which is rather risky |
23:54:49 | pamaury | 2) so button_get_w_tmo() returns SYS_USB_CONNECTED and usb gui is started |
23:55:14 | pamaury | 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 | gevaerts | I suspect you're right |
23:58:36 | pamaury | I thought there was a timeout on host detection, was I wrong ? |