Added EFI_SIMPLE_POINTER_PROTOCOL patch for APTIO IV on Z87

[vit9696]

I kind of completely forgot about it, and submit it only now, but perhaps some people will still find it useful. The added patch fixes EFI_SIMPLE_POINTER_PROTOCOL GetState implementation in certain APTIO IV implementations, where the pointer does not move (click) unless you hold a button at the same time you move the mouse.

The implementation looks like this, and the patch simply replaces OR by AND.

EFI_STATUS SimplePointerGetState(EFI_SIMPLE_POINTER_PROTOCOL *Protocol, EFI_SIMPLE_POINTER_STATE *State)
{
  if ( !State )
    return EFI_INVALID_PARAMETER;
  if ( gUsbData->MouseData[0] == -1 )
    return EFI_NOT_READY;
  MouseGetRelativeData(gUsbData->MouseData);
  TranslateUsbKey(gUsbData->MouseData);
  // The condition here is obviously wrong, was meant to be "nothing happened" not "both not happened"
  if ( !gMouseData->AmiMouse.State.PosChanged || !gMouseData->AmiMouse.ButtonChanged )
    return EFI_NOT_READY;
  gBS->CopyMem(State, &gMouseData->PosX, sizeof(EFI_SIMPLE_POINTER_STATE));
  gMouseData->PosX = 0;
  gMouseData->PosY = 0;
  gMouseData->PosZ = 0;
  gMouseData->AmiMouse.State.PosChanged = FALSE;
  gMouseData->AmiMouse.ButtonChanged = FALSE;
  return EFI_SUCCESS;
}

An example of the faulty firmware could be found here: https://www.asus.com/ru/Motherboards/Z87PROV_EDITION/HelpDesk_BIOS/
From what I know only the latest APTIO IV implementations are affected, so almost all Z87 and probably some Z97.

Just in case you may find it useful, here is the header for reverse-engineered AMI proprietary mouse pointer protocol (https://github.com/vit9696/AptioFixPkg/blob/master/Platform/AptioInputFix/AmiPointer.h). From what I know it still exists on APTIO V.

[vit9696]

I think there is a good reason for adding another patch to unlock several ASUS Z97 boards from NVRAM write limitations, which @Download-Fritz and I explored not so long ago ago. However, I do not think one could add it to UEFIPatch at the moment. It will not find the sequence, most likely due to section subtype DXE/SMM.

An example with a faulty firmware could be found here:
https://www.asus.com/ru/Motherboards/MAXIMUS_VII_IMPACT/HelpDesk_BIOS/

And a patch for the most recent firmwares should be similar to that:

842A454A-75E5-408B-8B1C-36420E4E3F21 10 P:9801000072:0000000072 

Fortunately the list has always had 17 entries, so it should be pretty reliable for newer firmwares. For older firmwares it seems that 49 83 3C 24 00 75 -> EB 05 90 90 90 75 would work.

More details are posted here and here.

Also, might there be any binary releases for macOS in the future? Since fixes appear from time to time, it would be nice to be able to use the latest UEFITool and stuff.

[vit9696]

Implemented in master (8bfa302).