Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PS/2 Keyboard recognition on PC power ON inconcistency #21

Open
cmarkak opened this issue Sep 27, 2021 · 4 comments
Open

PS/2 Keyboard recognition on PC power ON inconcistency #21

cmarkak opened this issue Sep 27, 2021 · 4 comments

Comments

@cmarkak
Copy link

cmarkak commented Sep 27, 2021

Hi,

Many thanks for this great library!

In my computer, M/B and PC case incompatibility prevent it from booting properly unless F1 is pressed in the BIOS.

I use an arduino to press F1 after powering on my computer in order to proceed to booting windows and I would like this to be done remotely with an IoT plug.

Currently, I have two ways of powering on my computer:

  1. With the power button directly, when power is supplied to the computer
  2. With an IoT power plug.

I have managed to make it work when I use the power button (with the IoT plug always on). The builtin led corresponding to num lock lights up, so the keyboard_handle() is working as intended) and the F1 button is emulated successfully, proceeding to boot.

But with the IoT plug, when initially powered off, when I turn it on, it is not working. The builtin led does not go to the on state, indicating a problem in communication.

I run a few tweaks/tests on my own with the library to no avail. I imagine it has to do with the initialization timing in the booting sequence because in the case of the IoT plug, there is a slight delay of about 1 second before the computer boots in comparison the the power on button.

I have tested with a working ps/2 keyboard and it works in both cases.

Some observations from my tests

  • The keyboard_init() function completes in both cases
  • I tried including some delays before and after the keyboard_init() function but no luck, maybe it is a matter of more trials combinations?
  • Initially, the CLK and DATA pins are on 5V in both cases, but in the non-working case, when the write function initiates the CLK pin goes to LOW state. That happens for some reason before the call to the write() function because I have also found with a debugging led that the function exits with code -1 when entering "if (digitalRead(_ps2clk) == LOW) {" block.
  • The keyboard_init() function never completes when the windows is already booted. But to be honest the ps/2 keyboard that otherwise works does not get recognized either so maybe this is not relevant.

Any help or insight on the problem would be highly appreciated.

@Hamberthm
Copy link

Hamberthm commented Apr 15, 2023

Been working on PC-Compatibility issues and got progress.

Note that I'm working on an ESP32 fork, as I want to make this Bluetooth enabled.

Check all my findings here: hrko#1

@ole00
Copy link
Contributor

ole00 commented Mar 2, 2024

@Hamberthm thanks for fixing the issue and posting the resolution. I had the same issue as @cmarkak : that is I needed to automatically press F1 key during PC start-up because the bios was complaining a fan is not connected. When the PC was started from cold (power was cut completely for 30 seconds) then the PC did not register the F1 key send by this library during boot. OTOH, when I pressed the PC case Power button (not the power switch on the power supply) 2x to shut the PC down, then start it back on, the F1 key was registered and booting continued. Your changes fixed the cold boot issue and now the F1 key is registered by the Bios in both of the cases (cold start and warm start).

@Hamberthm
Copy link

Glad it helped!

@ole00
Copy link
Contributor

ole00 commented Mar 3, 2024

BTW. the modified code for Arduino (compatible with this repo) can be found here:
https://github.com/ole00/ps2dev
branch: ole-20240302-fix_pc_boot_from_cold

Harvie pushed a commit that referenced this issue Mar 3, 2024
based on @Hamberthm fixes for esp-32. See issue #21

Hamberthm's comments:
* On my 486 PC, ACKs were being missed by the host controller during LED
set command handling. This made the process to end and the controller
to ignore the keyboard after that command. This makes it stable.

* Testing in my Toshiba 205CDS with a combined port, DEVICE ID command was
failing to write the ID properly. Added some loops to shield time to the
controller and get them properly.

* The interface was missing some commands in one of my sytems because of
waiting to send the 0xAA "BAT test success". BAT success should always
be sent a couple of houndred of milliseconds after power up,
regarding state.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants