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

core: improve timing in ps2_host_send to fix caps/num LEDs consistency #563

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bruce33
Copy link

@bruce33 bruce33 commented Jul 15, 2018

Thanks for the great project. Typing this on a QPAD MK-80 over USB having both lost their PS/2 to USB adapter and failed to be happy with cheap active adapters not working on both Linux and Mac.

Anyway, I had a problem with the Caps Lock, Number Lock LEDs not being set correctly and the keyboard resetting itself when running on an 8MHz avr pro micro (32u4). Changing the pull-up resistors helped, but given what is said here: http://www.burtonsys.com/ps2_chapweske.htm that the data from host->keyboard is sampled on the rising CLK edge (cf falling edge) then removing the delay would seem appropriate. It could even be done differently, setting the data up just after the WAIT(clock_hi...) ?

I'll own up and say I've only tested this in interrupt mode (pro micro) and only on two PS/2 keyboards - the QPAD MK-80 and an old Chicony KB-5916. The Chicony would also lose some setting of the LEDs before, now both are solid.

@tmk
Copy link
Owner

tmk commented Jul 15, 2018

I think I added those waits to make signal form clean and recognizable when examining with scope. So would prefer to leave those waits if possble, 15us may be too long if keyboard with very fast clocking exists. I guess 5us is safe but not sure.

When you built the firmware did you change setting for 8MHZ, btw? I believe you did but it doesn't hurt to ask. And did you try with 16MHz pro micro?

@tmk
Copy link
Owner

tmk commented Jul 15, 2018

And anyway sending signal for LED setting(converter->keyboard) is best-effort basis(with polling, not interrupt) and could fail in the end when other code with priority like USB task or other interrupts block it.

I would think LED indicator is not critical and good enough if it works like 95% of the time.

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

Successfully merging this pull request may close these issues.

2 participants