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

Layer corruption when moving keys (?) #1373

Open
The-Compiler opened this issue Jan 14, 2025 · 4 comments
Open

Layer corruption when moving keys (?) #1373

The-Compiler opened this issue Jan 14, 2025 · 4 comments
Labels
bug Something isn't working

Comments

@The-Compiler
Copy link

Describe the bug

I'm trying to move two keys in a layer for my Atreus. Doing so seems to reproducibly corrupt my keyboard layout.

The first time this happened, I had the layout loaded from hardware (not modified in a while). Here is an older backup I have from my layout, which seems to suffice to reproduce this at least on one layer: Layout.json

To Reproduce
Steps to reproduce the behavior:

  1. Load the layout from above
  2. Go to layer 3 with the F-keys:

image

  1. Shift the F-keys one to the left by reassigning them:

image

  1. Save to device and observe how holding both middle keys and trying to use the F keys now produces numbers sometimes (?), as if I was on layer 2. Various things except the primary layer seem to be broken.

  2. Close and reopen Chrysalis, the data read back from the device is broken in a similar way:

image

image

image

Here is a reexport:
Layout-broken.json

Expected behavior

No such corruption. I'm not sure if there is something wrong in my initial JSON somehow (?), but apparently it also was what was stored on my device in hardware.

Debug bundle

It looks like the problem disappeared while I was trying to get a debug bundle... here it is anyways:
chrysalis-debug.json

Desktop (please complete the following information):

  • OS: Archlinux
  • Chrysalis Version: 0.13.3
@The-Compiler The-Compiler added the bug Something isn't working label Jan 14, 2025
@obra
Copy link
Member

obra commented Jan 14, 2025

Hi, Can you repro this on https://chrysalis.keyboard.io? Chrysalis has moved to the web and there's been a ton of work on reliability since 0.13.3

@tofraley
Copy link

tofraley commented Jan 16, 2025

I've had the same issue intermittently since updating firmware to v0.92.6+116 a week or so ago. I can't remember the previous version I had, but maybe 0.91.x.

First, it was shifting the layout of certain layers left or right several columns, wrapping around. Today it shifted all the keymaps up one row on all layers, top rows of some layers now showing up at the bottom row of layers below them. It also reset the layer names I had set except for "Base" (layer 0).

For example, here is "Base" layer. The value of the highlighted key was on the key below it (the one that now has 5). The numbers were on the top row of layer #1. The highlighted key was the only thing I changed before saving. It was Backspace on tap, Shift to "Arrows" layer when held. I changed it to just Shift to "Arrows" layer . After saving, the layer name changed from Arrows to #2, and all the keys shifted up one row, the numbers are now on the bottom row of layer "Base".
Image

Other layers look to be shifted the same way.
Image

OS: Windows
Chrysalis 0.13.3, desktop app
Keyboard: Keyboardio Atreus
Keyboard firmware: 0.92.6+116

Update: Originally I said the top rows were wrapping around to the bottom layer of the same row. But I realize now they are wrapping around to the bottom of the layer below.

@obra
Copy link
Member

obra commented Jan 16, 2025 via email

@tofraley
Copy link

The web app seems to work fine. For good measure, I flashed the firmware again. There were some errors and it did a factory reset. After that, I loaded the backup of the corrupted layout, and put it all back the way it was originally. That saved to my keyboard without issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants