When USB keyboard support is enabled the BIOS begins to emulate normal PS/2 keyboard and this will take CPU time, since USB is a bit of a complex animal compared to the dedicated interfaces.
Corruption like that shouldn't happen though, this suggests the emulation is buggy and maybe a different BIOS version fixes that but you'll still get the performance hit and only way to avoid it is to use a PS/2 keyboard (or USB one with an active converter, or a keyboard that talks PS/2 natively and can use a dumb port adapter).

Tiido wrote on 2023-07-14, 17:50:

When USB keyboard support is enabled the BIOS begins to emulate normal PS/2 keyboard and this will take CPU time, since USB is a bit of a complex animal compared to the dedicated interfaces.
Corruption like that shouldn't happen though, this suggests the emulation is buggy and maybe a different BIOS version fixes that but you'll still get the performance hit and only way to avoid it is to use a PS/2 keyboard (or USB one with an active converter, or a keyboard that talks PS/2 natively and can use a dumb port adapter).

The corruption is that either this happens:

or this happens:

Or both happen at the same time:

It juse seems random but the idea that the keyboard is the cause was because it does not seem to happen by itself and corruption also happens right after a key press. Basically after a key press the screen goes black and picture returns corrupted.

It isn't so much that it is the keyboard that is the cause but how BIOS is handling USB to PS/2 emulation, this is a most likely software (BIOS) related issue. Implementations that I see use SMI to do these sort of things and SMI handler, on at least intel CPUs, uses part of video range (A0000) to hold its code. Whenever SMI happens, video hardware is essentially paged out and normally inaccessible code becomes available instead, CPU does its thing there, finishes and things return as if nothing happened... but it looks like something goes wrong along the way. A different BIOS version might help here.

Tiido wrote on 2023-07-14, 21:49:

It isn't so much that it is the keyboard that is the cause but how BIOS is handling USB to PS/2 emulation, this is a most likely software (BIOS) related issue. Implementations that I see use SMI to do these sort of things and SMI handler, on at least intel CPUs, uses part of video range (A0000) to hold its code. Whenever SMI happens, video hardware is essentially paged out and normally inaccessible code becomes available instead, CPU does its thing there, finishes and things return as if nothing happened... but it looks like something goes wrong along the way. A different BIOS version might help here.

Thank you. I might be forced to make a choice of not using usb keyboard because I am using newest version of bios I have found and with older bios you would lose support for newer cpus.