OpenCore: Can't use usb keyboard on Windows BitLocker recovery menu #1716

Halo-Michael · 2021-07-06T02:07:20Z

I was used OpenCore 0.7.0, with TPM2.0 used BitLocker locked Operating system drive Windows11.
Today I upgraded to OpenCore 0.7.1, and I noticed a new options "SyncTableIds". I think I need that, so I added this entry and set it to "true". Unfortunately when I rebooted my computer, Windows entered into BitLocker recovery menu and it prompts I recently changed my hardware and I needs to entry my recovery code. it doesn't matter, I do have my revovery code.
But unfortunately, keyboard won't work in this menu so I can't entry my recovery code.
It's a usb keyboard connect to the usb2.0 interface on the back of the motherboard. Works on OpenCore Graphics menu but won't work on the followed by BitLocker recovery menu. The keyboard leds didn't off between the two menus. (So I think keyboard control has not yet been transferred?)

Human79 · 2021-07-06T08:13:27Z

Can you disable SyncTableIds and try again?

vit9696 · 2021-07-06T08:16:42Z

You do not need this quirk I believe, it is for Windows 7 with custom SLIC.

Halo-Michael · 2021-07-06T09:41:56Z

You do not need this quirk I believe, it is for Windows 7 with custom SLIC.

Well, this problem is easy to fix. I just need to start Windows directly in the bios without using OpenCore, then the keyboard works and then choose to temporarily disable bitlocker in Windows and restart.
But I think the key point is fix keyboard doesn't work on BitLocker recovery menu via OpenCore boot, not my problem.

Halo-Michael · 2021-07-06T09:45:09Z

I think it is common for users to change the device hardware after enabling bitlocker (even if only a USB flash drive is inserted). If this problem cannot be solved, then the user will have to use a more troublesome method to solve the problem.

Halo-Michael · 2021-07-06T09:45:59Z

@vit9696 so can you re-open it?

vit9696 · 2021-07-06T14:12:38Z

Right, I think I got it. So the problem here is not how you reached bitlocker recovery menu, but the fact it is not working correctly. I.e. there are many legitimate ways to enter this bitlocker menu, and it should normally work.

Well, okay. I need the following:

testing it on Windows 10 as we will not look on Windows 11 unless strictly required.
a video showing how it behaves (i.e. not working keyboard)
a video showing how it should behave (i.e. working keyboard)
your EFI directory would help
your hardware configuration would help

Halo-Michael · 2021-07-06T14:34:01Z

Right, I think I got it. So the problem here is not how you reached bitlocker recovery menu, but the fact it is not working correctly. I.e. there are many legitimate ways to enter this bitlocker menu, and it should normally work.

Well, okay. I need the following:

testing it on Windows 10 as we will not look on Windows 11 unless strictly required.

a video showing how it behaves (i.e. not working keyboard)

a video showing how it should behave (i.e. working keyboard)

your EFI directory would help

your hardware configuration would help

Except for the first item that is difficult to implement (although this is strange, this is my main device, so I can't downgrade it to Windows 10 quickly), others should be available as soon as possible

Halo-Michael · 2021-07-06T15:35:35Z

Right, I think I got it. So the problem here is not how you reached bitlocker recovery menu, but the fact it is not working correctly. I.e. there are many legitimate ways to enter this bitlocker menu, and it should normally work.

Well, okay. I need the following:

testing it on Windows 10 as we will not look on Windows 11 unless strictly required.

a video showing how it behaves (i.e. not working keyboard)

a video showing how it should behave (i.e. working keyboard)

your EFI directory would help

your hardware configuration would help

Okey, here is the video: https://drive.google.com/file/d/1GDFxqqyQjFfxIGoRJzw11d_2VvddEYqt/view?usp=sharing
And here is my OpenCore and my hardware configurations: https://github.com/Halo-Michael/OC-GA-B250M-EVO-Hackintosh

Halo-Michael · 2021-07-11T08:11:21Z

It seems matter with if I enable the GUI or not...

mikebeaton · 2021-07-11T09:17:31Z

Have you tried setting KeySupport=false and add OpenUsbKbDxe.efi to OC drivers list instead? (You should always use one or other of KeySupport and OpenUsbKbDxe and not both.)

Halo-Michael · 2021-07-11T11:17:32Z

Have you tried setting KeySupport=false and add OpenUsbKbDxe.efi to OC drivers list instead? (You should always use one or other of KeySupport and OpenUsbKbDxe and not both.)

Same, and if I only set KeySupport to false without add OpenUsbKbDxe.efi, keyboard will not works on OpenCore GUI menu but works on BitLocker Recovery menu; if I remove OpenCanopy.efi driver(disable GUI), keyboard will works on both menu.

mikebeaton · 2021-07-11T14:32:17Z

You have OpenShell.efi installed and enabled as a tool already. You can confirm that this is nothing to do with Windows 11 if you can confirm that kb input is working (or not working) in OpenShell at all the same times that is it working (or not working) in Win11 BitLocker. Could you check that and confirm the answer?

Halo-Michael · 2021-07-11T15:54:45Z

You have OpenShell.efi installed and enabled as a tool already. You can confirm that this is nothing to do with Windows 11 if you can confirm that kb input is working (or not working) in OpenShell at all the same times that is it working (or not working) in Win11 BitLocker. Could you check that and confirm the answer?

Well, it works

Halo-Michael · 2021-07-11T15:55:14Z

You have OpenShell.efi installed and enabled as a tool already. You can confirm that this is nothing to do with Windows 11 if you can confirm that kb input is working (or not working) in OpenShell at all the same times that is it working (or not working) in Win11 BitLocker. Could you check that and confirm the answer?

Well, it works

With the GUI mode

mikebeaton · 2021-07-11T16:10:25Z

Can you confirm whether these are your results:

KeySupport	OpenUsbKbDxe	OpenCanopy	BitLocker	OpenShell
yes	no	yes	kb does not work	works
no	yes	yes	kb does not work	works
no	no	yes	works	works
yes	no	no	works	works
no	yes	no	works	works

Halo-Michael · 2021-07-11T17:13:40Z

Can you confirm whether these are your results:

KeySupport OpenUsbKbDxe OpenCanopy BitLocker OpenShell
yes no yes kb does not work works
no yes yes kb does not work works
no no yes works works
yes no no works works
no yes no works works

mikebeaton · 2021-07-11T22:57:32Z

Can you try starting Windows from OpenShell : OpenCore -> OpenShell -> Windows (e.g. fs0:\EFI\Microsoft\Boot\bootmgfw.efi)

Halo-Michael · 2021-07-12T05:33:29Z

Can you try starting Windows from OpenShell : OpenCore -> OpenShell -> Windows (e.g. fs0:\EFI\Microsoft\Boot\bootmgfw.efi)

Keyboard works.

vit9696 · 2021-07-12T06:06:08Z

Can I confirm this was OpenCanopy → OpenShell → Windows? If so, can you try creating a custom entry for Windows and choosing Text mode?

Halo-Michael · 2021-07-12T07:24:24Z

Can I confirm this was OpenCanopy → OpenShell → Windows? If so, can you try creating a custom entry for Windows and choosing Text mode?

That makes keyboard works🤔

Halo-Michael · 2021-07-12T07:32:22Z

Can I confirm this was OpenCanopy → OpenShell → Windows? If so, can you try creating a custom entry for Windows and choosing Text mode?

That makes keyboard works🤔

Also if I set text mode to false, keyboard won’t work.

vit9696 · 2021-07-12T07:56:12Z

Right, can you try different values for TextRenderer? I would try BuiltinText first and run Windows normally from OpenCanopy. Will ideally need a table with works/does not, and perhaps a list of negative side effects if any.

Halo-Michael · 2021-07-12T09:16:48Z

Well, I guess the key point is I used CrScreenshotDxe.efi😓. Keyboard works fine after remove the item.

Halo-Michael · 2021-07-12T09:32:19Z

BitLocker recovery menu due to the redundant design principle, in order to avoid being unable to enter the system when the number keys in the keyboard are damaged, the F1~F10 button (F10 is regarded as 0) is used as a substitute for the number keyboard, so it conflicts with CrScreenshotDxe.efi, I think this is the reason .😓

Halo-Michael · 2021-07-12T09:33:53Z

I don't think this has much to do with OpenCore itself, so I will close this issue. (Or you can continue to improve the related logic of CrScreenshotDxe.efi)

Halo-Michael · 2021-07-12T12:48:30Z

Do we still have the datapoint that creating a manual entry for Windows with TextMode=true fixes the issue, even with CrScreenshotDxe.efi installed. Can you confirm? Thx.

Well, keyboard works, and can still get screenshots...

mikebeaton · 2021-07-12T13:08:10Z

@vit9696 - It is still helpful for us if the user can carry out these tests, right? (Starting from a version which does not work, then changing TextRenderer to see if any values make it work.)

Right, can you try different values for TextRenderer? I would try BuiltinText first and run Windows normally from OpenCanopy. Will ideally need a table with works/does not, and perhaps a list of negative side effects if any.

Halo-Michael · 2021-07-12T13:12:29Z

@vit9696 - It is still helpful for us if the user can carry out these tests, right? (Starting from a version which does not work, then changing TextRenderer to see if any values make it work.)

Right, can you try different values for TextRenderer? I would try BuiltinText first and run Windows normally from OpenCanopy. Will ideally need a table with works/does not, and perhaps a list of negative side effects if any.

I tried, none of those combinations makes keyboard work. This did not match the previous test results, and led me to consider whether there was an error in the previous test, so I finally found the real reason.

vit9696 · 2021-07-12T19:15:35Z

So, this is interesting. For us CrScreenshotDxe would work with AppleEvent, by attaching over AppleEvent→RegisterHandler on APPLE_EVENT_TYPE_KEY_UP. That means all the key events would go to this function. Maybe it steals them from the other input handlers somehow?

CC @mikebeaton @mhaeuser

mhaeuser · 2021-07-12T19:47:30Z

@vit9696 Not impossible, but should not as polling is disabled with no active handlers

vit9696 · 2021-07-12T20:37:54Z

Well, does not CrScreenshotDxe essentially create an active handler? Causing polling to happen...

mikebeaton · 2021-07-12T23:25:48Z

I think this is not a general problem with CrScreenshotDxe on all systems. I've been trying using it with BitLocker (both Win 10 and Win 11) on OC-d MacBook Pro and Dell hack - and there are no problems.

(Or rather, using the F10 key within BitLocker is a bit of a problem, since BitLocker wants to use it as an alternative key for 0 - on the hack it takes a screenshot of the BitLocker screen but then hangs all further kb input; on the MBP it fails to take a valid screenshot (saves a 677 byte long invalid file) but does not crash further input. I think these are probably not major bugs, or at least are not the same bug as this issue.)

In no case I've tested does having CrScreenshotDxe prevent all kb input in BitLocker - so whatever the issue is, I think it is also dependent on something about the firmware.

mikebeaton · 2021-07-13T06:34:45Z

Hi @Halo-Michael - sorry if I keep asking request questions, but since some of your data changed. Can you confirm that this issue a) requires CrScreenshotDxe.efi to be present, but b) when it is present, only happens when either KeySupport=true or OpenUsbKbDxe.efi is present.

vit9696 · 2021-07-13T07:06:11Z

Could you please try this? Requires config.plist from master build.
OpenCore-test-r1.zip

For ref:

% git diff
diff --git a/Library/OcAppleEventLib/KeyHandler.c b/Library/OcAppleEventLib/KeyHandler.c
index 87aac0eb..8ebae15b 100644
--- a/Library/OcAppleEventLib/KeyHandler.c
+++ b/Library/OcAppleEventLib/KeyHandler.c
@@ -574,7 +574,7 @@ InternalAppleEventDataFromCurrentKeyStroke (
   UINTN                           NumberOfKeyCodes;
   EFI_CONSOLE_CONTROL_PROTOCOL    *ConsoleControl;
   EFI_CONSOLE_CONTROL_SCREEN_MODE Mode;
-  UINTN                           Index;
+  //UINTN                           Index;
 
   DEBUG ((DEBUG_VERBOSE, "InternalAppleEventDataFromCurrentKeyStroke\n"));
 
@@ -607,7 +607,7 @@ InternalAppleEventDataFromCurrentKeyStroke (
       ConsoleControl->GetMode (ConsoleControl, &Mode, NULL, NULL);
     }
 
-    if (Mode == EfiConsoleControlScreenGraphics) {
+    /*if (Mode == EfiConsoleControlScreenGraphics) {
       for (Index = 0; Index < (NumberOfKeyCodes + 1); ++Index) {
         Status = gST->ConIn->ReadKeyStroke (gST->ConIn, &InputKey);
 
@@ -615,7 +615,7 @@ InternalAppleEventDataFromCurrentKeyStroke (
           break;
         }
       }
-    }
+    }*/
 
     *Modifiers = AppleModifiers;
     Status     = InternalGetCurrentKeyStroke (

Halo-Michael · 2021-07-13T07:17:36Z

Hi @Halo-Michael - sorry if I keep asking request questions, but since some of your data changed. Can you confirm that this issue a) requires CrScreenshotDxe.efi to be present, but b) when it is present, only happens when either KeySupport=true or OpenUsbKbDxe.efi is present.

Only happens when both KeySupport=true and OpenUsbKbDxe.efi is present.
If I set KeySupport=false and OpenUsbKbDxe.efi is present, keyboard won't work in opencore menu, but works in bitlocker menu, and F10 can't take screenshots in bitlocker menu.
If I set KeySupport=true and OpenUsbKbDxe.efi is present, with TextMode=true, keyboard will works in any menu. And if I press F10 in bitlocker menu, type 0 and screenshot will both happen.

Halo-Michael · 2021-07-13T07:31:56Z

Could you please try this? Requires config.plist from master build.
OpenCore-test-r1.zip

For ref:

% git diff
diff --git a/Library/OcAppleEventLib/KeyHandler.c b/Library/OcAppleEventLib/KeyHandler.c
index 87aac0eb..8ebae15b 100644
--- a/Library/OcAppleEventLib/KeyHandler.c
+++ b/Library/OcAppleEventLib/KeyHandler.c
@@ -574,7 +574,7 @@ InternalAppleEventDataFromCurrentKeyStroke (
   UINTN                           NumberOfKeyCodes;
   EFI_CONSOLE_CONTROL_PROTOCOL    *ConsoleControl;
   EFI_CONSOLE_CONTROL_SCREEN_MODE Mode;
-  UINTN                           Index;
+  //UINTN                           Index;
 
   DEBUG ((DEBUG_VERBOSE, "InternalAppleEventDataFromCurrentKeyStroke\n"));
 
@@ -607,7 +607,7 @@ InternalAppleEventDataFromCurrentKeyStroke (
       ConsoleControl->GetMode (ConsoleControl, &Mode, NULL, NULL);
     }
 
-    if (Mode == EfiConsoleControlScreenGraphics) {
+    /*if (Mode == EfiConsoleControlScreenGraphics) {
       for (Index = 0; Index < (NumberOfKeyCodes + 1); ++Index) {
         Status = gST->ConIn->ReadKeyStroke (gST->ConIn, &InputKey);
 
@@ -615,7 +615,7 @@ InternalAppleEventDataFromCurrentKeyStroke (
           break;
         }
       }
-    }
+    }*/
 
     *Modifiers = AppleModifiers;
     Status     = InternalGetCurrentKeyStroke (

Well, it works:

But I was set PlatformInfo-Automatic as true and get this:

mhaeuser · 2021-07-13T07:33:33Z

@Halo-Michael Well, it tells you your config is borked.
Can you confirm it works with text mode off now, and did not before (after fixing the config ofc)?

Halo-Michael · 2021-07-13T07:37:41Z

@Halo-Michael Well, it tells you your config is borked.
Can you confirm it works with text mode off now, and did not before (after fixing the config ofc)?

I can confirm
I means when PlatformInfo-Automatic is true, smbios dictonary shouldn't even be read? my smbios dictonary is empty and I'm using Generic dictonary, there's no such errors before.

mikebeaton · 2021-07-13T07:39:40Z

there's no such errors before

@mhaeuser - I'd just about got to that before op said it, I think separate config validation error in latest version?

mikebeaton · 2021-07-13T07:42:09Z

@Halo-Michael - we're all asking you tests at once, but what happens if you press F10 now, on @vit9696 test version? It outputs 0, takes screenshot (you already said), but after that, is it fine? Kb input carries on as before? (On some of my setups, I was getting 0, takes screenshot, then kb input stops working.)

Halo-Michael · 2021-07-13T07:43:06Z

We fixed a bug, and then add another two :O

mikebeaton · 2021-07-13T07:43:36Z

It's separate, it wasn't introduced by this fix! (And hopefully you'll find the direction of travel is actually the other way! ;) Software between releases is beta, and helpful users like yourself spot any remaining issues.... )

Halo-Michael · 2021-07-13T07:44:12Z

It's separate, it wasn't introduced by this fix!

Oh I know, it's a joke :P

Halo-Michael · 2021-07-13T07:51:49Z

@Halo-Michael - we're all asking you tests at once, but what happens if you press F10 now, on @vit9696 test version? It outputs 0, takes screenshot (you already said), but after that, is it fine? Kb input carries on as before? (On some of my setups, I was getting 0, takes screenshot, then kb input stops working.)

I didn't get kb stop working

mikebeaton · 2021-07-13T08:08:10Z

@Halo-Michael - cc @mhaeuser (sorry!) - I think your config is wrong - you need to not have the <SMBIOS> section at all, not just have it with no items in. (I've just checked, also on 0.7.1 and 0.7.0 and there is no change here.)

Halo-Michael · 2021-07-13T08:11:28Z

@Halo-Michael - cc @mhaeuser (sorry!) - I think your config is wrong - you need to not have the <SMBIOS> section at all, not just have it with no items in. (I've just checked, also on 0.7.1 and 0.7.0 and there is no change here.)

Well, I'm using 0.7.1 and there really have no errors yet

Halo-Michael · 2021-07-13T08:16:34Z

But okey I'll remove it.

mikebeaton · 2021-07-13T08:33:11Z

@vit9696 - removing the dequeue code (as you have done in the test version above) fixes a fundamental problem on my Dell hack too.

Without the change, if I press F10 either within OpenCanopy (before entering BitLocker) or within BitLocker, then from that point onwards BitLocker accepts no key input. I already reported the second part of that above. (Before any F10 keypress, on my system unlike @Halo-Michael's, BL does accept input.)

With the change, it all just works (on my system and on @Halo-Michael 's).

There is no change to behaviour on my MBP (input is never crashed, with or without the dequeue code).

For that reason, I am wondering if removing this needs to be on a flag? Can it just die?!

vit9696 · 2021-07-13T08:48:21Z

@mikebeaton, I believe we should make it a flag.

As for the config, there were XMP parsing changes right after 0.7.1, I am worried whether they might have broken something. @Halo-Michael, can you upload your config?

Halo-Michael · 2021-07-13T08:51:06Z

@mikebeaton, I believe we should make it a flag.

As for the config, there were XMP parsing changes right after 0.7.1, I am worried whether they might have broken something. @Halo-Michael, can you upload your config?

Here is:
https://github.com/Halo-Michael/OC-GA-B250M-EVO-Hackintosh/blob/main/EFI/OC/Config.plist
And I just did some change:
Halo-Michael/OC-GA-B250M-EVO-Hackintosh@e775318

mikebeaton · 2021-07-13T08:52:34Z

@Halo-Michael - can you report behaviour of ocvalidate tool from 0.7.1 on the two different versions of SMBIOS config.plist (with SMBIOS either missing, or empty)? if it shows the errors when SMBIOS is present but empty (as I think it will) then (despite the recent parsing changes) I think it's just that Vit's copy of OpenCore.efi is compiled in such a way as to show you an error which was there anyway.

Halo-Michael · 2021-07-13T09:00:07Z

@Halo-Michael - can you report behaviour of ocvalidate tool from 0.7.1 on the two different versions of SMBIOS config.plist (with SMBIOS either missing, or empty)? if it shows the errors when SMBIOS is present but empty (as I think it will) then (despite the recent parsing changes) I think it's just that Vit's copy of OpenCore.efi is compiled in such a way as to show you an error which was there anyway.

You are right, ocvalidate did report my old config have errors :o

mikebeaton · 2021-07-13T23:21:38Z

Okay, this issue should be fixed in acidanthera/OpenCorePkg@ccf5dac .

To apply the fix you need to set AppleEvent/GraphicsInputMirroring to true.

Halo-Michael changed the title ~~Can't use usb keyboard in Windows BitLocker recovery menu~~ Can't use usb keyboard on Windows BitLocker recovery menu Jul 6, 2021

Halo-Michael changed the title ~~Can't use usb keyboard on Windows BitLocker recovery menu~~ OpenCore: Can't use usb keyboard on Windows BitLocker recovery menu Jul 6, 2021

vit9696 added the project:oc label Jul 6, 2021

vit9696 closed this as completed Jul 6, 2021

vit9696 reopened this Jul 6, 2021

mikebeaton closed this as completed Jul 13, 2021

mikebeaton mentioned this issue Aug 5, 2021

Problem with keyboard selection, when OpenCore’s picker is used in GUI mode #1737

Closed

OpenCore: Can't use usb keyboard on Windows BitLocker recovery menu #1716

OpenCore: Can't use usb keyboard on Windows BitLocker recovery menu #1716

Comments

Halo-Michael commented Jul 6, 2021 • edited Loading

Human79 commented Jul 6, 2021

vit9696 commented Jul 6, 2021

Halo-Michael commented Jul 6, 2021

Halo-Michael commented Jul 6, 2021

Halo-Michael commented Jul 6, 2021

vit9696 commented Jul 6, 2021 • edited Loading

Halo-Michael commented Jul 6, 2021

Halo-Michael commented Jul 6, 2021

Halo-Michael commented Jul 11, 2021

mikebeaton commented Jul 11, 2021

Halo-Michael commented Jul 11, 2021

mikebeaton commented Jul 11, 2021 • edited Loading

Halo-Michael commented Jul 11, 2021

Halo-Michael commented Jul 11, 2021

mikebeaton commented Jul 11, 2021

Halo-Michael commented Jul 11, 2021

mikebeaton commented Jul 11, 2021

Halo-Michael commented Jul 12, 2021

vit9696 commented Jul 12, 2021

Halo-Michael commented Jul 12, 2021

Halo-Michael commented Jul 12, 2021

vit9696 commented Jul 12, 2021

Halo-Michael commented Jul 12, 2021

Halo-Michael commented Jul 12, 2021

Halo-Michael commented Jul 12, 2021

Halo-Michael commented Jul 12, 2021

mikebeaton commented Jul 12, 2021

Halo-Michael commented Jul 12, 2021 • edited Loading

vit9696 commented Jul 12, 2021

mhaeuser commented Jul 12, 2021

vit9696 commented Jul 12, 2021

mikebeaton commented Jul 12, 2021 • edited Loading

mikebeaton commented Jul 13, 2021

vit9696 commented Jul 13, 2021

Halo-Michael commented Jul 13, 2021

Halo-Michael commented Jul 13, 2021

mhaeuser commented Jul 13, 2021 • edited Loading

Halo-Michael commented Jul 13, 2021

mikebeaton commented Jul 13, 2021

mikebeaton commented Jul 13, 2021

Halo-Michael commented Jul 13, 2021

mikebeaton commented Jul 13, 2021 • edited Loading

Halo-Michael commented Jul 13, 2021

Halo-Michael commented Jul 13, 2021

mikebeaton commented Jul 13, 2021

Halo-Michael commented Jul 13, 2021

Halo-Michael commented Jul 13, 2021

mikebeaton commented Jul 13, 2021 • edited Loading

vit9696 commented Jul 13, 2021 • edited Loading

Halo-Michael commented Jul 13, 2021

mikebeaton commented Jul 13, 2021

Halo-Michael commented Jul 13, 2021

mikebeaton commented Jul 13, 2021

Halo-Michael commented Jul 6, 2021 •

edited

Loading

vit9696 commented Jul 6, 2021 •

edited

Loading

mikebeaton commented Jul 11, 2021 •

edited

Loading

Halo-Michael commented Jul 12, 2021 •

edited

Loading

mikebeaton commented Jul 12, 2021 •

edited

Loading

mhaeuser commented Jul 13, 2021 •

edited

Loading

mikebeaton commented Jul 13, 2021 •

edited

Loading

mikebeaton commented Jul 13, 2021 •

edited

Loading

vit9696 commented Jul 13, 2021 •

edited

Loading