Diff: Readme.md

Revision:

1:0c3b6cc480b6

Parent:

0:1a3aa2e25db9

--- a/Readme.md	Fri Nov 04 22:07:07 2016 +0000
+++ b/Readme.md	Mon Feb 13 14:56:00 2017 +0000
@@ -179,6 +179,9 @@
     bool WinUSBDevice::USBCallback_request()
     {
         
+Returning false means 'I didn't handle this; carry on as you were'. Returning true means
+'I've handled this and stored a response in transfer'.
+                
 First we need a reference to the transfer structure which contains both the request information
 and provides a place to store our response. The USBDevice::transfer member is actually private
 but there is a protected function to access it. (Thank you mBed people - I always knew your APIs were the best!
@@ -187,15 +190,10 @@
         // This can never be null.
         CONTROL_TRANSFER& transfer = *getTransferPtr();
         
-Check if the setup is addressed to the device. It can also be addressed to an interface or an endpoint
-but we do not care about these. More advanced devices may do, and in that case you may wish to use
-MSOS Descriptors 2.0 which support treating interfaces separately.        
-        
-        if (transfer.setup.bmRequestType.Recipient != DEVICE_RECIPIENT)
-            return false;
-    
-Note that returning false means 'I didn't handle this; carry on as you were'. Returning true means
-'I've handled this and stored a response in transfer'.
+Requests can be addressed to the device, an interface or an endpoint. Most WinUSB requests are addressed
+to the device, but the Extended Properties request is sent to the interface, so we'll just ignore what
+the recipient is. We only have on interface anyway.
+
 
 Next we see if this is a request for the 0xEE string descriptor.
     
@@ -250,3 +248,5 @@
 And we're done! Next we need a USB class that takes advantage of this WinUSBDevice class and
 responds to our control transfers.
 
+
+...WIP...