> This should take us at least 90% of the way to all usbnet remotes. As far > as i can tell, they unified on the "TCP" protocol on all usbnet remotes > from the 900 on. And by TCP, I don't mean TCP/IP, I mean their TCP remote > protocol. Now that that's fleshed out and the usbnet subsystem if flushed > out, we should be doing well. I have a 1000 I was sent for testing, and > ... I'll test it against this as soon as I have time, life's been hectic > since I moved back to the states.
Cool. It will be interesting to see what PID the 1000 shows up as, because it looks like you were expecting the 1000 to be the PID that the 900 showed up as. So maybe they use the same one. If not, we may have to add other PID's to the kernel patch. > Does the remote constantly DHCP while plugged in? I feel like requiring > our daemon isn't much better... - and I feel like, if we're going to write > one, it should be really because we don't want the user to have to run > some daemon...so perhaps at concordance start time took an interface > name, checked it was configured, configured it, and then waited for a > DHCP packet and answered. Yes, the remote will constantly issue DHCP requests until it receives a reply. I think it issues them maybe every 10-15 seconds or so. My thinking with the stripped down daemon was...we could have a udev rule that, when the usbXX device gets created, would kick off our dhcpd which would assign an IP address to the usbXX device on the host side and also assign an IP address to the remote. (This appears to be how the Windows 7 driver works.) If we wanted to contain the DHCP code inside of concordance, I guess that would be a possibility, but it would require running concordance as root, since DHCP needs to bind to a lower-numbered port. > I've read through the first patch briefly. Overall it looks good, but I > need to read it more carefully. I'll find time to do that this weekend, I > hope. It definitely needs some more comments though. Especially in the > areas that aren't duplicating/porting existing functions - the new > stuff... it needs comments. There's a lot of old code that's not > commented well at all because I haven't had the need to look at it ... > but like, if you change things from, say 68 to 1036, then you probably > had to figure out why that buffer size is useful, so lets write that > down. I have other questions like why we check for usb remotes in the HID > code, or why you added micro-version support but then > assign it to 0, but all of will likely/hopefully become clearer to me when > I read it more carefully (and not on severe lack of sleep). I agree. I could have done a much better job of documenting things. I'll work on a rev 2 which should take care of those things and hopefully be easier for you to read. Scott ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
