Driver update coming [message #109946] |
Thu, 11 February 2021 14:25 |
mikeaudet
Messages: 477 Registered: February 2009 Location: Canada
|
Senior Member |
|
|
Hi Everyone,
I just thought that I would share some progress on PARIS work I've been doing. I was planning to do this work last spring, but COVID has changed everything.
I started reading a book on the Windows Driver Foundations last spring, the latest standard for Windows drivers. I read it cover to cover, taking notes as I went. I’d looked up WDM power management a few years ago, and at the time, it was daunting. WDF has power management just built in, so that seemed a better way to go. The book was huge. I got to the end, and opened up Microsoft's latest sample audio driver. That's when I realized that Windows still uses the pre-WDF driver model for audio drivers. Back to the drawing board.
So, I went through my old driver books, and started looking up how to add the power management code to WDM drivers and found what I needed. I sat down over the Christmas break to get started. I had to piece together a PC out of parts in my basement because my son is using my PC for online school and playing online with his friends while we’re stuck at home because of COVID. I put together a Phenom X4 with 8 GB of RAM.
I put two EDS card in, and attached MEC worked fine, but the 442 didn’t initialize. It took about a week to figure out what was going on, but it turned out that the 442 was transmitting bytes faster than my 2 GHZ Phenom X4 could pick them up. To make a long story short, I had to figure put a way to detect if a 442 is present in a new way because the “Who is out there” command would come back scrambled because of the 442 writing bytes too fast. A 442 and an MEC need the “slow down your transmit” command sent differently. While I was in that section, I rewrote the init code so that all interfaces are initialized in parallel on separate threads. I also got rid of all the time delays and replaced them with events. Start-up is amazingly fast.
Then, I got to work on the power management in the Scherzo. My first draft blue screened within seconds, but I just got it working last week. The driver can now handle a sleep or a hibernation, and upon wake, PARIS can be loaded without needing to restart the PC. It also sends commands to prevent sleep while the PARIS hardware is in use. I wish I could support hibernation and sleep while using the PARIS hardware, but the effects loading and a bunch of other things weren’t designed with this in mind.
Next, I’m going to add code to allow the checkbox in the device manager to select turning off the hardware when it’s not in use. Finally, I’m going to see if I can get rid of needing to run PARIS as administrator, but I’m not promising anything. I may not be able to get all that done by April.
April is when Microsoft’s cross signed driver certificates expire, and they’ve decided not to renew them. Going forward, only EV certificates will be allowed for driver signing. Plus, all drivers will have to be submitted to Microsoft for their signature, too. To submit the driver to Microsoft, one needs to be a Certified Microsoft Partner. I’m now a Certified Microsoft Partner, but I don’t have an EV certificate, and they are ridiculously expensive and hard to get. After April, I will likely only be able to provide unsigned driver updates, so I want to get as much done before then as I can.
That’s all I have to share. I hope everyone is staying safe!
|
|
|
|
|
|
|
Re: Driver update coming [message #109953 is a reply to message #109952] |
Sun, 14 February 2021 09:13 |
mikeaudet
Messages: 477 Registered: February 2009 Location: Canada
|
Senior Member |
|
|
Hi Ted,
My certificate expires in the fall, but the cross signed certificate that it relies upon expires in April. So, in April, I'll still be able to sign a driver, but Windows won't load it unless integrity checks are disabled. It's an extra step to disable integrity checks in addition to disabling secure boot, but it might be workable. I might be able to renew the certificate in the fall, and we can just keep working like that, having to disable secure boot and integrity checks. Alternatively, I can self sign the driver, and using the driver will require installing my certificate on the root certificate on the PC and putting Windows in "Test Mode" so that it will accept any certificate. This puts a water mark in the corner of the screen, but the driver will load. Some programs that rely on copy protection, like say a blue-ray player, may be programmed not to work in test mode.
It's basically a huge pain.
Maybe if I have time to move things forward enough, we might fund-raise to buy one year of EV certificate and cover any legal fees when we feel the driver is basically finished. But, after the year, I lose the ability to address bugs or adjust to OS changes in the kernel driver without coming up with another $500 US for the cert and whatever additional legal fees are involved. It's all a huge pain.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|