Độ trễ bàn phím dựa trên ngăn xếp sử dụng bàn phím Logitech MX3100


6

Tôi đã sử dụng bàn phím Logitech Cordless Desktop MX3100 được một thời gian. Tôi chưa bao giờ thực sự có bất kỳ vấn đề, ngoại trừ lỗi đánh máy thường xuyên.

Tuy nhiên, tôi nhận thấy rằng tôi có xu hướng tạo ra lỗi đánh máy "Laod" thay vì "Tải", thường xuyên hơn một chút so với bất kỳ lỗi đánh máy nào khác. Khi nó bắt đầu trở nên căng thẳng, tôi quyết định làm một số thử nghiệm.

Những gì tôi phát hiện ra là hơn khi tôi viết "tải" chữ thường, tôi sẽ không bao giờ mắc lỗi đánh máy. Tất cả chữ hoa hoặc chỉ chữ hoa L, tôi thường mắc lỗi đánh máy. Thử nghiệm thực tế (rất khoa học) của tôi có lẽ được mô tả tốt nhất bằng cách hiển thị đầu ra:

moatmoatmoat
MoatMoatMoat

loatloatloat
LaotLaotLaot

loafloafloaf
LaofLaofLaof

hoathoathoat
HoatHoatHoat

hoadhoadhoad
HoadHoadHoad

lortlortlort
LrotLrotLrot

Những gì tôi phát hiện ra là bất cứ khi nào sự thay đổi bị trầm cảm, việc gõ chữ hoa "L" sẽ gây ra độ trễ đáng kể nếu ký tự tiếp theo là "o", so với độ trễ của bất kỳ phím nào khác:

High "o" lag:
LoLoLoLoLoLo

No "a" lag:
LaLaLaLaLaLa

No lag for neither "o" nor "a":
lolololololo
lalalalalala

Bằng cách nhận ra điều này, tôi đã lấy lại được một chút tỉnh táo vì tôi biết rằng tôi sẽ không gặp phải trường hợp Parkinsons. Tôi đã thực sự gõ chính xác, độ trễ chỉ giải thích sai.

Bây giờ, điều thực sự làm tôi bực mình là tôi không thể hiểu được chuyện này xảy ra như thế nào. Cái mà tôi thực sự gõ, theo thứ tự vật lý, là: L - o - a - d, tuy nhiên, "a" là đầu ra trước "o", mặc dù "o" đã được nhấn trước "a".

Vì vậy, trong khi bàn phím đang xử lý kết hợp "Lo", "a" được ưu tiên và được chèn trước khi "o" được xử lý xong, dẫn đến Laod thay vì Tải. Và điều này chỉ xảy ra khi gõ "Lo", không phải khi gõ chữ "lo".

Vấn đề này có thể xuất phát từ phần cứng bàn phím, phần cứng máy thu hoặc trình điều khiển phần mềm bàn phím. Tuy nhiên, bất kể vị trí lỗi, tôi không thể tưởng tượng làm thế nào điều này có thể được thực hiện như bất kỳ thứ gì ngoại trừ hàng đợi FIFO. Một sự chậm trễ chung, chắc chắn, tôi có thể sống với điều đó, mặc dù tôi bị kích thích. Nhưng độ trễ ảnh hưởng đến các khóa khác nhau khác nhau và thậm chí dẫn đến kết quả không thể đoán trước - điều đó không có ý nghĩa gì.

Tôi đã giải quyết vấn đề bằng cách chuyển sang bàn phím có dây. Tôi chỉ không thể rũ bỏ nó ra mặc dù; loại lỗi / lỗi / kịch bản nào sẽ dẫn đến một trường hợp như thế này?

Chỉnh sửa: Có ý kiến ​​cho rằng tôi nên ngừng uống Red Bull và thay vào đó là uống nước. Trong khi điều đó thực sự có thể giúp giải quyết vấn đề, tôi thực sự không tìm kiếm một giải pháp như vậy. Tôi quan tâm nhiều hơn đến một lời giải thích về cách điều này có thể xảy ra, vì tôi không thể tưởng tượng bất kỳ giải pháp kỹ thuật khả thi nào có thể dẫn đến hành vi này.

Câu trả lời:


1

Một cái gì đó xuất hiện trong tâm trí là đề cập đến các mã phím mà bàn phím không dây gửi và sự chậm trễ liên quan:

Mỗi phím được nhấn sẽ gửi cả mã XUỐNG và LÊN ...

  • Bạn nhấn SHIFT, nó sẽ gửi 'Shift-DOWN'
  • nhấn 'l', gửi 'l-DOWN'
  • phát hành 'l', gửi 'l-UP'
  • phát hành SHIFT, gửi 'SHIFT-UP'
  • nhấn 'o', gửi 'o-DOWN'
  • phát hành 'o', gửi 'o-UP'
  • nhấn 'a', gửi 'a-DOWN'
  • phát hành 'a', gửi 'a-UP'
  • ... và cứ thế

Nghe có vẻ như không dây Logitech có điều gì đó ảnh hưởng đến nó trong khi gửi các nét thay đổi (hoặc có thể là các nét của 'modifier' ... ctrl, shift, alt ..)

Tôi có bàn phím không dây Logitech (Model K270) và không nhận thấy bất cứ điều gì như thế này, mặc dù tôi biết từ kiểu gõ của mình, tôi đã gõ nhầm 'làm' như 'maek' và 'mkae' ... đó là tôi, tôi nhất quán trên mọi bàn phím và máy tính tôi viết mã trên ... vì vậy tôi đã thêm bí danh vào bash và vim để tôi không bị đánh (theo nghĩa bóng) trong đầu mỗi khi tôi làm điều này.

Đó có phải là một độ trễ có thể nhìn thấy hoặc cảm nhận được? Chỉ xảy ra dựa trên tốc độ gõ của bạn?

Tôi sẽ lên ý tưởng shotgun ở đây: những điều ngẫu nhiên tôi có thể nghĩ về điều đó có thể có liên quan ...

  • can thiệp không dây có thể cho bitpotype cụ thể được gửi? Bạn đã thử đồng bộ lại không dây với máy thu chưa?
  • can thiệp ma trận khóa có thể xảy ra do 'L' và 'O' thường nằm trên cùng một dòng 'cột'? (có thể là hàng ... nhưng bạn có ý tưởng)
  • Bạn có vi-rút 'Lào' cực kỳ hiếm và có thể gây tử vong. (Bạn chưa nghe về nó? Đã nói với bạn rằng nó rất hiếm ...)

Tôi sẽ thử đồng bộ lại bàn phím với máy thu, không, tôi cũng không biết, nhưng những thứ lạ đã hoạt động ít hơn. Không thể đau? Đúng?


0

Tôi thường viết bình luận này như một bình luận nhưng tôi không có đủ danh tiếng, vì vậy tôi sẽ làm cho nó hữu ích nhất có thể.

Tôi có một vấn đề rất giống nhau, ngoại trừ sự chậm trễ của tôi đến từ sự OMkết hợp.

Thỉnh thoảng tôi sẽ viết FROM(trong một truy vấn cơ sở dữ liệu) và SPACEBARđột quỵ của tôi sẽ xử lý trước và tôi sẽ kết thúc bằng FRO. Không hoàn toàn giống như vậy, vì tôi Mkhông bao giờ thực sự đi qua, nhưng rất giống nhau. Ngoài ra, nó chỉ làm điều đó khi tôi giữ SHIFT. Nếu tôi đang sử dụng CAPSLOCK, sự chậm trễ là không có. Ngoài ra, khi CAPSLOCKđược bật và tôi giữ SHIFT, sau đó viết thường omgây ra độ trễ tương tự. Vấn đề chắc chắn nằm ở SHIFT.

Tôi cũng có một bàn phím logitech, mặc dù đó là G110 và có dây;

Tôi vừa kiểm tra kịch bản cụ thể của bạn và tôi không có vấn đề gì với nó, vì vậy mỗi kiểu bàn phím (hoặc trình điều khiển tương ứng của nó), phải có sự không nhất quán riêng và vì lý do nào đó, không cập nhật đúng cách hàng đợi gõ phím. (Giả sử như bạn nói rằng đó là một hàng đợi, và tôi sẽ không hiểu tại sao không).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.