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).

#rockbox log for 2015-10-06

00:37:12***Saving seen data "./dancer.seen"
00:56:38 Quit pamaury (Remote host closed the connection)
01:01:56 Quit FSanches (Quit: Leaving.)
01:03:51 Quit ender (Quit: Politicians are like sperm. One in a million turns out to be an actual human being.)
02:15:56 Join chrisb [0] (
02:25:07 Quit chrisb (Ping timeout: 256 seconds)
02:37:14***Saving seen data "./dancer.seen"
02:40:02 Join FSanches [0] (~felipe@2804:14c:37:268b:41af:6fd7:e9a1:15fc)
02:52:28 Join chrisb [0] (
02:52:34jtdesigns01hey guys, is there a way to turn down the time i have to hold the power button to force my fuze+ off?
03:00:38 Join Strife89 [0] (
03:13:41 Quit chrisb (Ping timeout: 246 seconds)
04:36:49 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs)
04:37:18***Saving seen data "./dancer.seen"
05:09:59 Quit cmhobbs (Ping timeout: 255 seconds)
05:25:56 Join rela [0] (~x@pdpc/supporter/active/rela)
05:28:44 Quit jtdesigns01 (Quit: Leaving)
05:37:53 Quit [7] (Disconnected by services)
05:38:03 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06:37:20***Saving seen data "./dancer.seen"
06:47:03 Quit Strife89 (Ping timeout: 244 seconds)
07:02:56 Quit kugel (Ping timeout: 255 seconds)
07:02:57 Quit nosa-j (Ping timeout: 246 seconds)
07:03:04 Join kugel [0] (
07:03:08 Quit kugel (Changing host)
07:03:08 Join kugel [0] (~kugel@rockbox/developer/kugel)
07:03:10 Quit derf (Ping timeout: 246 seconds)
07:03:18 Quit Jinx (Ping timeout: 246 seconds)
07:03:37 Join evilnick_ [0] (
07:04:00 Quit evilnick (Ping timeout: 265 seconds)
07:04:28 Quit chardy (Ping timeout: 265 seconds)
07:04:33 Quit shmibs (Read error: Connection reset by peer)
07:04:43 Join shmibs [0] (
07:05:00 Join derf [0] (
07:05:26 Quit user890104 (Ping timeout: 265 seconds)
07:06:17 Join nosa-j [0] (
07:08:10 Join user890104 [0] (Venci@unaffiliated/user890104)
07:09:38 Join chardy [0] (
07:09:50 Join Jinx [0] (Dojo@unaffiliated/jinx)
07:36:17 Join CUP_GOD [0] (
07:36:29CUP_GODQuestion about conributing to the codebase
07:36:41CUP_GODI see you guys use mostly C, would C++ be acceptable?
08:13:09 Join wodz [0] (
08:26:03 Join ender` [0] (
08:33:34 Quit FSanches (Quit: Leaving.)
08:37:25***Saving seen data "./dancer.seen"
08:49:15 Join petur [0] (~petur@rockbox/developer/petur)
09:14:48utrackCUP_GOD: I'm not a rbdev, but I guess C++ won't work - it requires exceptions and vfuncs which would add overhead to the firmware size
09:15:36utrackCUP_GOD: that is, if you're sure it's C only :) I'm just hacking around, didnt see the whole code
09:20:49 Quit CUP_GOD (Ping timeout: 240 seconds)
09:34:29 Quit JanC (Read error: Connection reset by peer)
09:50:40 Join JanC [0] (~janc@lugwv/member/JanC)
10:00:38gevaertsCorrect. We don't have any C++ infrastructure in place
10:04:19 Quit soap (Read error: Connection reset by peer)
10:04:49 Join soap [0] (~soap@rockbox/staff/soap)
10:37:27***Saving seen data "./dancer.seen"
10:41:18 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
10:48:40 Join einhirn [0] (
11:01:18pamauryjtdesigns01bot: yes but you need to recompile rockbox. But the poweroff delay is already quite small in ymy opinion
11:02:30 Quit Hadaka (Ping timeout: 256 seconds)
11:04:12gevaertsThat's the normal poweroff, not the force thing
11:08:55pamauryah I misread
11:09:03pamaurynot it cannot be changed indeed
11:14:36 Quit yuriks (Ping timeout: 246 seconds)
11:14:57 Join Hadaka [0] (
11:22:39wodzpamaury: Where in qeditor is scanning for connected devices implemented.
11:22:54pamaurybackend.cpp iirc why ?
11:23:53pamauryin HWStubBackendHelper
11:26:35wodzpamaury: I am thinking in moving this to hwstub_server and extend TCP protocol to return the list. So make hwstub_server true backend
11:26:35 Quit pamaury (Remote host closed the connection)
11:27:28 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
11:29:03pamaurywodz: sounds fine
11:31:13pamauryI think you should build up on g#1217
11:31:25fs-bluebotGerrit review #1217 at : hwstub: add JZ support, refactor code, fix related tools (qeditor, hwstub tools) by Amaury Pouly
11:32:51wodzpamaury: sure
11:33:58pamauryout of curiosity, do you plan to make it possible for hwstub_server to relay to another TCP server ? In other words, will your hwstub_server handle any kind of devices (usb, tcp and potentially mode in the future) ?
11:36:12wodzpamaury: I don't think this is desirable. You can select remote hswtub_server instance in client, don't you?
11:37:40pamaurybut imagine the case where you want to do some work on both a remote device and a local device, then it's impossible
11:38:22pamauryor you would need to add this to the library hum
11:39:51pamauryanyway, this is probably another issue, just have a go at it, it can be improved later
11:43:08wodzpamaury: Any particular example of such setup? You can always fire up two clients connected to two different backend servers
11:45:57pamauryjust to avoid having two qeditor instances and if you want to use it for a diff for example
11:46:29wodzDiff is the only thing I can imagine this useful for.
11:46:41wodzBut is diff commited at all?
11:48:01pamauryno, there is a patch on gerrit but not sure about the state
11:50:10wodzAnyway in case of diff you still have to select two sources of information to compare. It can be made UI level setup to use local backend server for one and remote for the second.
11:52:17pamauryok do as you wish, that's clearly not the major point here :)
11:54:33pamauryI need to go, be back later
11:55:54 Quit greatwolf (Ping timeout: 246 seconds)
11:56:59 Join greatwolf [0] (greatwolf@gateway/shell/panicbnc/x-qnknsycyrcfxxryw)
12:10:06 Join yuriks [0] (~quassel@opentyrian/developer/yuriks)
12:13:02 Quit einhirn (Read error: Connection reset by peer)
12:37:28***Saving seen data "./dancer.seen"
12:37:59 Join FSanches [0] (~felipe@2804:14c:37:268b:41af:6fd7:e9a1:15fc)
12:38:18utrackcould anyone look at g#1193? It's a simple workaround, but it's a pain to fix every time code is checked out ._.
12:38:29fs-bluebotGerrit review #1193 at : Added fgnu89-inline flag for tool compilers; fixes embedded GCC build for host GCC... by Nick K
12:43:22pamauryutrack: what does that do ?
12:43:53utrackpamaury: it enables compilation on host systems with newer gcc :)
12:43:54pamauryI'll be happy to commit it if necessary
12:44:14pamauryok, may it cause any issue with older gcc >
12:45:05utrackpamaury: it needs tests on gcc <= 4.3, but the gist of it is iso c99 inline externs were default with v<4.3, but on 4.3 and later some other syntax was chosen as default. So some parts of RB refuse to compile
12:45:18utrackpamaury: not sure, but according to specs it shouldn't
12:46:24pamauryI see, if you have a way to test it on gcc <= 4.3 that would be awesome
12:46:55utrackpamaury: i'll try to check it out tomorrow. :)
12:47:03pamauryok thanks :)
14:37:30***No seen item changed, no save performed.
14:49:00 Join peeZ3 [0] (253aa42a@gateway/web/freenode/ip.
14:50:05peeZ3a question: I wonder where I can submit bug reports for a particular theme? in flyspray? thx
14:52:39 Join amayer [0] (
14:52:46pamauryunfortunately, I don't think we look at bug reports very often because the few devs are very busy
14:54:38peeZ3it's just a little think but a bit anoying:,51021.0.html
14:55:19wodzpamaury: Looking at code you basically register callback which fires when new device enumerates (+ returns all already connected devices on registration). Now the server should have means to notify clients connected.
14:56:56pamauryyeah it's very easy with libusb (assuming the library supports hot plug so you should also have a function to check if hotplug is supported)
14:57:21wodzyes, there is one
14:57:46pamaurythe current code in qeditor is quite dumb at the moment though
14:58:09pamauryI'd like the library to report when a device disappear/is disconnected
15:00:39pamauryhow do you plan to have the server notify device changes ?
15:01:19pamauryalso if hwstub_server supports several devices, it should probably have a notion of 'opening a device' right ?
15:02:03wodzpamaury: Thats the question. The easiest approach is to poll the server for device list. Otherwise you should asynchronously listen for messages from server.
15:02:40wodzpamaury: yes tcp protocol should be extended with device id
15:03:10pamauryyou can use out of band data
15:03:38pamauryI suppose in any case, it means the hwstub library should have its own thread
15:05:29wodzso you mean to spawn 'listening' thread in hwstub_open(), righ?
15:06:44pamaurythat will make the whole library more complicated though because the handling of OOB data is not trivial
15:07:46pamaurybut polling is not trivial either because you don't want to send a poll request in the middle of a request, so you need a queuing mechnism
15:08:36 Quit FSanches (Quit: Leaving.)
15:08:36wodzThere is simpler approach. backend can respond with disconnect error if you issue request to the device which got disconnected in the middle
15:09:05wodzthen you could poll infrequently about new entities
15:10:07pamauryyes of course, I think the hwstub library should report disconnect error anyway, and those errors should also appear in the TCP protocol.
15:11:40wodzSo the simplest thing is to extend protocol so 1) it reports actual errors such as disconnects 2) add status query which will return the list of devices connected to the server
15:11:57wodz3) add device id field to the messages
15:12:00 Join jtdesigns01 [0] (~jonathan@2601:400:8000:2669:a912:ad75:a3a8:b02b)
15:12:14pamaury4) add open/close requests
15:12:38wodzpamaury: what good is it for?
15:12:55pamauryyou can't send arbitrary request to USB device without opening then before
15:13:22wodzpamaury: or you mean that server should know what devices are connected but not open usb connection to them?
15:13:49pamaurynot on start no, because opening a device may prevent access for other programs
15:14:06pamauryyou should only open it when you actually use it
15:15:00pamaurymy suggestion is that server can 'open' a device, return a handle ID, then you can use the handle to send request and you can close it
15:15:15pamauryotherwise you need to open/close it on each request
15:15:25pamaurybut that sounds wrong
15:16:37wodzWhy server shouldn't keep devices opened actually?
15:17:28 Join stickyb1t [0] (
15:17:42wodzeach device will have separate handle so server is able to route requests appropriately
15:18:20pamauryit feels kind of strange to greedily open all devices you can even if you don't use them
15:19:13wodzexplicit open/close may feel strange in multiclient scenario
15:20:03wodzwhat if one client decides to close and the second wishes to read something?
15:20:08pamauryeach client would have its own ID, the server would multiplex requests
15:20:19pamauryopen/close is relative to the client
15:20:27pamaurythe server counts references basically
15:20:30wodzthat sounds overly complicated from my point of view
15:21:26pamaurybut for example, what if hwstub_server grabs a JZ device and them you try to use jw tools to upload a binary ?
15:21:42pamauryI guess you can't because hwstub already claimed the interface
15:22:27pamaury(it's only a problem for device that could potentially be in use by other programs of course)
15:23:34wodzSo you expect additional button for connect/disconnect in qeditor for example?
15:24:01wodzor open/close() in hwstub_shell - thats sounds bogus to me
15:24:51pamauryqeditor already does that internally, it open devices when you select them in the interface and leave the other ones alone
15:25:15pamauryhzstub_shell would open the device you specified on start, since it only handle a single device at the moment
15:25:26pamauryI mean the current library already has open/close
15:25:41wodzI'll think about this some more. Gtg
15:25:44 Quit wodz (Quit: Leaving)
15:27:51 Quit stickyb1t (Ping timeout: 246 seconds)
15:34:19 Join stickyb1t [0] (
15:36:37 Quit peeZ3 (Quit: Page closed)
15:39:04 Quit stickyb1t (Ping timeout: 240 seconds)
16:00:02 Join stickyb1t [0] (
16:00:07 Join FSanches [0] (~atomic@
16:07:36 Quit stickyb1t (Ping timeout: 250 seconds)
16:09:47user890104hello, does anyone know why when i set "backlight on hold" to off, it does not go off when locking the hold switch on my ipod classic? (build bc25437-150929)
16:11:34user890104it used to turn off immediately when locking the switch, and that version was more than year old, but since i wiped the whole hdd i don't have it
16:12:07jtdesigns01hmm, thats not the most recent version afaik
16:12:10 Join stickyb1t [0] (
16:13:21jtdesigns01but its close
16:14:02jtdesigns01were you using the latest "stable" before you wiped?
16:17:28 Quit stickyb1t (Read error: Connection reset by peer)
16:17:34 Join st1ckyb1t [0] (
16:20:14pamaurysounds like either the code to set backlight on off is broken, or hold detection notification on the ipod classic is broken
16:22:06 Quit st1ckyb1t (Ping timeout: 256 seconds)
16:26:39pamauryuser890104: does hold work ? (I mean apart from the backlight not goes off immediately)
16:36:44user890104pamaury: yes
16:37:10user890104also the ipod doesn't wake up on unlock, it used to do so
16:37:24user890104wake up = backlight on + screen on
16:37:34***Saving seen data "./dancer.seen"
16:38:00user890104looks like it blocks button inputs, but doesn't notify rockbox about its status changes
16:38:42user890104TheSeven might have an idea what's going on
16:39:07user890104the hold switch is not a GPIO IIRC
16:45:42pamaurythe button driver is supposed to notify rockbox on hold change. If the hold is a hardware switch, it could still block the input but the code to sense that is broken. But yeah TheSeven is probably the one who knows about that
16:48:50 Quit munch (Ping timeout: 246 seconds)
16:50:20jtdesigns01pamaury: implementing your suggested change, when is the interrupt called?
16:53:05pamauryjtdesigns01: I would need to check the datasheet, you can probably select interrupt events but iirc, as long as the user is touching the pad, you get at least N reports per seconds. where is N is the report rate and can be adjusted
16:53:31jtdesigns01i see
16:53:35pamauryI think it's 50 interrupts per/sec, not sure
16:54:44pamauryone thing to think about though is what happens if for example you get two reports between two calls to get relative data: should you report the sum of relative moves or only the most report ?
16:57:42 Join TheLemonMan [0] (~lemonboy@unaffiliated/thelemonman)
17:12:58 Part esko997 ("Leaving")
17:15:28 Join nlogex [0] (
17:21:42 Join st1ckyb1t [0] (
17:31:46jtdesigns01pamaury: could you look at my new patchset? I`m not sure what i did wrong, but using dragging in rockpaint now freezes instantly.
17:32:48pamauryjtdesigns01: the button driver part looks ok
17:33:17pamaurymy guess is that x and/or y in rockpaint goes out of range
17:33:53pamauryI'm not quite sure you want relative data by the way
17:33:58 Quit petur (Quit: Leaving)
17:49:57jtdesigns01i had forgotten about a little plugin i made while testing the first patchset that shows the current relative data.
17:50:16jtdesigns01with my new implementation, its showing all zeroes
17:50:47pamauryjtdesigns01: it is possibly the touchpad doesn't report relative data, let me check
17:51:07jtdesigns01no, it did work before.
17:51:19jtdesigns01same with my changes to rockpaint
17:53:00pamauryare you sure it's not just a display problem ? Ie it reports one non-zero valye one time out of 50
18:12:21jtdesigns01pamaury: what does the display have to do with it?
18:12:48pamaurydisplay is slow :)
18:13:13jtdesigns01um.. ok?
18:13:21jtdesigns01it worked before.
18:13:59pamaurymaybe do this: go to debug > target > interrupts
18:15:07pamauryyou will see a number of interrut sources, look for for gpio0 (I think), there should be number next to it, it's the number of interrupts per sec
18:15:20pamaurystart touching the pad, check that the number goes up
18:15:33pamaury(I don't have the device at hand, so I can't check the details)
18:17:01pamaurysorry it should debug > View HW info > icoll
18:18:25pamauryyou can reach icoll by pressing select multiple times I think
18:22:17jtdesigns01yeah, it does go up. why?
18:22:31jtdesigns01why is that important?
18:22:45jtdesigns01is that to test if my device is working?
18:23:10pamauryit means that interrupts are reported
18:27:15jtdesigns01hmm... so i guess the struct isnt getting filled at all OR the get_relative function isnt returning it correctly
18:27:24 Quit FSanches (Ping timeout: 246 seconds)
18:28:36 Quit jtdesigns01 (Remote host closed the connection)
18:31:26 Join jtdesigns01 [0] (~Thunderbi@2601:400:8000:2669:c0bc:57d1:b403:264b)
18:31:53 Quit st1ckyb1t (Ping timeout: 250 seconds)
18:35:47 Quit nlogex (Quit: WeeChat 1.3)
18:37:35***Saving seen data "./dancer.seen"
18:54:50 Quit pamaury (Ping timeout: 255 seconds)
19:15:13 Join lebellium [0] (
19:16:53 Join FSanches [0] (~atomic@
19:41:17 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
19:49:10 Join st1ckyb1t [0] (
19:51:38 Quit st1ckyb1t (Read error: Connection reset by peer)
19:52:04 Join st1ckyb1t [0] (
20:14:57 Quit st1ckyb1t (Quit: Konversation terminated!)
20:15:35 Join st1ckyb1t [0] (
20:22:28 Quit st1ckyb1t (Quit: Konversation terminated!)
20:23:26 Join stickyb1t [0] (
20:36:41 Quit stickyb1t (Ping timeout: 246 seconds)
20:37:36***Saving seen data "./dancer.seen"
21:00:18 Quit fs-bluebot (Read error: Connection reset by peer)
21:00:29 Quit bluebrother (Read error: Connection reset by peer)
21:00:48 Quit Bray90820 ()
21:10:20 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
21:14:13 Join petur [0] (~petur@rockbox/developer/petur)
21:17:56 Join wodz [0] (
21:21:46 Join bertrik [0] (~quassel@rockbox/developer/bertrik)
22:16:42 Join stickyb1t [0] (
22:37:39***Saving seen data "./dancer.seen"
22:39:17 Quit kugel (Ping timeout: 240 seconds)
22:39:24 Join kugel [0] (
22:39:24 Quit kugel (Changing host)
22:39:24 Join kugel [0] (~kugel@rockbox/developer/kugel)
22:39:29 Quit yuriks (Read error: Connection reset by peer)
22:39:37 Quit orly_owl (Ping timeout: 240 seconds)
22:40:30 Join orly_owl [0] (~david@unaffiliated/orly-owl/x-3167833)
22:43:40 Quit JanC (*.net *.split)
22:43:40 Quit stickyb1t (*.net *.split)
22:43:40 Quit jtdesigns01 (*.net *.split)
22:43:40 Quit greatwolf (*.net *.split)
22:43:41 Quit Jinx (*.net *.split)
22:43:41 Quit ps-auxw (*.net *.split)
22:43:42 Quit Jack87 (*.net *.split)
22:45:46 Join JanC [0] (~janc@lugwv/member/JanC)
22:46:13 Join stickyb1t [0] (
22:46:13 Join jtdesigns01 [0] (~Thunderbi@2601:400:8000:2669:c0bc:57d1:b403:264b)
22:46:13 Join greatwolf [0] (greatwolf@gateway/shell/panicbnc/x-qnknsycyrcfxxryw)
22:46:13 Join Jinx [0] (Dojo@unaffiliated/jinx)
22:46:13 Join ps-auxw [0] (
22:46:13 Join Jack87 [0] (Jack87@nasadmin/admin/jack87)
22:47:43 Join yuriks [0] (~quassel@opentyrian/developer/yuriks)
22:47:44 Quit scorche|sh (Ping timeout: 240 seconds)
22:50:02 Quit Jinx (Ping timeout: 246 seconds)
22:52:11 Quit stickyb1t (Read error: Connection reset by peer)
22:52:31 Join stickyb1t [0] (
22:52:54 Quit stickyb1t (Client Quit)
22:55:18 Join ZincAlloy [0] (~Adium@2a02:8108:8080:26f0:20bf:edb3:7bd0:3206)
22:55:51 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche)
23:00:07 Quit Cinos (Remote host closed the connection)
23:00:18 Quit wodz (Quit: Leaving)
23:08:51 Join Cinos [0] (
23:11:19 Join Jinx [0] (Dojo@unaffiliated/jinx)
23:14:45 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 42.0/20151001142456])
23:15:59 Quit bertrik (Remote host closed the connection)
23:19:55 Quit petur (Quit: Leaving)
23:26:20 Join Bray90820 [0] (
23:26:58 Quit ender` (Quit: Any technology distinguishable from magic is insufficiently advanced. -- Gehm's Corollary to Clarke's Third Law)
23:31:43 Quit amayer (Quit: Leaving)
23:35:53 Join FSanches1 [0] (~felipe@2804:14c:37:268b:4552:b544:575:c80d)
23:46:31 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")

Previous day | Next day