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-07

00:02:37 Join Strife89 [0] (~Strife89@adsl-98-80-221-246.mcn.bellsouth.net)
00:06:54 Quit rela (Read error: Connection reset by peer)
00:07:15 Join rela [0] (~x@pdpc/supporter/active/rela)
00:08:14 Quit Bray90820 (Read error: Connection reset by peer)
00:08:39 Join Bray90820 [0] (~Bray90820@2604:2d80:800a:81bb:fd07:bbcd:4797:c03e)
00:09:14 Quit ruhans (Remote host closed the connection)
00:37:41***Saving seen data "./dancer.seen"
00:42:07 Join [Franklin] [0] (~franklin@unaffiliated/franklin)
00:49:27 Quit FSanches (Ping timeout: 244 seconds)
00:50:07 Quit ZincAlloy (Quit: Leaving.)
00:52:05 Join FSanches [0] (~atomic@179.114.13.111)
01:00
01:00:29*TheSeven passes that on to prof_wolfff
01:00:58TheSevenuser890104: IIRC he found a GPIO in the meantime, but maybe there's an issue with it
01:01:29TheSeventhe hold switch actually physically shuts down power to the clickwheel, so that explains why the buttons wouldn't work despite hold detection not working
01:01:39TheSevendoes the lock icon in the status bar come up if you lock it?
01:01:54user890104TheSeven: no
01:02:22TheSevenok, most definitely a regression from one of these patches then
01:02:52user890104any idea which are they?
01:03:05user890104i can try an older build
01:03:45TheSevenhttp://git.rockbox.org/?p=rockbox.git;a=blob;f=firmware/target/arm/ipod/button-clickwheel.c;h=3af50b5112c29a25d2935701ccfeef3ec130f48b;hb=HEAD#l399
01:03:59TheSevencan you check GPIOE value while toggling the hold switch?
01:04:00prof_wolfffactually the holdswitch is not working, i have patched it in the bootloader patch that i am going to send to gerrit (finally) today or tomorrow, in addition i have more info on how the clickwheel works, ATM it is not included in the patch because it is so much info and i need to revise it
01:04:57 Quit djukon (Ping timeout: 264 seconds)
01:05:01*TheSeven wonders where prof_wolfff always gets that information from ;)
01:06:08 Join FSanches2 [0] (~atomic@179.95.51.19)
01:06:09user890104prof_wolfff: which bootloader? :)
01:06:20*user890104 is using emCORE
01:06:24 Quit FSanches (Ping timeout: 240 seconds)
01:06:36TheSevenI think he has an AMS-like approach
01:06:49prof_wolfffi noticed the problem with the holdwitch when writing the bootloader, then i start to investigate the clickwheel, i did it sampling the GPIOs using emCORE to see what was going on, i was hooked with that for a few sessions
01:07:56TheSevenI guess I had a reason when I implemented the PMU-based hold detection ;)
01:08:12TheSevenway too long ago to remember what it was though
01:09:10user890104is there a development version of the new bootloader available for debugging/testing?
01:09:11prof_wolfffuser890104, i have a bootloader prepared, it is the first version but it works great, ATM i load it using ipoddfu.py, i have seen there is a ipoddfu_c written by you, i think it could be by the RB intallation utility
01:09:51user890104prof_wolfff: the C version is so buggy, i haven't had the time to fix it
01:10:21prof_wolfffi was doing the last cleanup ATM, i will try to upload it in the next hours, it modifies many files and i had last time problems porting it to RB, it is almost 90% emcore code
01:10:21 Quit pamaury (Ping timeout: 264 seconds)
01:10:41user890104the exploit uses some timings, which i fail to reproduce in my version so it doesn't work as expected
01:10:43 Join ruhans [0] (uid76353@gateway/web/irccloud.com/x-tzlikzckasxxdlwl)
01:10:54prof_wolfffdoes the c version works on windows?
01:11:09user890104it should in theory
01:11:16TheSevenuser890104: shouldn't depend on timings much, other than "wait long enough for it to complete whatever it's doing"
01:11:45TheSevenand the expected error situation at the end of the process, when the ipod just reboots
01:11:47user890104TheSeven: then there's another bug in it
01:12:08prof_wolfffall my development was in linux, but i have tested nothing in windows, i think i should use cygwin
01:12:44user890104i can do windows testing
01:13:16prof_wolfffanyways the C version is a good starting point to add to rbutils/mk6gboot/, actually there is a mkdfu.c thats build a .dfu file including the installer and the bootloader
01:13:46prof_wolfffuser890104, nice, please tell me all problems you can find
01:13:54user890104prof_wolfff: i think i can get the c version to work
01:14:55prof_wolfffgreat!, it will be necessary for the RB installation utility
01:43:17user890104prof_wolfff: ipoddfu_c works on my linux board
01:43:43user890104at least with the 17kiB bootstrap, i remember that it used to fail on bigger files
01:46:40user890104working: http://pastebin.com/raw.php?i=uyMNKD6q
01:47:02user890104not working: http://pastebin.com/raw.php?i=tbRGSttW
01:59:00prof_wolfffuser890104: i tested it yesterday on linux a couple of times using a ~90Kb .dfu and it works well for me, i am going to use it from now
02:00
02:00:04user890104prof_wolfff: i'm pushing an update now, there are some ugly expressins in the code and the makefile is a mess
02:00:33user890104but freemyipod's svn server is acting up
02:03:47prof_wolfffif you are ok, i will download it latter and add it to RB bootloader at rbutils/mk6gboot/ipoddfu, then we need to modify it a bit to integrate into an unique rbutils/mk6gboot/mk6gboot utility, this utility will create the .dfu using mkdfu.c and upload it to iPod device using ipoddfu.c
02:04:34prof_wolfffuser890104: ^
02:05:43user890104prof_wolfff: i'd like to polish it a bit before inclusion into rockbox, and test it with large files
02:06:45prof_wolfffok, i you want you can try to integrate it into mk6gboot
02:07:31user890104is it uploaded to rockbox's git repo, or only as a patch?
02:07:47 Quit FSanches2 (Ping timeout: 246 seconds)
02:07:56prof_wolfffi will upload it as a patch in a few hours, just look at these folders
02:08:08user890104ah, i see. ok
02:09:20prof_wolfffyou can add it as other patch over the bootloader, i suppose the bootloader is not to be commited too soon
02:10:00prof_wolfffand then join both patches before the final commit
02:37:45***Saving seen data "./dancer.seen"
02:56:51 Quit jtdesigns01 (Quit: jtdesigns01)
02:57:19 Join jtdesigns01 [0] (~Thunderbi@2601:400:8000:2669:c0bc:57d1:b403:264b)
02:57:37 Quit [Franklin] (Quit: Lost terminal)
03:00
03:14:20 Join djukon [0] (transitor@gateway/shell/insomnia247/x-rrfmayxcxuhmlftt)
03:43:26 Quit jtdesigns01 (Quit: jtdesigns01)
03:45:12 Join jtdesigns01 [0] (~jonathan@2601:400:8000:2669:894f:5aa7:5332:5dc9)
03:49:19 Quit jtdesigns01 (Remote host closed the connection)
04:00
04:02:30 Join jtdesigns01 [0] (~jonathan@2601:400:8000:2669:e1ed:7e38:cc9b:749)
04:37:49***Saving seen data "./dancer.seen"
05:00
05:11:06 Quit jtdesigns01 (Remote host closed the connection)
05:36:53 Quit TheSeven (Disconnected by services)
05:37:05 Join [7] [0] (~quassel@rockbox/developer/TheSeven)
05:41:50 Quit FSanches1 (Quit: Leaving.)
06:00
06:00:51 Join FSanches [0] (~felipe@2804:14c:37:268b:4552:b544:575:c80d)
06:07:10 Quit FSanches (Quit: Leaving.)
06:24:47 Quit Strife89 (Ping timeout: 244 seconds)
06:37:52***Saving seen data "./dancer.seen"
07:00
07:08:42 Join ender` [0] (krneki@foo.eternallybored.org)
08:00
08:03:35 Quit pixelma (Remote host closed the connection)
08:03:35 Quit amiconn (Read error: Connection reset by peer)
08:04:12 Join pixelma [0] (~pixelma@rockbox/staff/pixelma)
08:04:13 Join amiconn [0] (~amiconn@rockbox/developer/amiconn)
08:30:42 Quit yuriks (Ping timeout: 246 seconds)
08:33:13 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
08:34:31 Join yuriks [0] (~quassel@opentyrian/developer/yuriks)
08:37:53***Saving seen data "./dancer.seen"
08:57:13 Join petur [0] (~petur@rockbox/developer/petur)
09:00
09:00:59 Quit petur (Read error: Connection reset by peer)
09:01:28 Join petur [0] (~petur@rockbox/developer/petur)
09:44:34 Quit kugel (Ping timeout: 264 seconds)
09:45:51 Join kugel [0] (~kugel@ip5b42be9b.dynamic.kabel-deutschland.de)
09:45:51 Quit kugel (Changing host)
09:45:51 Join kugel [0] (~kugel@rockbox/developer/kugel)
09:58:34 Quit JanC (Ping timeout: 240 seconds)
10:00
10:12:11 Join JanC [0] (~janc@lugwv/member/JanC)
10:37:57***Saving seen data "./dancer.seen"
10:52:58 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
11:00
11:10:06 Quit pamaury (Ping timeout: 252 seconds)
11:43:53 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
12:00
12:07:09 Join markun [0] (~markun@rockbox/developer/markun)
12:15:38wodzpamaury: ping
12:18:13pamaurywodz: pong
12:19:06wodzpamaury: What libusb_ref_dev() actually does?
12:19:35pamauryadds a reference to the device and return the same pointer
12:19:46pamauryyou absolutely want to get those right
12:19:56pamaurycause the pointer is destroyed when ref count is 0
12:20:54pamauryand read the libusb doc carefully
12:21:14wodzI did and still don't quite grasp how it works
12:21:47pamaurywhat do you mean ?
12:22:20pamaurysome functions create libusb_device pointers, like libusb_get_device_list
12:22:41pamauryinitially the device has ref count 1
12:22:48pamaurywhen count is 0, pointer is destroyed and becomes invalid
12:23:07wodzpamaury: I mean I have hotplug_callback() with libusb_device *dev filled by libusb. Do I need to reference this dev with libusb_ref_dev() or it is permanent and I need to destroy it manually?
12:23:44pamauryyou need to read the doc, let me check
12:25:06pamauryfor future reference: http://libusbx.sourceforge.net/api-1.0/group__hotplug.html
12:26:20pamauryhum doc is unclear, my guess is that the pointer is unreference after the callback so if you want to save it, you need to reference it
12:27:17pamaurysorry wrong link to the doc: http://libusb.sourceforge.net/api-1.0/group__hotplug.html
12:27:33pamauryexample: http://libusb.sourceforge.net/api-1.0/hotplug.html
12:37:59***Saving seen data "./dancer.seen"
12:39:24pamaurywodz: I had a look at the code, apparently the device is unreferenced when it is disconnected, so you probably should add reference
12:40:08pamauryand in the example they provide, libusb_open adds a reference internally
12:40:26wodzpamaury: I'll craft something and let you look at it
12:40:31pamauryok
12:43:26 Join FSanches [0] (~felipe@2804:14c:37:268b:4552:b544:575:c80d)
13:00
13:47:34 Quit markun (Ping timeout: 244 seconds)
13:49:20 Join markun [0] (~markun@rockbox/developer/markun)
13:57:30 Quit markun (Ping timeout: 256 seconds)
14:00
14:04:11 Join jtdesigns01 [0] (~jonathan@2601:400:8000:2669:d19b:417f:a55b:a2b0)
14:12:10 Quit nosa-j (Ping timeout: 264 seconds)
14:21:18 Join nosa-j [0] (~m00k@cpe-24-74-14-251.carolina.res.rr.com)
14:31:43wodzpamaury: Do you think client should be able to close/release device it didn't opened (but it happens is opened by other client)?
14:32:27 Quit nosa-j (Ping timeout: 246 seconds)
14:33:18pamaurywodz: no
14:33:45wodzhmm, this complicates server
14:33:59 Quit jtdesigns01 (Remote host closed the connection)
14:34:14pamauryI mean for a start you could allow this (but clearly if the client does so that's a bug) and later on fix this
14:34:46pamaurybecause then it means you need to keep a per-client list of opened devices so yeah it makes things a bit more involved
14:35:43wodzbut we do allow other client to issue commands to device opened by other client, or not?
14:35:52 Join amayer [0] (~amayer@mail.weberadvertising.com)
14:36:46pamaurywodz: in theory no
14:37:58wodzok, goes back to thinking...
14:38:03***Saving seen data "./dancer.seen"
14:39:32pamauryThis is not very complicated in fact: the server has a list of clients, each client has a list of opened devices it can send commands to or close. The server manages the devices based on that: it opens devices that one or more clients opended and closes them when no client is using it anymore
14:41:37pamauryIf you want I can have a go at the code to shoz you what I'm thinking about
14:43:51wodzI'll try to do this on my own.
15:00
15:55:18 Quit wodz (Remote host closed the connection)
16:00
16:04:54 Join Strife89 [0] (~Strife89@adsl-98-80-221-246.mcn.bellsouth.net)
16:23:47 Quit Strife89 (Ping timeout: 264 seconds)
16:38:06***Saving seen data "./dancer.seen"
16:55:55 Quit mc2739 (Ping timeout: 265 seconds)
16:56:13 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
17:00
17:20:48 Join ZincAlloy [0] (~Adium@2a02:8108:8080:26f0:c530:500a:d8ec:4613)
17:33:41 Quit petur (Quit: Leaving)
17:55:48 Quit amayer (Quit: Leaving)
18:00
18:38:09***Saving seen data "./dancer.seen"
18:41:44 Join TheLemonMan [0] (~lemonboy@unaffiliated/thelemonman)
18:54:23 Quit ZincAlloy (Quit: Leaving.)
19:00
19:22:44 Quit pamaury (Ping timeout: 255 seconds)
20:00
20:00:33 Join JdGordon [0] (~jonno@ppp118-209-9-70.lns20.mel4.internode.on.net)
20:00:33 Quit JdGordon (Changing host)
20:00:33 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
20:04:01 Quit JdGordon_ (Ping timeout: 268 seconds)
20:13:23 Join ZincAlloy [0] (~Adium@2a02:8108:8080:26f0:c179:8cb3:df96:a059)
20:31:07 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
20:38:11***Saving seen data "./dancer.seen"
20:55:30 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon)
20:58:35 Quit JdGordon (Ping timeout: 255 seconds)
21:00
21:07:27 Quit bluebrother (Disconnected by services)
21:07:32 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
21:25:50 Quit amiconn (Read error: Connection reset by peer)
21:25:50 Quit Bray90820 (Read error: Connection reset by peer)
21:26:09 Join Bray90820 [0] (~Bray90820@173-17-46-117.client.mchsi.com)
21:26:26 Join amiconn [0] (~amiconn@rockbox/developer/amiconn)
21:45:55 Join lebellium [0] (~chatzilla@89-93-179-187.hfc.dyn.abo.bbox.fr)
21:47:07 Quit jtdesigns01bot (Ping timeout: 240 seconds)
21:47:07 Quit yosafbridge (Ping timeout: 240 seconds)
21:47:07 Join jtdesigns01bot [0] (~jonathan@c-68-43-178-141.hsd1.mi.comcast.net)
21:47:58 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
21:48:34 Join yosafbridge [0] (~yosafbrid@105.ip-167-114-152.net)
21:50:49 Quit JdGordon_ (Ping timeout: 272 seconds)
21:52:22 Quit JdGordon (Ping timeout: 250 seconds)
21:52:59 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
22:00
22:38:15***Saving seen data "./dancer.seen"
23:00
23:04:48 Quit ZincAlloy (Quit: Leaving.)
23:19:12 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon)
23:20:15 Join wodz [0] (~wodz@89-75-106-221.dynamic.chello.pl)
23:21:34wodzpamaury: See g#1222. This early WIP, untested, probably not working. Please comment about general approach.
23:21:42pamauryok let me see
23:21:50 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 42.0/20151005144425])
23:22:08 Quit JdGordon (Ping timeout: 246 seconds)
23:23:39pamaurywodz: just a small remark, since the server and device protocol are now differing, wouldn't it be better to use different #define to avoiding mixing the two ?
23:24:26pamauryespecially since the usb protocol commands must have special values (0x4x) for usb reasons, whereas the tcp protocol does not
23:25:30wodzpamaury: As you like. tcp protocol is extension. I don't care if commands are 0x4x or something different
23:25:54pamauryyeah it's just that GET_DEV_LIST does not exists in USB
23:26:01pamaurybut it "eats" 0x49
23:26:16pamauryand USB can only have a small number of such commands
23:26:50pamauryanyway, it's not important
23:27:26pamauryoh actually my mistake, you use a different prefix HWSERVER
23:27:44pamauryso yeah forget about it, but use a different value, just to avoid confusion
23:30:30pamaurywodz: do you know C++ ?
23:32:00wodzpamaury: A little bit. I know it could make code cleaner in c++. I am just not fluent in c++;
23:32:08pamauryok no problem
23:36:30pamaurywodz: I don't quite understand what is reflist and dev_list, what is the difference/relationship between the two ?
23:37:22wodzdev_list is global device list as filled by libusb hotplug callback function
23:37:46wodzreflist is per connected client and reflects device the client is connected to.
23:38:33pamauryah ok, right
23:57:49pamaurywodz: The overall principle is fine I think
23:58:12pamauryI'm not sure about some missing libusb_ref_device
23:58:41pamauryalso I *think* there might be race condition between hotplug and server thread

Previous day | Next day