[안내] 210914. suo pcb 펌웨어 FN문제
ggmoss2021-09-15 07:56
pc버전 기다리겠습니다. 너무 오래걸리지 않았으면 좋겠네요...
dkrakgksgy2021-09-15 22:38
헛 그럼 가끔 펑션키 활성화 되는 문제를 당장 해결하려면 매장으로 보내야 하는건가요??
Kin252021-09-16 01:00
프로그램을 다운받으셔서 최신펌으로 업데이트한 후에 키매핑 리셋을 한 후에,
fn+shift+1을 눌러서 shift+F1으로 입력이 되면 정상입니다.
fn+shift+1을 눌러서 shift+1로 입력되어 !로 입력이 되면 비정상입니다.
펌웨어 개발자가 방법을 찾아보고 있으나, 시간이 걸릴수도 있고, 로더를 이용하여야만 해결되는 문제일수 있습니다.
fn+shift+1을 눌러서 shift+F1으로 입력이 되면 정상입니다.
fn+shift+1을 눌러서 shift+1로 입력되어 !로 입력이 되면 비정상입니다.
펌웨어 개발자가 방법을 찾아보고 있으나, 시간이 걸릴수도 있고, 로더를 이용하여야만 해결되는 문제일수 있습니다.
매니저2021-09-16 01:04
네, pcb 프로그램을 사용하여 펌웨어 업데이트를 했는데도 FN키 사용에 문제가 있는 경우는 현재 로더를 통해 물리적으로 펌웨어를 넣어줘야만 해결이 되네요.
불편하시겠지만 매장과 가까운 곳이면 잠깐 방문하셔도 되고, 착불로 기보강을 매장으로 보내주시면 펌업후 발송해 드리겠습니다.
불편하시겠지만 매장과 가까운 곳이면 잠깐 방문하셔도 되고, 착불로 기보강을 매장으로 보내주시면 펌업후 발송해 드리겠습니다.
dalchong08192021-09-17 11:14
@매니저
원인을 찾는데 도움이 될까하여 남겨드립니다.
사실 이전과 같은 fn락이 좌측 shift키와 연결되어 남아있는것 같습니다.
shift키가 눌러져있는 상태에서 fn키를 누르게 되면 fn키가 지속적으로 눌러져있는 상태로 인식하는 것 같습니다.
(다른동작을 하지 않고 shift + fn키만 한번 누르고 떼면, 모든 키배열이 fn레이어의 조합으로 고정됩니다. 여기서 fn키를 한번 더 눌럿다 떼면 기본 레이아웃으로 돌아옵니다.)
문제가 발생하는 원인에 대해서도 생각해봤는데
shift + 조합키를 인식하는 기본로직이 이럴 것 같습니다.
A.1. shift를 누르면 shift키가 press됨과 동시에 다음에 눌려질 key 에 대해 wait 하게 됩니다.
A.2. 이때, 일반적인 키(fn을 제외한 ctrl)를 입력하면, 펌웨어는 shift + 조합키에 대한 인식을 비로소 완료하고 초기상태로 돌아옵니다.
다음으로, fn + 조합키를 인식하는 방법도 유사합니다.
B.1. fn키를 누르고 있는동안 키보드의 맵핑은 fn layer의 키값으로 바뀐상태로 대기(wait)합니다.
B.2. 이때, fn키를 제외한 fn layer의 아무 키를 입력하면, 펌웨어는 조합키를 인식하고 비로소 완료합니다.
A의 과정과 B를 보시면 매우 유사합니다.
여기서 문제가 발생하는 핵심은, A->B가 순차적으로 연계될 때 shift가 받아들일 최종키값을 B.2까지 연계하지 못하기 때문입니다.
예를 들어, shift + fn + 1의 정상작동은 shift + f1입니다.
즉, shift + fn + 'third key' 조합에서 third key의 값은 해당 키가 눌러지기 바로직전인 fn의 값으로 결정되는 것 입니다.
하지만 제가 추정하기로 로직이 shift키가 눌린 상태면 마지막 키 값이 fn 의존이 아니라 shift 의존으로 하드 코딩되어있는 것 같습니다.
이 과정에서, shift는 third key와 결합하여 무사히 입력을 종료하지만, fn키는 눌려진 상태에서 마지막값을 받지못해 켜진상태로 락이 걸리는 것 같습니다.
이것이 문제의 이유라면 shift + fn만 눌렀다 떼어도 오류가 발생하여 fn이 락걸려 있는 것도 설명 가능합니다.
따라서 shift + fn + T(third key)가 눌렸을 때는, 이를 처리할때 이를 역순으로
T(fn+T의 값을 입력처리) -> fn(turn을 종료하고 fn+t값을 shift에 리턴) -> shift는 fn에게 받은 리턴 키값을 shift+리턴값 처리하고 입력을 종료.
이렇게 순차적으로 종료해야 할 것 같습니다.
현재는 T-> fn(fn 관련 처리는 무시) -> (shift + T값을 처리) 해서 shift + T처럼 fn처리과정을 건너뛰고 shift만 보기 때문에
fn이 대기 상태로 붕뜨게되는 것이죠. 그래도 저번보다는 많이 고쳐져서 이번에는 좀 더 수정범위가 적을 것 같습니다.
사실 이전과 같은 fn락이 좌측 shift키와 연결되어 남아있는것 같습니다.
shift키가 눌러져있는 상태에서 fn키를 누르게 되면 fn키가 지속적으로 눌러져있는 상태로 인식하는 것 같습니다.
(다른동작을 하지 않고 shift + fn키만 한번 누르고 떼면, 모든 키배열이 fn레이어의 조합으로 고정됩니다. 여기서 fn키를 한번 더 눌럿다 떼면 기본 레이아웃으로 돌아옵니다.)
문제가 발생하는 원인에 대해서도 생각해봤는데
shift + 조합키를 인식하는 기본로직이 이럴 것 같습니다.
A.1. shift를 누르면 shift키가 press됨과 동시에 다음에 눌려질 key 에 대해 wait 하게 됩니다.
A.2. 이때, 일반적인 키(fn을 제외한 ctrl)를 입력하면, 펌웨어는 shift + 조합키에 대한 인식을 비로소 완료하고 초기상태로 돌아옵니다.
다음으로, fn + 조합키를 인식하는 방법도 유사합니다.
B.1. fn키를 누르고 있는동안 키보드의 맵핑은 fn layer의 키값으로 바뀐상태로 대기(wait)합니다.
B.2. 이때, fn키를 제외한 fn layer의 아무 키를 입력하면, 펌웨어는 조합키를 인식하고 비로소 완료합니다.
A의 과정과 B를 보시면 매우 유사합니다.
여기서 문제가 발생하는 핵심은, A->B가 순차적으로 연계될 때 shift가 받아들일 최종키값을 B.2까지 연계하지 못하기 때문입니다.
예를 들어, shift + fn + 1의 정상작동은 shift + f1입니다.
즉, shift + fn + 'third key' 조합에서 third key의 값은 해당 키가 눌러지기 바로직전인 fn의 값으로 결정되는 것 입니다.
하지만 제가 추정하기로 로직이 shift키가 눌린 상태면 마지막 키 값이 fn 의존이 아니라 shift 의존으로 하드 코딩되어있는 것 같습니다.
이 과정에서, shift는 third key와 결합하여 무사히 입력을 종료하지만, fn키는 눌려진 상태에서 마지막값을 받지못해 켜진상태로 락이 걸리는 것 같습니다.
이것이 문제의 이유라면 shift + fn만 눌렀다 떼어도 오류가 발생하여 fn이 락걸려 있는 것도 설명 가능합니다.
따라서 shift + fn + T(third key)가 눌렸을 때는, 이를 처리할때 이를 역순으로
T(fn+T의 값을 입력처리) -> fn(turn을 종료하고 fn+t값을 shift에 리턴) -> shift는 fn에게 받은 리턴 키값을 shift+리턴값 처리하고 입력을 종료.
이렇게 순차적으로 종료해야 할 것 같습니다.
현재는 T-> fn(fn 관련 처리는 무시) -> (shift + T값을 처리) 해서 shift + T처럼 fn처리과정을 건너뛰고 shift만 보기 때문에
fn이 대기 상태로 붕뜨게되는 것이죠. 그래도 저번보다는 많이 고쳐져서 이번에는 좀 더 수정범위가 적을 것 같습니다.
eggo2021-09-29 16:40
@dalchong0819
저도 같은 의견인데여.
초기 우 shift가 fn shift로 맵핑되있는게 문제인거 같습니다.
즉, 우 shift 조합키로 사용하고 나면 fn이 해제 되지 않는게 문제인거 같습니다.
초기 우 shift가 fn shift로 맵핑되있는게 문제인거 같습니다.
즉, 우 shift 조합키로 사용하고 나면 fn이 해제 되지 않는게 문제인거 같습니다.
dalchong08192021-09-17 11:17
추가 하여, 테스트 완성도를 높이려면, shift, ctrl, fn등이 서로 결합되어 3단계 이상 깊이가 있는 조합을 테스트하면 좋을 것 같습니다.
실사용을 하시지 않으시면 찾기 힘들지만, 유저들은 이걸로 문서작업이나 코딩을 하시는 분도 있으셔서 여러가지 단축키를 씁니다.
때문에 아래처럼 자주쓰는 단축키를 꼼꼼히 체크하시면 펌웨어 검증에 도움이 될 것 같네요.
1. 윈도우 관련 단축키 정상작동 유무(링크는 윈도우 관련 단축키 정리한 페이지가 있길래 적어봤습니다)
https://kowal.tistory.com/80
2. MS 오피스 중 엑셀 단축키 정상작동 유무(비지니스 업무상 사장님도 반드시 쓰고계실 프로그램 같아서 적었습니다)
https://susublog.tistory.com/23
테스트를 꼼꼼하게 하는게 쉬운일은 아니지만, 1번과 2번 테스트를 직접하시고 이에 대한 문제가 없다면
사실상 99%의 유저도 문서작업, 각종 프로그램 호환성에서 이상이 없을 걸로 생각됩니다.
실사용을 하시지 않으시면 찾기 힘들지만, 유저들은 이걸로 문서작업이나 코딩을 하시는 분도 있으셔서 여러가지 단축키를 씁니다.
때문에 아래처럼 자주쓰는 단축키를 꼼꼼히 체크하시면 펌웨어 검증에 도움이 될 것 같네요.
1. 윈도우 관련 단축키 정상작동 유무(링크는 윈도우 관련 단축키 정리한 페이지가 있길래 적어봤습니다)
https://kowal.tistory.com/80
2. MS 오피스 중 엑셀 단축키 정상작동 유무(비지니스 업무상 사장님도 반드시 쓰고계실 프로그램 같아서 적었습니다)
https://susublog.tistory.com/23
테스트를 꼼꼼하게 하는게 쉬운일은 아니지만, 1번과 2번 테스트를 직접하시고 이에 대한 문제가 없다면
사실상 99%의 유저도 문서작업, 각종 프로그램 호환성에서 이상이 없을 걸로 생각됩니다.
dalchong08192021-09-17 11:25
마지막으로, 현재 대응하고 계신방법은 임시방편이라 결국에는 소프트웨어 문제라고 생각합니다.
로더로 펌웨어를 올리면 잘 된다고 하셨는데, 제가 생각하기에는 로더자체 문제가 아니라 펌웨어 코드 버전이 서로 섞여서
올리는 환경에 따라, 어떤 것에는 다른코드가 들어가서 운좋게 맞아 떨어지는 것 같습니다.
그 말인 즉, 당장에 로더로 올려서 정삭작동되는 것처럼 보여도... 그 펌웨어 또한 오히려 다른 케이스에서 버전이 꼬임으로 인해
버그가 또 발생할 확률이 엄청 크다는 것입니다.
원하시는분에 한해 그렇게 처리하는 것은 나쁘지 않다고 생각하지만, 결국에는 펌웨어 수정하셔서 한번더 배포하시는 걸 추천드립니다.
+ 저도 fn+shift+1 테스트 해보니, !로 잘못입력되네요.
아마도 대부분의 사용자가 잘못입력될 것이고, 문제를 느끼지 못한분들은 해당 키조합을 사용할 일이 없으시기 때문 같습니다.
아무쪼록, 지속적으로 고쳐나가시는 노력에 대해 응원합니다.
귀찮더라도 이번기회에 계속 기반을 다져나가는게 좋다고 생각합니다.
앞으로 나올 모든 suo미니 배열들에서도 결국 펌웨어를 사용해야 하기 때문에, 이번에 확실히 해두면 앞으로는 훨씬 편하고 문제가 적을것 같네요.
저도 당분간은 새 키보드 빌드 계획이 없지만, 가끔 들러서 응원하겠습니다..ㅎ
로더로 펌웨어를 올리면 잘 된다고 하셨는데, 제가 생각하기에는 로더자체 문제가 아니라 펌웨어 코드 버전이 서로 섞여서
올리는 환경에 따라, 어떤 것에는 다른코드가 들어가서 운좋게 맞아 떨어지는 것 같습니다.
그 말인 즉, 당장에 로더로 올려서 정삭작동되는 것처럼 보여도... 그 펌웨어 또한 오히려 다른 케이스에서 버전이 꼬임으로 인해
버그가 또 발생할 확률이 엄청 크다는 것입니다.
원하시는분에 한해 그렇게 처리하는 것은 나쁘지 않다고 생각하지만, 결국에는 펌웨어 수정하셔서 한번더 배포하시는 걸 추천드립니다.
+ 저도 fn+shift+1 테스트 해보니, !로 잘못입력되네요.
아마도 대부분의 사용자가 잘못입력될 것이고, 문제를 느끼지 못한분들은 해당 키조합을 사용할 일이 없으시기 때문 같습니다.
아무쪼록, 지속적으로 고쳐나가시는 노력에 대해 응원합니다.
귀찮더라도 이번기회에 계속 기반을 다져나가는게 좋다고 생각합니다.
앞으로 나올 모든 suo미니 배열들에서도 결국 펌웨어를 사용해야 하기 때문에, 이번에 확실히 해두면 앞으로는 훨씬 편하고 문제가 적을것 같네요.
저도 당분간은 새 키보드 빌드 계획이 없지만, 가끔 들러서 응원하겠습니다..ㅎ
Kin252021-09-17 11:59
@dalchong0819
mcu도 여러가지로 테스트를 해보고 랜덤하게 발생하는지라, 원인은 로더로 펌을 올릴때 설정문제인거 판단하였습니다.
저희가 보통은 공장에서 로더를 이용하여 펌을 올리는데, 락을 걸어서 pc에서 올리는데 제한이 걸리는게 아닌가 추정이 됩니다.
처음에는 펌버전 관리가 안되서 그런것으로 추정을 했었는데, 좀 더 테스트를 해보니 그것때문은 아닌거 같습니다.
개발자에게 프로그램으로 해결할수 있는 방안을 찾아보라고 얘기는 해뒀습니다.
말씀하신 것처럼 펌웨어의 코드를 변경하면 락이 걸리는쪽을 할수도 있을꺼 같네요.
조언 감사합니다.
저희가 보통은 공장에서 로더를 이용하여 펌을 올리는데, 락을 걸어서 pc에서 올리는데 제한이 걸리는게 아닌가 추정이 됩니다.
처음에는 펌버전 관리가 안되서 그런것으로 추정을 했었는데, 좀 더 테스트를 해보니 그것때문은 아닌거 같습니다.
개발자에게 프로그램으로 해결할수 있는 방안을 찾아보라고 얘기는 해뒀습니다.
말씀하신 것처럼 펌웨어의 코드를 변경하면 락이 걸리는쪽을 할수도 있을꺼 같네요.
조언 감사합니다.
안녕하세요.
지난번 FN+shift+key 조합에서 입력 오류가 있던 펌웨어를 테스트 해보니, 펌웨어에는 문제가 없는것으로 확인되었습니다.
기억에도 고쳐진것을 확인했었는데, 기억이 왜곡된 건지 이상했었습니다.
펌웨어는 전부 고쳐졌는데, pc로 프로그램을 통해 펌웨어 업데이트를 하면, 정상작동되기도 하고, 어떤것은 오류가 나기도 했습니다.
매장에 있는 여러배열의 여러버전 pcb들을 테스트하여도 랜덤하게 오류가 발생하고, mcu생산시기에 따라서도 랜덤하여, 문제점을 찾는데 시간이 좀 걸렸습니다.
결국 문제의 원인을 찾았는데, 로더로 펌웨어를 올리면 정상 작동을 합니다.
로더가 아닌 pc프로그램으로 올린 것도 정상작동하기도, 안하기도 하기 때문에, 로더로 펌웨어를 올리며 설정에서 락이 걸려, pc로 펌웨어 업데이트시 일부영역에 영향을 준것으로 추정이 됩니다.
이전에 올려드린 펌웨어로 작동에 문제가 있으신 분은 기보강만 잘 포장하셔서 매장으로 착불로 보내주시면 로더로 펌웨어를 올려드리겠습니다.
개발자에게 pc프로그램으로 문제없게 펌웨어를 올리는 방법을 찾아보라고 부탁했습니다.