Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2016-10-20

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] (
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.
02:01:49BilgusI was looking through commits and noticed 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__builtinBilgus: 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__builtinand also the newer context should encompass the previous ones
03:06:50 Join Bilgus1 [0] (4cf32773@gateway/web/freenode/ip.
03:10:34Bilgus1Well 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.
03:18:45saratogaBilgus1: 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:33saratogaeventually 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:38saratogawithout the UI lagging
03:20:38Bilgus1so then the compromise was expanded to always boost with the addition of processor/voltage scaling?
03:20:42saratogawe could always enable the old behavior on a new device if it made sense of course
03:20:57saratogayeah so that we could lower the normal clock even lower
03:21:24saratogawe considered doing this on the old ipod video back in the day but decided not to for various reasons
03:23:17saratogabut its more efficient to have the lowest possible clock and then just speed it up if the UI is needed
03:23:28Bilgus1makes sense..
03:24:01saratogawe 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:52Bilgus1I 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:46saratogait boosts for a set period (grep GUI_BOOST_TIMEOUT, i forget how long it is)
03:26:58saratogaso everytime you hit a button the timer is reset
03:27:30saratogabut 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:24Bilgus1Ive already added selective backlighting i was just following this to the next power savings possibility and wondering if there were any downsides
03:30:34saratogayou can just disable it in the config file for you device if you want to test
03:30:50saratogaassuming its already enabled that is
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] (
04:10:13 Quit zoktar (Changing host)
04:10:13 Join zoktar [0] (~zoktar@unaffiliated/zoktar)
04:14:46 Join sbach [0] (~sbach@
04:20:12 Join prof_wolfff [0] (
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@
04:33:39 Join Rower [0] (
04:49:29Bilgusok 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:49Bilgusnm firmware/kernel/include/tick.h #define HZ 100 /* number of ticks per second */
05:29:25Bilgus* 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] (
06:54:15 Join ender` [0] (
06:56:49 Quit dfkt (Disconnected by services)
06:56:59 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt)
07:07:13 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
07:39:39***Saving seen data "./dancer.seen"
08:34:00 Quit amiconn (Quit: - 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] (
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] (
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@
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@
10:16:32 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627)
10:20:00 Join sth [0] (~ZNC-SRV-H@
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@
10:53:53 Join ved [0] (
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:53pamauryBilgus: boosting depends on the soc. on some it's very cheap, on some it can be expensive
11:25:43pamaurymemory frequency scaling is usually more expensive
11:29:06pamaurybut 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] (
13:39:45***Saving seen data "./dancer.seen"
13:44:46duo8pamaury have you tried looking at the fw file?
13:44:54pamauryduo8: yes, see the logs
13:44:59pamauryit unpacks fine with packtool
13:45:04pamauryyou can then descramble the main firmware
13:46:04pamauryduo8: m2.fw unpacks fine with packtool
13:46:04pamaurymkdir m2; packtools −−unpack -i m2.fw -o m2/; packtool −−descramble -i m2/sys.bin -o m2/sys.bin
13:46:04pamaurythen sys.bin is the main firmware
13:46:04DBUGEnqueued KICK pamaury
13:46:04pamauryif you want to disassemble it, I can send you what I disassemble of the Fiio X1, that might help you
13:46:04pamauryalso 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:04pamauryso I would advise to dump the IPL and SPL anyway
13:46:16duo8unrelated, but apparently DAC mode requires some propriety driver and doesn't work with linux
13:46:49duo8nah no knowledge of asm so can't do much
13:47:54pamauryI see, well when the Fiio X1 port is mode advance, I can have a look at it and send you some binaries
13:48:00duo8i'll try dumping those, but how do i build hwstub shell?
13:48:18pamaurycd /path/to/utils/hwstu/tools; make
13:48:43duo8ok will try
13:48:54 Join rogeliodh [0] (~Thunderbi@
13:49:43duo8(btw the DAC mode is recognized as a hid device and uses hidraw, then causes pulseaudio to be stuck in status D)
13:50:08elensilduo8: you're trying to play with the DAC mode of Rockbox ?
13:50:26duo8no that's the built in DAC mode of my dap
13:51:00pamauryduo8: interesting, can you run lsusb -v and pastebin the result?
13:51:06pamaury(just being curious)
13:51:15duo8yeah, already did yesterday
13:51:31duo8alsa seems to (somewhat) works with it though
13:51:48duo8if PA isn't running then aplay can play audio through it
13:56:05***Alert Mode OFF
13:57:39pamaurylooks like a standars usb audio device, except it is class 2.0, not that common I think
14:13:43 Nick p3tur is now known as petur (~petur@rockbox/developer/petur)
14:27:52pamaurythe most common usb class for audio is audio 1.0 which is way simpler
14:28:10pamaurythe 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] (
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/
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] (
16:32:54 Quit chrisb (Remote host closed the connection)
16:50:55 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium
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.
19:06:17 Join lebellium [0] (
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@
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@
20:04:00-->"last #zeus" received from br33d (~br33d@
20:15:34-->"last #zeus" received from br33d (~br33d@
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] (
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] (
23:13:08ulmutulDoes anyone has objections against g#1408?
23:13:09fs-bluebot_3Gerrit review #1408 at : 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] (
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:14pamaurywhy 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:43pamaurythis is weird
23:32:47__builtin_on some hardware
23:33:16pamauryI 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:40pamauryI don't really like device specific code in apps/
23:34:43ulmutulThere'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:37ulmutulBut this affects only certain hardware revisions, others run fine.
23:37:05ulmutulI 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:50ulmutulBecause 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:56ulmutulError code in the condition of reading "2nd February 2002 02:02:02" on YH820; this means the RTC doesn't work properly.
23:40:46pamauryin 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:31pamauryor maybe return 1
23:41:37pamaurydon't know what the return error code
23:41:44pamauryprobably anything different from 0
23:41:57pamauryI think the display handles it fine, but indeed the recording code might hang
23:42:07pamaurythat would mean the recording code needs to be fixed
23:42:49ulmutulBTW 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:32pamaurywell my understanding is that if the rtc is not valid, reading should fail
23:43:43pamaurybut then you can (try) to write it to make it valid
23:44:08pamauryOr maybe you can return a time structure with a clearly invalid timedate
23:44:27pamauryTo be honest, I would need to read the code to see if error conditions are handled at all
23:45:04ulmutulWhen 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] (
23:46:01pamauryOr 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:54CtcpIgnored 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:14ulmutulThis wouldn't solve the problem that the time doesn't advance.
23:47:28pamaurythe recording code should be fixed
23:47:43pamauryor the rtc code can fake time
23:47:54pamaurylike counting seconds since startup and add an arbitrary time
23:47:55 Join krabador [0] (~krabador@unaffiliated/krabador)
23:48:07pamaurythat might actually be the simplest solution
23:48:53ulmutulMaybe it's useful for all targets to have a fallback and use the numbered filenames like targets without a rtc
23:50:08pamauryyes clearly this code is shaky
23:51:27ulmutulWhere would I put a global "rtc_not_valid"-flag?
23:55:03 Quit pamaury (Ping timeout: 256 seconds)

Previous day | Next day