--- Log for 20.10.116  Server: karatkievich.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 12 days and 2 hours ago

00.02.46 Quit    fishbowlkraken (Quit: Page closed)
00.08.58 Quit    ved (Ping timeout: 260 seconds)
00.17.36 Quit    tchan (Quit: WeeChat 1.4)
00.28.24 Quit    ender` (Quit: I always wanted to have a job in construction or at a hardware store just so I could eat some pink cotton candy in front of someone in a situation that would make them think I was eating fiberglass insulation.	— Chris Hallbeck)
00.28.44 Quit    girafe (Read error: Connection reset by peer)
00.35.02 Join    tchan [0] (~tchan@c-50-129-174-2.hsd1.il.comcast.net)
00.35.02 Quit    tchan (Changing host)
00.35.02 Join    tchan [0] (~tchan@lunar-linux/developer/tchan)
00.39.58 Quit    ZincAlloy (Quit: Leaving.)
01.04.28 Quit    rogeliodh (Quit: rogeliodh)
01.08.10 Quit    pamaury (Ping timeout: 252 seconds)
01.39.35 ***     Saving seen data "./dancer.seen"
01.52.19 Join    Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217)
02.01.49 #       <Bilgus> I was looking through commits and noticed http://gerrit.rockbox.org/r/#/c/1277/  Change 1277 - Merged  GUI boost for any button I noticed this also removed the previous contexts I was wondering if there was any particular reasoning behind this?
02.43.11 #       <__builtin> Bilgus: it makes sense that the user only cares about speed when they're directly interacting with the system
02.43.21 #       <__builtin> (though I'm not exactly sure what the author had in mind)
02.44.05 #       <__builtin> and also the newer context should encompass the previous ones
03.06.50 Join    Bilgus1 [0] (4cf32773@gateway/web/freenode/ip.76.243.39.115)
03.10.34 #       <Bilgus1> Well it does encompass the contexts (as in all of them) I suppose this would make everything more responsive but i think in most instances this is just needlessly boosting the processor
03.18.18 Join    saratoga [0] (49722379@gateway/web/freenode/ip.73.114.35.121)
03.18.45 #       <saratoga> Bilgus1:  the original gui boost system was a compromise between the needs of some devices (mostly ipods) that needed faster processing of wheel events
03.19.33 #       <saratoga> eventually it didn't make much sense to keep it restricted to only wheel devices (eg fuze) when the clip players with the same processor often couldn't have as low an idle frequency
03.19.38 #       <saratoga> without the UI lagging
03.20.38 #       <Bilgus1> so then the compromise was expanded to always boost with the addition of processor/voltage scaling?
03.20.42 #       <saratoga> we could always enable the old behavior on a new device if it made sense of course
03.20.57 #       <saratoga> yeah so that we could lower the normal clock even lower
03.21.24 #       <saratoga> we considered doing this on the old ipod video back in the day but decided not to for various reasons
03.23.17 #       <saratoga> but its more efficient to have the lowest possible clock and then just speed it up if the UI is needed
03.23.28 #       <Bilgus1> makes sense..
03.24.01 #       <saratoga> we could probably be more efficient and have multiple clock frequencies for gui boost, but the fraction of power consumed by boost on UI is very small 
03.25.52 #       <Bilgus1> I was kinda wondering how much power/ clock cycles were used for each boost/unboost being that every button press is boosting no matter the context.. wps track skip for instance
03.26.46 #       <saratoga> it boosts for a set period (grep GUI_BOOST_TIMEOUT, i forget how long it is)
03.26.58 #       <saratoga> so everytime you hit a button the timer is reset
03.27.30 #       <saratoga> but it will usually be boosted for way less time than the screen is on, and boosting uses a tiny fraction of the power as the back light
03.29.24 #       <Bilgus1> Ive already added selective backlighting i was just following this to the next power savings possibility and wondering if there were any downsides
03.30.34 #       <saratoga> you can just disable it in the config file for you device if you want to test
03.30.50 #       <saratoga> assuming its already enabled that is
03.31.44 #       <Bilgus1> thx
03.36.06 Quit    Bilgus1 (Quit: Page closed)
03.36.37 Quit    saratoga (Quit: Page closed)
03.39.37 ***     Saving seen data "./dancer.seen"
04.07.27 Quit    prof_wolfff (Ping timeout: 252 seconds)
04.07.36 Quit    zoktar (Ping timeout: 240 seconds)
04.10.13 Join    zoktar [0] (~zoktar@78-70-243-143-no186.tbcn.telia.com)
04.10.13 Quit    zoktar (Changing host)
04.10.13 Join    zoktar [0] (~zoktar@unaffiliated/zoktar)
04.14.46 Join    sbach [0] (~sbach@107.189.42.74)
04.20.12 Join    prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com)
04.32.38 Quit    sbach (Remote host closed the connection)
04.32.38 Quit    Rower (Write error: Broken pipe)
04.33.37 Join    sbach [0] (~sbach@107.189.42.74)
04.33.39 Join    Rower [0] (husvagn@d83-183-134-99.cust.tele2.se)
04.49.29 #       <Bilgus> ok so Ive been tracking down the timeout of GUI_BOOST_TIMEOUT it is defined as (HZ) which is scattered all over the code anyone know where this define originates or even the value?
05.20.49 #       <Bilgus> nm firmware/kernel/include/tick.h  #define HZ      100 /* number of ticks per second */
05.29.25 #       <Bilgus> * Timeout for gui boost in seconds. */ #define GUI_BOOST_TIMEOUT (HZ)  < so this is actually timeout in ticks.. or atm 1 second what kind of overhead is required to boost/unboost the cpu could benefit be seen with a lower or higher timeout?
05.39.38 ***     Saving seen data "./dancer.seen"
05.47.10 Quit    michaelni (Ping timeout: 256 seconds)
06.00.06 Join    michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at)
06.54.15 Join    ender` [0] (krneki@foo.eternallybored.org)
06.56.49 Quit    dfkt (Disconnected by services)
06.56.59 Join    dfkt_ [0] (~dfkt@unaffiliated/dfkt)
07.06.45 Quit    dfkt_ (Quit: SIC GORGIAMVS ALLOS SVBJECTATOS NVNC.)
07.07.13 Join    dfkt [0] (~dfkt@unaffiliated/dfkt)
07.39.39 ***     Saving seen data "./dancer.seen"
08.34.00 Quit    amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
08.34.01 Quit    pixelma (Quit: .)
08.36.42 Join    pixelma [0] (pixelma@rockbox/staff/pixelma)
08.36.42 Join    amiconn [0] (amiconn@rockbox/developer/amiconn)
08.40.23 Join    einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09.03.33 Quit    rela (Read error: Connection reset by peer)
09.03.55 Join    rela [0] (~x@pdpc/supporter/active/rela)
09.20.49 Join    girafe [0] (~girafe@LFbn-1-8015-136.w90-112.abo.wanadoo.fr)
09.39.40 ***     Saving seen data "./dancer.seen"
09.40.01 Quit    duo8 (Ping timeout: 250 seconds)
09.42.31 Join    duo8 [0] (~ZNC-SRV-H@27.72.17.17)
09.51.37 Join    petur [0] (~petur@rockbox/developer/petur)
10.02.17 Join    elensil [0] (~edhelas@2001:1c02:1903:d800:a925:530f:d2f1:bcab)
10.12.42 Quit    duo8 (Read error: Connection reset by peer)
10.15.04 Join    duo8 [0] (~ZNC-SRV-H@116.107.152.250)
10.16.32 Join    cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627)
10.20.00 Join    sth [0] (~ZNC-SRV-H@116.107.152.250)
10.22.03 Quit    duo8 (Ping timeout: 250 seconds)
10.25.17 Quit    sth (Ping timeout: 256 seconds)
10.29.15 Join    duo8 [0] (~ZNC-SRV-H@116.96.247.225)
10.53.53 Join    ved [0] (ved@ddsbox.tk)
10.57.00 Quit    cc___ (Ping timeout: 260 seconds)
11.13.49 Join    ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:9dfa:ca40:8ae0:8063)
11.20.01 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
11.24.53 #       <pamaury> Bilgus: boosting depends on the soc. on some it's very cheap, on some it can be expensive
11.25.43 #       <pamaury> memory frequency scaling is usually more expensive
11.29.06 #       <pamaury> but as saratoga pointed out, this is probably negligeable compared to backlight
11.39.41 ***     Saving seen data "./dancer.seen"
11.52.47 Quit    advcomp2019_ (Quit: Leaving)
12.24.53 Join    p3tur [0] (~petur@rockbox/developer/petur)
12.27.07 Quit    petur (Ping timeout: 250 seconds)
12.32.55 Join    petur [0] (~petur@rockbox/developer/petur)
12.35.41 Quit    p3tur (Ping timeout: 252 seconds)
12.45.56 Join    p3tur [0] (~petur@rockbox/developer/petur)
12.48.52 Quit    petur (Ping timeout: 252 seconds)
13.14.28 Quit    michaelni (Quit: Leaving)
13.14.37 Quit    Bilgus (Quit: Page closed)
13.24.13 Join    michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at)
13.39.45 ***     Saving seen data "./dancer.seen"
13.44.46 #       <duo8> pamaury have you tried looking at the fw file?
13.44.54 #       <pamaury> duo8: yes, see the logs
13.44.59 #       <pamaury> it unpacks fine with packtool
13.45.04 #       <pamaury> you can then descramble the main firmware
13.46.04 #       <pamaury> duo8: m2.fw unpacks fine with packtool
13.46.04 #       <pamaury> mkdir m2; packtools --unpack -i m2.fw -o m2/; packtool --descramble -i m2/sys.bin -o m2/sys.bin
13.46.04 #       <pamaury> then sys.bin is the main firmware
13.46.04 DBUG    Enqueued KICK pamaury
13.46.04 #       <pamaury> if you want to disassemble it, I can send you what I disassemble of the Fiio X1, that might help you
13.46.04 #       <pamaury> also some init is done only in the SPL and is not the main firmware, like LCD init
13.46.04 ***     Alert Mode level 1
13.46.04 #       <pamaury> so I would advise to dump the IPL and SPL anyway
13.46.16 #       <duo8> unrelated, but apparently DAC mode requires some propriety driver and doesn't work with linux
13.46.49 #       <duo8> nah no knowledge of asm so can't do much
13.47.54 #       <pamaury> I see, well when the Fiio X1 port is mode advance, I can have a look at it and send you some binaries
13.48.00 #       <duo8> i'll try dumping those, but how do i build hwstub shell?
13.48.18 #       <pamaury> cd /path/to/utils/hwstu/tools; make
13.48.43 #       <duo8> ok will try
13.48.54 Join    rogeliodh [0] (~Thunderbi@200.56.67.120)
13.49.43 #       <duo8> (btw the DAC mode is recognized as a hid device and uses hidraw, then causes pulseaudio to be stuck in status D)
13.49.47 #       <duo8> strange
13.50.08 #       <elensil> duo8: you're trying to play with the DAC mode of Rockbox ?
13.50.26 #       <duo8> no that's the built in DAC mode of my dap
13.51.00 #       <pamaury> duo8: interesting, can you run lsusb -v and pastebin the result?
13.51.06 #       <pamaury> (just being curious)
13.51.15 #       <duo8> yeah, already did yesterday
13.51.31 #       <duo8> alsa seems to (somewhat) works with it though
13.51.48 #       <duo8> if PA isn't running then aplay can play audio through it
13.55.48 #       <duo8> http://pastie.org/10946799
13.56.05 ***     Alert Mode OFF
13.57.39 #       <pamaury> looks like a standars usb audio device, except it is class 2.0, not that common I think
14.12.33 #       <duo8> ?
14.13.43 Nick    p3tur is now known as petur (~petur@rockbox/developer/petur)
14.27.52 #       <pamaury> the most common usb class for audio is audio 1.0 which is way simpler
14.28.10 #       <pamaury> the 2.0 version added a lot of complexity and most devices stick to the 1.0 one
15.12.32 Join    advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
15.18.59 Join    fs-bluebot_ [0] (~fs-bluebo@x4d099ae7.dyn.telefonica.de)
15.20.53 Quit    bluebrother (Ping timeout: 250 seconds)
15.21.27 Quit    fs-bluebot (Ping timeout: 265 seconds)
15.22.56 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
15.28.29 Join    Ivoah [0] (uid49352@gateway/web/irccloud.com/x-ykiccxvjdkgtefqb)
15.39.46 ***     Saving seen data "./dancer.seen"
15.52.32 Quit    elensil (Ping timeout: 245 seconds)
16.05.31 Join    elensil [0] (~edhelas@2001:1c02:1903:d800:a925:530f:d2f1:bcab)
16.08.48 Quit    krnlyng (Ping timeout: 256 seconds)
16.21.40 Join    krnlyng [0] (~liar@178.114.20.54.wireless.dyn.drei.com)
16.32.54 Quit    chrisb (Remote host closed the connection)
16.50.55 Quit    smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
16.54.29 Quit    rela (Ping timeout: 250 seconds)
17.22.36 Quit    petur (Quit: Connection reset by beer)
17.39.47 ***     Saving seen data "./dancer.seen"
17.55.46 Quit    elensil (Quit: Leaving.)
18.23.14 Join    cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627)
18.32.13 Quit    einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
19.06.17 Join    lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr)
19.12.20 Quit    krabador (Quit: Leaving)
19.14.16 Join    krabador [0] (~krabador@unaffiliated/krabador)
19.17.08 Quit    rogeliodh (Remote host closed the connection)
19.17.53 Join    rogeliodh [0] (~Thunderbi@200.56.67.120)
19.20.38 Join    petur [0] (~petur@rockbox/developer/petur)
19.30.12 Quit    krabador (Quit: Leaving)
19.32.13 Join    krabador [0] (~krabador@unaffiliated/krabador)
19.39.48 ***     Saving seen data "./dancer.seen"
19.45.30 Quit    WakiMiko (Max SendQ exceeded)
19.46.11 Join    WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
20.03.56 -->     "last #zeus" received from br33d (~br33d@199.201.64.134)
20.04.00 -->     "last #zeus" received from br33d (~br33d@199.201.64.134)
20.15.34 -->     "last #zeus" received from br33d (~br33d@199.201.64.134)
21.08.40 Join    TheLemonMan [0] (~root@unaffiliated/thelemonman)
21.39.51 ***     Saving seen data "./dancer.seen"
21.43.57 Quit    prof_wolfff (Ping timeout: 250 seconds)
21.53.55 Quit    lebellium (Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459])
21.56.32 Join    prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com)
22.10.22 Join    __builtin_ [0] (~xray@unaffiliated/franklin)
22.12.51 Quit    __builtin (Ping timeout: 248 seconds)
22.31.17 Quit    cc___ (Ping timeout: 245 seconds)
22.39.09 Quit    krabador (Ping timeout: 250 seconds)
22.39.49 Quit    rogeliodh (Remote host closed the connection)
23.02.51 Join    ulmutul [0] (~chatzilla@x5f757080.dyn.telefonica.de)
23.13.08 #       <ulmutul> Does anyone has objections against g#1408?
23.13.09 #       <fs-bluebot_> 3Gerrit review #1408 at http://gerrit.rockbox.org/r/1408 : 3YH-820: prohibit to change time/date on some hardware versions by Sebastian Leonhardt
23.14.48 Quit    ulmutul (Remote host closed the connection)
23.15.24 Join    ulmutul [0] (~chatzilla@x5f757080.dyn.telefonica.de)
23.18.06 Quit    ZincAlloy (Quit: Leaving.)
23.18.45 Quit    alexweissman (Remote host closed the connection)
23.28.40 #       <__builtin_> ulmutul: how about hiding the set time/date menu altogether?
23.28.47 Quit    TheLemonMan (Quit: "It's now safe to turn off your computer.")
23.31.14 #       <pamaury> why is it a problem to set the time/date on those?
23.32.34 #       <__builtin_> according to the commit message it leaves the player in "an unusable state"
23.32.43 #       <pamaury> this is weird
23.32.47 #       <__builtin_> on some hardware
23.33.16 #       <pamaury> I think on those I would rather implement the fix in the rtc driver, by returning an error code (even on reading time). I *think* rockbox handles fine devices without rtc by displaying --:--:--
23.33.40 #       <pamaury> I don't really like device specific code in apps/
23.34.43 #       <ulmutul> There's something wrong with the RTC connection on some hardware revisions, with the result that (a) the rtc is always read as "02:02:02" and (b) trying to set time/date will make the player unusable slow. It can only be revived by removing the battery.
23.35.37 #       <ulmutul> But this affects only certain hardware revisions, others run fine.
23.37.05 #       <ulmutul> I also thought of some kind of error code, but I would need a global variable for this. What would be the best place for it?
23.37.40 Join    krabador [0] (~krabador@unaffiliated/krabador)
23.37.45 #       <__builtin_> an error code on what condition?
23.38.50 #       <ulmutul> Because there's still problem (a) : the rtc readout doesn't change and the recording code hangs in an infinite loop when trying to create an unique filename.
23.39.54 ***     Saving seen data "./dancer.seen"
23.39.56 #       <ulmutul> Error code in the condition of reading "2nd February 2002 02:02:02" on YH820; this means the RTC doesn't work properly.
23.40.46 #       <pamaury> in the rtc driver (don't know which one), I would detect the faulty rtc in rtc_init(), save it to a flag. And then in rtc_read_datetime and rtc_write_datetime, I would directly return -1 if the hardware is faulty
23.41.14 #       <ulmutul> Ok
23.41.31 #       <pamaury> or maybe return 1
23.41.37 #       <pamaury> don't know what the return error code
23.41.44 #       <pamaury> probably anything different from 0
23.41.57 #       <pamaury> I think the display handles it fine, but indeed the recording code might hang
23.42.07 #       <pamaury> that would mean the recording code needs to be fixed
23.42.49 #       <ulmutul> BTW I wonder if some kind of "rtc not valid"-flag might be useful for all targets, i.e. if the code runs just by chance with an unset clock.
23.43.32 #       <pamaury> well my understanding is that if the rtc is not valid, reading should fail
23.43.43 #       <pamaury> but then you can (try) to write it to make it valid
23.44.08 #       <pamaury> Or maybe you can return a time structure with a clearly invalid timedate
23.44.27 #       <pamaury> To be honest, I would need to read the code to see if error conditions are handled at all
23.45.04 #       <ulmutul> When I record with a target where I previously removed the battery and didn't set the clock, I record some strange filenames, but it works, because the seconds advance as expected
23.45.12 Join    alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-3f1.dhcp6-bl.indiana.edu)
23.46.01 #       <pamaury> Or if the rtc is not valid, I guess you can return a default value like 1/1/1970 00:00
23.46.46 Quit    krabador (Quit: Leaving)
23.46.54 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
23.46.54 #       * pamaury needs to leave but can I have a look this weekend
23.47.14 #       <ulmutul> This wouldn't solve the problem that the time doesn't advance.
23.47.28 #       <pamaury> the recording code should be fixed
23.47.43 #       <pamaury> or the rtc code can fake time
23.47.54 #       <pamaury> like counting seconds since startup and add an arbitrary time
23.47.55 Join    krabador [0] (~krabador@unaffiliated/krabador)
23.48.07 #       <pamaury> that might actually be the simplest solution
23.48.53 #       <ulmutul> Maybe it's useful for all targets to have a fallback and use the numbered filenames like targets without a rtc
23.50.08 #       <pamaury> yes clearly this code is shaky
23.51.27 #       <ulmutul> Where would I put a global "rtc_not_valid"-flag?
23.55.03 Quit    pamaury (Ping timeout: 256 seconds)