Fix for keyboard latching

[hasseily]

Referring to #320 the keystroke latch now gets cleared after a configurable number of accesses if the queue is > 1.
I set it to 5 accesses similar to KEGS.

A new keystroke could always replace an existing one, which is the way a non-GS Apple II functions (a new keystroke always overrides an old one), but that would prohibit copy-pasting. AppleWin itself doesn't have a queue and functions that way.

[audetto]

I know I have not the exact same logic as AppleWin. How does it work there?

About code formatting, follow the code format files (for this area it is in source/linux/.clang-format). If not, make sure you follow the rules of the file.

[hasseily]

Applewin doesn't have a queue. Just a latch that gets overwritten when a new key comes, or cleared when the clearing softswitch is triggered.

This works like the OG hardware but it doesn't allow you to paste in text. The more I think about it, the more I believe we should have a user selectable option to enable paste (and have something similar to the PR) or not (in which case the queue should be a single entry, and always overwritten when a new keystroke comes in.

But in no case should it remain as it is now, as multiple apps don't clear the keystroke and do expect it to be overwritten by the next keystroke.

[audetto]

Would it be possible to find a middle ground ?

Copying is a rare event. Can we do the right thing if the queue has size 1, and use the counter only when text had been copied?

If this makes sense.

[audetto]

So, you are saying that if we did not need to worry about copying, we would simply have an std::optional<BYTE> which is equivalent to a queue where we overwrite when a new keystroke arrives.

Correct? Including the pop at the bottom of the file?

I never really understood how it should really be.

[hasseily]

If you don't care about copy paste, you juste need a BYTE variable that keeps the keystroke value.
It's overwritten on a new keystroke coming in, and it's cleared when the soft switch to clear it is triggered.

The problem you have now is that you're using a queue and expect the apps to always clear after the keystroke is read, hence popping the queue. But apps often don't bother, and poll the latch waiting for a change.

[audetto]

What about this then? 7a7aa05

It does the "right" thing for keyboard and still allows current clipboard behaviour only when pasting (which I guess requires cooperation from apps).