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

Jump to bottom

LCD not restored after key press following Latch #295

Closed
dfaught opened this issue Sep 21, 2018 · 9 comments
Closed

LCD not restored after key press following Latch #295

dfaught opened this issue Sep 21, 2018 · 9 comments
Assignees
@haata
Labels
bug
Milestone
v0.5.x

Comments

@dfaught
Copy link

dfaught commented Sep 21, 2018

  • Device:
    Infinity Ergodox Right-side Master (Massdrop 2017)

  • Firmware Origin:
    latest pull from git

  • OS:
    Arch Linux 4.18.8

  • Reproduction Steps:
    Local compile and flash of latest firmware. Both sides flashed.

  • Resulting Issue:
    After flashing firmware from the latest pull Latch# keys no longer restore the LCD to proper state after next key.
@dfaught
Copy link
Author

dfaught commented Feb 19, 2019

Ping.

This is still an issue. In fact, it's worse. Slave side is non-operational using the latest build. Flashed both sides independently, whichever side is the slave is non-responsive.

@haata haata self-assigned this Feb 19, 2019
@haata haata added the bug label Feb 19, 2019
@haata haata added this to the v0.5.x milestone Feb 19, 2019
@haata
Copy link
Member

haata commented Feb 19, 2019

kk, I shall take a look.

@dfaught
Copy link
Author

dfaught commented Feb 19, 2019

Stepping back through commits, 449d4d9 is the last commit I found where the slave half functions. LCD behavior is consistent with the original bug.

@dfaught
Copy link
Author

dfaught commented Nov 3, 2019

Bump... still an issue building against HEAD

@haata
Copy link
Member

haata commented Nov 3, 2019

I'm noticing a few issues on Infinity Ergodox with the LCD status.
Right now I'm using the lcdFuncMap.kll to handle the state transitions. One possible fix is to move to the internal layer signals. The downside of doing this is that KLL configurations will need to be updated (possible re-written) to work with the configurator (it's the right thing to do though).

@dfaught
Copy link
Author

dfaught commented Nov 3, 2019 •
edited

I'm happy to re-write my klls if it will resolve the issue. What do I need to do? I'll also try to get a debug capture of the layer stack tomorrow once I get in to the office. Although the layer behaves properly, just the lcd doesn't return to prior state. Debugging my keyboard beats my real job...

haata added a commit that referenced this issue Nov 16, 2019
@haata
Transitioning layer LCDs to use layer triggers instead key actions
a63346a 
- This should now handle all types of layer events rather than just key
actions
- Currently only mapping layers 1 through 9 (more can be added if
needed, but there are no numbers/colors for those layers)
- Should help with Issue #295
- Removing LayerLatch trigger hack to update the LCD screens
@haata
Copy link
Member

haata commented Nov 16, 2019

I haven't gone through a full set of testing, but this should fix the LCD update issues.

There may still be bugs but these will be more to do with the layer trigger events.

@dfaught
Copy link
Author

dfaught commented Nov 18, 2019

Confirmed. Built from head this morning. Flashed both sides. LCD is properly restored after post latch key press.

@haata
Copy link
Member

haata commented Mar 24, 2020

Pushed to the configurator now.

@haata haata closed this as completed Mar 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@haata haata

Labels
bug
Projects
None yet
Milestone
v0.5.x
Development

No branches or pull requests
2 participants
@haata @dfaught