[00:06:52] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [00:07:48] *** Joins: bcobco (~bcobco@77.225.204.119) [00:12:32] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [00:15:20] *** Joins: bcobco (~bcobco@77.225.204.119) [00:29:01] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [00:31:06] *** Joins: bcobco (~bcobco@77.225.204.119) [00:37:08] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [00:37:30] *** Joins: bcobco (~bcobco@77.225.204.119) [00:58:34] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [01:00:09] *** Joins: bcobco (~bcobco@77.225.204.119) [02:11:03] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:11:03] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [02:25:40] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [02:26:04] *** Joins: bcobco (~bcobco@77.225.204.119) [03:12:55] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [03:14:43] *** Joins: bcobco (~bcobco@77.225.204.119) [04:10:50] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [04:11:45] *** Joins: bcobco (~bcobco@77.225.204.119) [05:08:33] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [05:08:56] *** Joins: bcobco (~bcobco@77.225.204.119) [05:30:05] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [05:30:31] *** Joins: bcobco (~bcobco@77.225.204.119) [06:37:25] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 252 seconds) [06:39:00] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [08:11:06] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [08:11:06] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [09:13:55] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [09:15:00] *** Joins: [Saint] (~saint@rockbox/staff/saint) [11:46:49] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [11:47:14] *** Joins: bcobco (~bcobco@77.225.204.119) [12:09:00] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [12:09:55] *** Joins: [Saint] (~saint@rockbox/staff/saint) [12:45:15] user890104: you mean that dokan thing? [12:45:29] I don't think it ever worked reliably or usably fast [12:45:49] dokan isn't exactly stable :/ [12:46:36] I'd rather build a disk mode app for emcore than attempting to resurrect that weird stuff. [12:47:41] remember, we have a userland USB function framework these days ;) [12:47:56] I even built a ramdisk-based test app [12:48:07] now someone just needs to add the missing glue [12:49:19] i.e. a bit of UI to start/stop the whole thing, unmount the FS, connect the read/write calls to the storage API, and maybe add a bit of caching [12:57:01] TheSeven: and make certain windows versions stop bluescreening when they attach a mass storage driver to emCORE's debug interface [12:57:23] you said you have an idea on how to fix it [12:57:34] it should be somewhere in the logs, if you don't remember it [13:06:04] i should be able to make the app work on linux for example (on my raspberry pi) [13:06:35] but before announcing that it's compatible with windows, we should fix the bluescreen [13:06:44] it works fine on windows 8 IIRC [13:19:43] hm... not quite sure what's bluescreening it, but it seems likely that it could be related to the hacky few-kilobytes drive implementation of my test app [13:20:09] i.e. it might possibly even go away on its own once this thing is fully implemented [13:20:45] do you know how much windows interacts with the ipod before it crashes? [14:11:06] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:11:06] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [15:35:24] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [15:36:18] *** Joins: [Saint] (~saint@rockbox/staff/saint) [17:21:57] *** Quits: bcobco (~bcobco@77.225.204.119) () [20:11:04] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [20:11:04] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [22:43:25] TheSeven: if i let windows install its mass storage drivers, then switch from mass storage to debugger, windows crashes immediately [22:43:58] do you know if it sent any SCSI packets before crashing? [22:44:08] or did it just query descriptors? [22:44:14] well i can't think of a way to find out [22:44:24] unless i learn how to attach a kernel debugger [22:44:25] logging on the ipod side [22:44:40] ah, this makes sense [22:44:52] or a bus sniffer ;) [22:44:59] are there any debugging code which does such logging? [22:45:07] is* [22:45:14] no, but it can easily be hooked into the UMS app [22:45:32] just print something to the console when handling a SCSI request [22:45:53] it's actually trying to talk mass storage to emcore's debugging interface [22:46:05] apart from that, the umstest app works fine [22:46:18] but as soon as i terminate it, windows panics [22:46:30] oh... you mean it crashes while LEAVING the app... hm... [22:46:36] yes [22:47:13] what happens if you just unplug it? [22:47:56] well, it's ok, but when i replug it (assuming the app has been terminated when unplugging), windows freaks out [22:48:10] let me test it again [22:48:17] does it freak out even if you unplug, terminate, replug? [22:48:24] (and close all important apps before that :P) [23:27:27] TheSeven: here's what happens: [23:27:40] 1. i install emcore's libusb driver, then launch the ums app [23:28:15] 2. windows finds out that the device is now a composite one, but keeps libusb's driver (usb class changes from 0xff to 0x00) [23:28:40] 3. i uninstall libusb's driver from the composite device and press Scan for hardware changes [23:29:20] 4. windows realizes that it's a composite device, and installs the composite driver, then the child ones (msc+debugger) [23:29:49] 5. i unplug the ipod, ums terminates, then i replug the ipod - bang! bluescreen [23:30:07] if i uninstall the composite driver before replugging, everything works fine [23:30:15] ...or if you reboot, I guess [23:30:32] no, if i reboot it still remembers what driver it uses [23:30:38] and bluescreens during booting :) [23:30:46] yes, but shouldn't it bluescreen-loop then? [23:30:57] yes, that's what it does [23:31:03] (unless i unplug the ipod) [23:31:16] it's a really nasty situation [23:31:20] ok, that is some very useful information at least [23:31:51] can we tell libusb to attach only to specific usb device class? [23:31:58] i.e. windows' funny idea of tracking devices by VID/PID beyond reconnection explodes [23:32:26] quick workaround: use a different PID for the composite device [23:32:45] that should solve it [23:32:45] or maybe a different serial number even [23:32:54] what's the device instance id? [23:33:02] uhm, do we provide *any* serial number? [23:33:08] let me see [23:33:18] I think we at least provide some static nonsense [23:33:26] just wondering if windows even uses that [23:34:00] because then we could possibly get away with sending a hash of the descriptors as that serial number ;) [23:34:12] i only have Device instance path, not device instance id [23:34:26] ...or that [23:34:27] USB\VID_FFFF&PID_E000\5&26E972D6&0&3 [23:34:36] and when ums is running: [23:34:49] * TheSeven wonders what the \5&26E972D6&0&3 part is [23:36:32] 26E972D6 looks like a filesystem serial number, without the dash [23:36:43] but it has no filesystem at all [23:36:55] ah, that's not even the mass storage device [23:37:14] with the composite driver, the instance path is exactly the same [23:37:50] there's a notable difference in Compatible Ids: [23:37:56] USB\DevClass_00&SubClass_00&Prot_00 [23:37:56] USB\DevClass_00&SubClass_00 [23:37:56] USB\DevClass_00 [23:37:56] USB\COMPOSITE [23:37:59] vs. [23:38:30] USB\Class_FF&SubClass_00&Prot_00 [23:38:30] USB\Class_FF&SubClass_00 [23:38:30] USB\Class_FF [23:41:06] also, uninstalling the composite device before unplugging, and then replugging (without rescanning for devices) also does the trick [23:41:17] i'll try the custom PID approach [23:41:31] s/custom/different/ [23:47:09] ok, that worked well :) [23:47:48] now why did that trivial thing take us months to fix? ;) [23:48:03] but as soon as i install libusb's driver to the debugging interface in the composite device, i'll get the same issue ... or not? [23:48:46] I guess not [23:49:15] me too, but that's windows after all... let's see [23:50:10] I mean the problem only occurred if the device went non-composite, right? [23:50:52] yes [23:50:58] ah, i see [23:51:12] now i need to patch emcore.py :) [23:51:39] that's why I wondered if we could work around it by patching the serialnumber, but I guess not [23:52:31] well, we need to start sending a serial number in the first place [23:53:03] it's a string descriptor, so I guess it doesn't influence the device instance path here [23:54:06] ah right [23:55:28] should i patch umstest to use 0xe001 as PID, and libemcore.py to accept it? [23:55:37] then finally complete the ums app :) [23:56:40] and maybe extract & flash a diagmode on the classics? [23:58:28] yes to the first two [23:58:37] I don't think we really need the third [23:59:07] we can as well keep a binary around (inofficially due to copyright) that can just be used through umsboot if needed