Am 05.06.2019 07:58 schrieb Martin Kepplinger:
I can test later but I think I can see what happens. It fixes the issue, but still prints "ERROR: Keyboard set scancode failed!".
There's also a chance that it'd prematurely "return;" slightly later - in this case my tiny patch wouldn't fix the issue and commenting out the another return would be also required
On Thu, Jun 6, 2019 at 9:50 AM Martin Kepplinger martink@posteo.de wrote:
On 06.06.19 08:20, Paul Menzel wrote:
Dear Martin,
First, please try to use interleaved style for quoting.
On 05.06.19 13:47, Martin Kepplinger wrote:
Am 05.06.2019 07:58 schrieb Martin Kepplinger:
I can test later but I think I can see what happens. It fixes the issue, but still prints "ERROR: Keyboard set scancode failed!".
If we know that it's no error on at least one platform, we shouldn't print "ERROR" IMO, but as long as the bug gets fixes, I guess I'm fine.
It’s how it was done before, and I think it is useful to have error messages especially in case it aborts. Just to be sure, is the message
ERROR: Keyboard set scancode failed!also new for you, or did you see it in the past before the change resetting the keyboard, but the keyboard kept working. (Maybe with no reset it was still working because of the initialization by SeaBIOS or GRUB.)
it's new. Before the change that adds the reset, all was fine and no errors printed.
Paul, what do you think about removing the return and error message from the RESET cmd? Other thoughts?
Your error is not about the failing reset command anymore.
You should be ablet to work around it by selecting LP_PC_KEYBOARD_IGNORE_INIT_FAILURE in the libpayload configuration.
how do I select that?
Maybe that should be selected by default or we should indeed remove all the returns from the error paths in the hope the keyboard will be functional despite the non-working commands before.
We must add a fix. If you can select said config by default for libpayload users, that's fine. Otherwise, remove the return I guess...
thanks, martin