I am new to USB and I am trying to develop a library that can do Device Firmware Upgrade in our application.
The DFU Standard http://www.usb.org/developers/docs/devclass_docs/DFU_1.1.pdf talks about Run-Time DFU Functional Descriptor.
I understand what Device, configuration, interface and endpoint descriptors are but I don't know what Functional descriptors are. Therefore my questions are:
1. What is a Functional Descriptor?
2. How do I retrieve information about Functional Descriptor?
I am working with libusbto do my work. So if you have any examples, that'll be great help.
1 - Device, Configuration, Interface, Endpoint are standard descriptors for defining a device and its interfaces. These descriptors contain generic information and can be read by the USB device driver.
But Functional descriptors are device class specific and its known to
only the class drivers. So every class such as CDC, DFU, HID, etc. has
their own functional descriptor specific to the class functionalities.
Functional descriptor describes the class specific contents within interface descriptor. A class specific interface descriptor can have more than one functional descriptor. Functional descriptors have common header format.
2 - Since functional descriptors are part of class interface descriptor, please read the interface descriptor using libusb API and you will get the functional descriptor too.
Related
I am making a custom USB device which will be sending sensor values when requested from the host (i.e. Computer) via USB.
I looked for Communications and CDC Control & CDC-Data Class, they seemed to do the job and are seen as Virtual COM Port.
Will they be always seen as COM PORT or can be detected something else.
What other class or method is preferable for such example?
Someone suggested CDC class to similar application
Note:
Using STM32 microcontroller
That is the idea of the USB classes to be enumerated particular way. If you want driverless class on any system - I advice HID,
TL;DR: How do you encode and decode an MTLSharedTextureHandle and MTLSharedEventHandler such that it can be transported across an XPC connection inside an xpc_dictionary?
A macOS application I'm working on makes extensive use of XPC services and was implemented using the C-based API. (i.e.: xpc_main, xpc_connection, xpc_dictionary...) This made sense at the time because certain objects, like IOSurfaces, did not support NSCoding/NSSecureCoding and had to be passed using IOSurfaceCreateXPCObject.
In macOS 10.14, Apple introduced new classes for sharing Metal textures and events between processes: MTLSharedTextureHandle and MTLSharedEventHandle. These classes support NSSecureCoding but they don't appear to have a counter-part in the C-XPC interface for encoding/decoding them.
I thought I could use something like [NSKeyedArchiver archivedDataWithRootObject:requiringSecureCoding:error] to just convert them to NSData objects, which can then be stored in an xpc_dictionary, but when I try and do that, I get the following exception:
Caught exception during archival:
This object may only be encoded by an NSXPCCoder.
(NSXPCCoder is a private class.)
This happens for both MTLSharedTextureHandle and MTLSharedEventHandle. I could switch over to using the new NSXPCConnection API but I've already got an extensive amount of code built on the C-interface, so I'd rather not have to make the switch.
Is there any way to archive either of those two classes into a payload that can be stored in an xpc_dictionary for transfer between the service and the client?
MTLSharedTextureHandle only works with NSXPCConnection. If you're creating the texture from an IOSurface you can share the surface instead which is effectively the same thing. Make sure you are using the same GPU (same id<MTLDevice>) in both processes.
There is no workaround for MTLSharedEventHandle using public API.
I recommend switching to NSXPCConnection if you can. Unfortunately there isn't a good story for partially changing over using public API, you'll have to do it all at once or split your XPC service into two separate services.
I use JPype to build a SOAP client in my python based test platform. However, I need to extend a Java class to make a call like this:
Like
void process(Context parameter)
The type Context here is a class and to give an implementation, I need to extend Context in python using JPype.
class MyContext extends Context { //override the methods}
With JProxy functionality (in JPype), I'm able to "implement" java interfaces.
But I want to extend a class not an interface. Any help is appreciated.
This very much a limitation. JPype does not allow sub-classing.
sourceforge link
Changed the SOAP method to accept an interface in the API contract.
JPype is an effort to allow Python programs full access to Java class libraries. This is achieved not through re-implementing Python, as Jython/JPython has done, but rather through interfacing at the native level in both virtual machines.
Eventually, it should be possible to replace Java with Python in many, though not all, situations. JSP, Servlets, RMI servers and IDE plugins are all good candidates.
Once this integration is achieved, a second phase will be started to separate the Java logic from the Python logic, eventually allowing the bridging technology to be used in other environments, i.e. Ruby, Perl, COM, etc ..
I have some custom DirectShow filters with custom property pages. These work fine when the filter is in the same process as the property page.
However when I use the 'connect to remote graph' feature of Graph Edit the property pages don't work.
When the property page does a QueryInterface for my private COM interface on the remote filter, the QueryInterface fails. Property pages of Microsoft filters (e.g. the EVR video renderer) work fine so it must be possible.
Presumably this is happening because my filter's private interfaces only work 'in process' and I need to add extra COM support so that these interfaces will work with an 'out of process' filter. What do I need to do in COM terms to achieve this?
Do the DirectShow baseclasses support these COM features? Can I reliably detect when the filter is running out of process and refuse to show the property page gracefully?
One option is to build a proxy/stub pair. But another, and way easier, is to make your private interface automation compatible (derive from IDispatch, type constranits apply), and put it into type library, which is to be attached to the DLL, and registered the usual way. Proxy/stub pair will be supplied for such interface automatically without need to bother.
DirectShow base classes do not offer built in support for this. Stock DirectShow filters provided with Windows might be not not be compatible with passing interfaces over process boundaries and my guess would be that it depends on the team in charge for respective development years ago. Video renderers, for instance, have interfaces that you can connect remotely through. Audio renderers, on the contrary, have interfaces without such capability in mind and they just crash one of the processes attempting to makes such connection (client side process, if my memory serves me right).
I have a COM interface GUID but I don't know that interface definition. I don't know what methods it has, what parameters they have and so on. How can I obtain such information? Is it possible in general?
Practical problem is obtaining interface definition for few COM interfaces defined in actxprxy.dll. For example IFileDialogPrivate ({AC92FFC5-F0E9-455A-906B-4A83E74A803B}). (Obviously the interface is not documented and the name does suggest there is a reason for that.) I tried to use OLE/COM Object Viewer (OleView.exe) for that but wasn't able to get the interface definition.
I am trying to implement IFileDialogPrivate while doing some experiments on forcing IExplorerBrowser control to filter Windows 7 library folders. IFileDialog (which seems to use IExplorerBrowser) does it somehow and IExplorerBrowser askes service provider for IFileDialog and IFileDialogPrivate if ICommDlgBrowser is provided so I tryied to explore that interface. (Also it asks for few other interestingly named interface - could be useful).