I wonder how the hdcp compliant devices identify the version of the HDCP like 1.4 or 2.2.
Is it during the key share or after the authentication process.
Related
I have an Windows app exe file which updates the firmware of my usb device. For example: ./fwupdater.exe <fw.bin>
Since the above command requires manual upgrade by end user. I am planning to deliver firmware update by using windows firmware update driver.
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/updating-device-firmware-using-windows-update
I could not find a reference example for same publicly.
How can I achieve this updating the firmware using windows driver.
It depends on how your USB device is designed.
I would do it like that:
on D0Entry invoke WorkItem.
WorkItem will check version of the device and version of the file
if there is mismatch and can update (depend on your configuration)
Update the Device via USB Hardware function (depends on your endpoints and etc...)
I am creating custom UI for enabling/disabling the support for TLS 1.0/1.1/1.2/1.3 on OS level (for Windows).
I need to determine whether the current OS supports the different versions of TLS. I've seen the table describing TLS support by Windows version, but following the guideline in Operating System Version:
Identifying the current operating system is usually not the best way to determine whether a particular operating system feature is present.[...] Rather than using the Version API Helper functions to determine the operating system platform or version number, test for the presence of the feature itself.
I don't want to hard code specific version names in my code, so I am looking for way to query whether this particular feature is supported, (e.g. through the Windows API or similar).
P.S. It even seems hard to detect the actual version of the Windows these days, as e.g. both Windows Server 2019 and Windows Server 2022 would return 10.0.
How is linux cdc_ecm driver related to rndis protocol? Is cdc_ecm based on rndis specification from microsoft in any way?
From this wiki page https://en.wikipedia.org/wiki/RNDIS
The USB Implementers Forum (USB-IF) defines at least three non-proprietary USB communications device class (USB CDC) protocols with comparable "virtual Ethernet" functionality; one of them (CDC-ECM) predates RNDIS and is widely used for interoperability with non-Microsoft operating systems, but does not work with Windows.
seems cdc_ecm to be based on microsoft rndis.
CDC-ECM is a standard that was created by USB-IF. It's not related to RNDIS at all. As your quote says, it predates RNDIS. This means it was created before RNDIS existed, so it couldn't be based on RNDIS unless a time machine enters the picture. And if you look at the protocol, it's clearly different.
CDC-ECM works out of the box on Linux hosts, MacOS, ChromeOS, and certain (mainly Samsung) Android phones.
Microsoft decided to create a new Ethernet on USB protocol instead of using the standard that already existed (CDC-ECM). That's just how Microsoft is. So they created RNDIS which isn't a standard and wasn't published. It's a hack based on NDIS, which is an old DOS and Windows 3.11 era network protocol from Microsoft. That's also just how Microsoft is. They like to base stuff on top of older MS software, which is based on even older MS software, going all the way back to DOS. That makes it really complex and hard for anyone else to be compatible with.
Microsoft doesn't include CDC-ECM drivers in Windows, but does have RNDIS drivers.
One can't get Windows to load the included RNDIS drivers, without a INF file, using just the vendor and product ID, device class, etc. There is a non-standard USB device identification descriptor that Microsoft created (see the pattern here) that must be used to identify a RNDIS device to Windows so it will load the generic driver.
Linux has a CDC-ECM / RNDIS combo gadget that is useful for wider compatibility. This appears as a two function USB device. One function is RNDIS and Windows will use this. The other function is CDC-ECM and everyone else will use that. It's not "ECM with RNDIS support". It's two different functions, only one of which can be used at once, that are both created by the same gadget.
I had developed a kernel extension(kext) by IOKit, but it will be deprecated in the future. So I want develope another driver use dext to replace kext using the DriverKit. But I don't find the executable solutions, like that I cannot find the some class to repalce IOMedia. When I intend to include IOKit in my code,I found the TARGET_OS_DRIVERKIT is 1.
Can someone help me? Thanks a lot!
IOMedia is a subclass of IOStorage and part of the IOStorageFamily. As of the macOS 11.2 SDK (Xcode 12.4) this has not yet been ported to DriverKit.
The SCSIControllerDriverKit API has been in beta since WWDC 2020. It didn't ship with the release versions of macOS 11.0.x-11.2. It's included in the (as of this writing) current betas of 11.3. Perhaps it will see general release with macOS 11.3. This is not a direct port of the storage stack; instead, it's essentially a port of the IOParallelSCSIController KPI. This lets you implement a driver for, well, a SCSI controller. Such a driver can tell the OS about one or more SCSI devices, including block devices, and will start receiving SCSI commands from the system, which it is expected to forward to the underlying controller device. It does not allow you to implement "filter" storage drivers, or to issue SCSI commands to other devices in the system.
Are there any public APIs in Mac OS X for checking the High-bandwidth Digital Content Protection (HDCP), and/or Display Port Content Protection (DPCP) compliance of connected displays, or for requiring that your application's output only be displayed on HDCP/DPCP-compliant displays?
I'd like my application to be able to refuse to play back certain content unless these kinds of protection are ensured on all relevant connected displays. I believe Apple is able to do this for iTunes store HD content, but I'm not sure if they are using a private API for this.
How can I guarantee that my application's output is HDCP- or DPCP-protected?
As far as I know (and I've done a lot of homework on it, I am lead engineer for a well known Mac/Win Media Player) Apple is being greedy and not sharing. There is plenty of evidence that newer macbook and mac pro HDMI and Display port connections support the full encryption protocol, and that iTunes is able to query and control it.
Apple appears to be purposely withholding the API, with the intention of preventing any possibility of Blu-ray support on Mac, in order to create leverage for getting the studios to allow HD content for iTunes.