[00:24:59] <[7]> user890104: what we need for the userspace interface is basically a way for an app to shut down USB, swap out the usb_data struct (or at least the descriptor and configuration parts of it), and turn it back on again [00:25:15] <[7]> ideally in a way that ensures that the debugging interface will always be available [00:26:13] <[7]> might make most sense to let the app build a usb_data struct with the parts that it needs, which will be copied to a kernel memory allocation by emcore, enhanced with e.g. the debugging interface, and then switched to that [00:27:17] <[7]> this also has the advantage that if an app forgets to deregister its stuff when terminating, the chances are higher that the debugger interface survives (it will survive at least as long as no USB access to an interface or endpoint of the app triggers a callback) [00:28:02] [7]: what about representing ourselves as a composite usb device, that always exposes the debugging interface, and shows up additional child devices, depending on the userspace apps that provide them? [00:28:20] <[7]> I'll probably go for the crude hack rather than a proper abstraction and run app callback code in IRQ mode. I know it's nasty, but everything else would mean lots of effort, overhead and latency. [00:28:50] <[7]> user890104: that's the plan, but for that we need to ensure that the apps don't kick out the debugging interface [00:31:32] well, you was taliking about the number of available endpoints a long time ago, and i remember that there was some issue with that - they were not enough to support both ums and emcore debug interface [00:31:45] or i got that wrong? [00:33:14] <[7]> that's why I completely reimplemented the debug interface to use zero endpoints yesterday and today [00:33:40] <[7]> it breaks libemcore.py compatibility, but I guess it's worth it [00:34:25] <[7]> it now piggybacks on the standard control pipe [00:35:07] <[7]> I guess it's a bit slower now, but who cares [00:51:27] ah, i need to have a closer look at that [00:53:16] * user890104 guesses that [7] also broke compatibility with emCOREFS :) [00:53:40] <[7]> if that isn't based on libemcore, then yes [00:54:04] <[7]> for that one there might actually be a fairly big performance hit as well [00:54:32] <[7]> might make sense to implement a "server" app for that which assists from the ipod side in speeding things up [00:54:57] <[7]> would probably make more sense to just usb mass storage though [00:55:14] <[7]> (although that can't be used concurrently with any accesses from the ipod9 [01:56:48] *** Quits: Guest7017 (~liar@clnet-p09-185.ikbnet.co.at) (Ping timeout: 245 seconds) [02:03:28] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:03:28] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [02:35:07] <[7]> user890104: completely untested draft at a userspace USB registration API: [02:35:08] <[7]> http://paste.pm/8mb.c [06:21:31] *** x56 is now known as woolhook [06:36:39] *** Quits: [7] (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [06:36:47] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [07:18:04] *** woolhook is now known as x56 [08:03:27] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [08:03:27] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Read error: Connection reset by peer) [09:48:30] *** Joins: STeeF (~STeeF@office.hostnetbv.nl) [12:33:58] *** Quits: [Saint] (~saint@rockbox/user/saint) (Remote host closed the connection) [12:35:09] *** Joins: [Saint] (~saint@rockbox/user/saint) [13:25:54] *** Quits: [Saint] (~saint@rockbox/user/saint) (Remote host closed the connection) [13:26:50] *** Joins: [Saint] (~saint@rockbox/user/saint) [14:03:27] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:03:28] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [15:05:13] *** Joins: liar (~liar@clnet-p09-185.ikbnet.co.at) [15:05:13] *** Quits: liar (~liar@clnet-p09-185.ikbnet.co.at) (Client Quit) [16:11:24] *** Quits: [Saint] (~saint@rockbox/user/saint) (Remote host closed the connection) [16:13:36] *** Joins: [Saint] (~saint@rockbox/user/saint) [16:35:44] user890104: userspace USB API + simple USB mass storage test app has been committed :) [19:15:23] TheSeven: thanks, i'm looking at it now [19:16:32] * TheSeven needs to fix some odd build breakage [19:31:34] *** Joins: n1s (~n1s@nl118-168-30.student.uu.se) [19:31:34] *** Quits: n1s (~n1s@nl118-168-30.student.uu.se) (Changing host) [19:31:34] *** Joins: n1s (~n1s@rockbox/developer/n1s) [20:03:29] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [20:03:29] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [20:33:35] user890104: I've committed another round of fixes [20:33:53] building emcore works again over here, and the debug console as well [20:34:02] let me know if you run into any trouble [20:54:04] *** Quits: [Saint] (~saint@rockbox/user/saint) (Remote host closed the connection) [20:55:03] *** Joins: [Saint] (~saint@rockbox/user/saint) [22:25:21] user890104: so do you have everything that you need to start implementing the mass storage app? [22:28:22] TheSeven: seems so [22:29:35] were you able to test the mass storage app on your device? [22:49:27] *** Quits: [Saint] (~saint@rockbox/user/saint) (Quit: No Ping reply in 180 seconds.) [22:49:57] *** Joins: [Saint] (~saint@rockbox/user/saint) [22:53:17] TheSeven: not at the moment, probably later this night [22:53:24] ok [22:54:42] *** Quits: [Saint] (~saint@rockbox/user/saint) (Ping timeout: 256 seconds) [23:00:32] *** Joins: [Saint] (~saint@rockbox/user/saint) [23:43:15] *** Quits: n1s (~n1s@rockbox/developer/n1s) (Quit: Ex-Chat)