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

[Bug] Matrix scan issues on Planck Rev 6 and Rev 6.1 on versions 0.7.6 and up #8610

Closed
vomindoraan opened this issue Mar 30, 2020 · 9 comments · Fixed by #14488
Closed

[Bug] Matrix scan issues on Planck Rev 6 and Rev 6.1 on versions 0.7.6 and up #8610

vomindoraan opened this issue Mar 30, 2020 · 9 comments · Fixed by #14488

Comments

@vomindoraan
Copy link
Contributor

vomindoraan commented Mar 30, 2020

Describe the Bug

Pressing certain keys on Planck Rev 6 and Rev 6.1 results in multiple presses being registered, as if the board had ghosting issues. This is not a hardware/electrical issue since it works fine on older versions of QMK.

For example, pressing Enter on the default keymap outputs tg'. It seems to be a matrix scanning issue.

image

After some investigation and testing, I've determined that the broken behavior was brought about by #6140. This PR removed the custom matrix.c files for Planck Rev 3 and Rev 6 since the DIP switch functionality contained therein was made a core feature. However, this apparently also messed with the scan/debounce timing (or something of the sort), which resulted in broken matrix scanning.

System Information

  • Keyboard: Planck
    • Revision: Rev 6, Rev 6.1
  • Operating system: Windows
  • ARM GCC version: 6.3.1 20170620
  • QMK Firmware version: 0.7.6 and up

Additional Context

This issue was also experienced by the OP of this thread on the OLKB subreddit. Setting DIP_SWITCH_ENABLE = no as @drashna suggested in the thread didn't fix the problem.

Other affected boards may include Planck Rev 3 and Preonic Rev 3.

@alex-ong
Copy link
Contributor

(I don't have a planck)

Old debounce code; debounc_timer is part of scanning.

scan:
    scan cols:
        scan col
             compare col to previous scan / set debounce timer.
             store as columns in buffer

    check debounce timer:
        propagate to matrix, converting from columns to rows.

new: Debounce timer only updated at end of scan.

scan cols:
    scan col, store as rows in buffer, compare col to previous scan (set bool if changed)
debounce(pass in bool):
   if diff, set timer.
   if timer expired, propagate to matrix

While they are not exactly the same, to my eye they should be equivalent. The scanning code also looks equivalent-ish to qmk-cores default implementation. Only difference i can see is maybe how long it waits between pin-sets, working code uses 20us, new code (matrix.c) uses matrix_io_delay() which defaults to 30us. A longer delay shouldn't result in any weird noise chatter.

You could restore the custom_matrix and see if that works first; That way you have latest qmk_core but using old custom_matrix, hence excluding changes in qmk_core as part of the problem.

@DonnieWest
Copy link

Just chiming in here that I am also experiencing this problem. Fresh clone of the qmk project resulted in this issue. If there's anything I can do to troubleshoot just let me know

@DonnieWest
Copy link

I can confirm that switching back to the old matrix file for Planck Rev 6 resolves the issue for me

@timshearer
Copy link

Think I've also had this issue on my Preonic Rev 3. When pressing a particular key ("U" in my case) I would sometimes get no output and sometimes get multiple keypresses. I switched back to the custom matrix and that seems to fix it (or at least it has so far).

@speedRS
Copy link

speedRS commented Jun 5, 2021

@timshearer Having similar problems myself. Old post I know but any guidance on how to switch back to the old matrix?

@timshearer
Copy link

@speedRS I managed to fix my issue but unfortunately I'm not 100% sure how! There is a possibility that it was hardware related though as I think it may have resolved after I reseated a switch. So perhaps an intermittent connection.

@jsebdev
Copy link

jsebdev commented Sep 8, 2021

Could anyone tell me how to switch back to the old matrix file for Planck Rev 6?
Please and thank you very much

@samjonester
Copy link

samjonester commented Sep 13, 2021

I found this thread after chatting in discord. My new planck/rev6 from Drop was registering phantom keypresses and behaving erratically. Old firmware worked flawlessly with the board. I was directed here and to PR 6140 which removed a custom matrix file for the planck/rev6.

With the approach below, I was able to qmk compile -kb planck/rev6 -km default && qmk flash -kb planck/rev6 -km default. I've also been able to compile and flash with minimal customizations to the default keymap with these steps.

  1. From PR 6140, I added the file keyboards/planck/rev6/matrix.c back into my qmk project.
  2. I removed an include on line 8 for backlight.h which no longer exists.
  3. I reversed the diff to reference and enable the custom matrix.c file.
  4. I ran qmk compile -kb planck/rev6 -km default && qmk flash -kb planck/rev6 -km default
  5. I tested with https://www.keyboardtester.com/
  6. I ran qmk new-keymap -kb planck/rev6 -km <GH_USER> and made a few customizations.
  7. I ran qmk compile -kb planck/rev6 -km <GH_USER> && qmk flash -kb planck/rev6 -km <GH_USER>
  8. I tested with https://www.keyboardtester.com/
  9. I rejoiced that RSFT_T(KC_ENT) gave me a right shift key AND an enter key without moving any keycaps!

This isn't a permanent solution. The custom matrix file is out-of-date and radically different from others in the project. However, it enabled me to successfully compile and flash my planck with qmk v0.14.14. I think this suggests that the default firmware created with the default matrix file is incompatible with the latest hardware from Drop.

@jackhumbert
Copy link
Member

Thanks for all the insight here, folks. @samjonester, thanks for outlining your solution as well - @drashna has opened #14488 that adds an additional revision for the Planck & Preonic with these changes. I've also uploaded the binaries here for quickly testing this solution. I don't have a whole lot of insight into why this has become a bigger issue right now, but it may have something to do with lower tolerances somewhere along the supply chain/manufacturing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants