Комментарии 59
P.S. на клавиатуре 13" MacbookAir mid 2013 не отлавливаются проверкой одновременные нажатия трех клавиш, расположенных не на одной линии. То есть например ASD срабатывает, а WSD уже нет.
Я один не понимаю, как такое может произойти? Вертикальные-то линии разные, так что никаких проблем с распознаванием быть не должно. Ежели бы такая проблема была, то клавиатура бы вообще не могла отличить S от G, а заодно бы не смогли работать мониторы, тачскрины и цифровые фотоаппараты. Ибо во всех в них принцип аналогичен. Что-то мне подсказывает, что здесь какая-то маркетинговая собака порылась.
Вот, даже статья на эту тему есть: http://easyelectronics.ru/matrichnaya-klaviatura.html
С S и G проблем не будет. А вот если зажать W + S + D (по схеме из статьи), то получиться 4 пересечения (WSDE). Сколько на самом деле нажато кнопок (3 или 4), и каких именно — не определить. Просто W + D не приведут к такой ситуации, хотя тоже будет 4 пересечиня из-за того как происходит процедура сканирования (по колонкам, они открываются последовательно и смотрится состояние строк), то есть открывается строка с W, и на ней активно только W, затем закрывается и открывается строка с D, где тоже только одна клавиша активна. Но если и на строке, и на столбце по 2 активных клавиши, то разрешить это не получится.

Посмотрите на картинку. Если зажать одновременно S и R, то пересекутся ещё два лайна в буквах W и F. Они автоматически в дешёвых клавиатурах будут заблокированы, т.к. определить их нажатие / отпускание будет затруднительно.
В случае же с S и G блокируются сразу два лайна, и нажатия в двух других рядах приведут к ещё 4 «замыканиям», которые автоматом будут отсяеяны. Возможно, я неточно выразился в статье, сейчас поправлю описание.
Да и вообще не понимаю проблемы разводки 100+ линий под клавиши и организации многоканального мультиплексора(многоразрядный регистр сдвига будет проще схемотехнически) в виде 128-ногого чипа. Это добавит порядка 1..2$ в стоимость клавиатуры и решит все проблемы.
Но нет же, экономим на деталях чтобы потом героически 20 лет преодолевать проблему нажатия нескольких клавиш…
Как-то это невольно напоминает зависимость ширины ракетного ускорителя шаттла от размера конской задницы.
Хотя как по мне, то не стоит это называть «костылем». Это вынужденная необходимость при таком интерфейсе для полной хардварной поддержке стандартными драйверами без использования софтовых «костылей».
Кстати, вполне реально делать композитное устройство на клавиатуре (несколько HID так и сделано), представлять HID устройство (для совместимости) и своё, вендор-устройство, поддерживаемое своим драйвером — при инициализации, работа HID останавливается ну и дальше — работает свой драйвер. Минусы такого решения: более дорогая разработка и поддержка, нужно обеспечивать драйвер на разные системы (ну если разработчик руковдствует правилом: клава игровая, игры только под Windows, то драйвер нужен только для Windows :)).
Пример… правда не с клавиатурами, а с UVC и non-UVC (свой драйвер, и да, не рекламы ради): эпифановские грабберы DVI2USB3 и AVio HDMI — первый — свой драйвер для захвата видео, второй — UVC + UAC. Разница для конечного пользователя только в том, что для второго не нужно ставить драйвера. А по итогу доступ всё равно через подсистему DirectShow или Video4Linux2. С клавиатурами, думается, тоже самое: на винде не знаю какая подсистема, на линухе просто представиться evdev.
Если следовать наиболее строгой спецификации USB HID v1.11, которая поддеживает режим USB Boot (и позволяет использовать USB-клавиатуру для входа в BIOS и работы в нём), то клавиатура будет отправлять пррывания на CPU каждый раз, как USB-хост будет опрашивать её, вне зависимости от того, изменилось её состояние или нет.Суть текста в том, что в usb только хост может инициировать передачу данных. По этому CPU приходится постоянно просить USB прочитать данные с клавиатуры.
Один из байтов зарезервирован, так что на работу клавиатуры остаётся 7 байт, т.е. количество достаточное, чтобы закодировать нажатие любой клавиши-модификатора и ещё шести других.Тут совершенно ничего не ясно. Ведь PS/2 также посылает байты с кодами, суть последовательный порт. Проблема протокола HID в том, что он шлёт пакеты состояний 6 клавиш вместо сообщений о нажатии, как в PS/2.
Проще понять на примере:
- нажали навишу «a», пришёл пакет: 00 39 00 00 00 00 00
- отпустили «a», пришёл пакет: 00 00 00 00 00 00 00
- нажали «a» и «b», пришёл пакет: 00 39 40 00 00 00 00
- отпустили «a», «b» держим, пришёл пакет: 00 00 40 00 00 00 00
То-есть позиция сохраняется. По этому при нажатии седьмой клавиши, не модификатора, для неё не будет места и сучится неизвестное состояние. Для него кстати есть специальный пакет.
Отдельный вопрос нафига так? Возможно из-за желания сэкономить циклы процессора на опрос.
то клавиатура будет отправлять пррывания на CPU каждый раз, как USB-хост будет опрашивать её
скорее всего речь шла об interrupt end-point :) что не совсем то, что отправить прерывание на хост. А так да, в USB только хост может инициировать передачу данных. Устройство — нет. Соответственно, что бы быстро опрашивать, нужно быстро поллить, а это циклы CPU. Подробности не читал, но какие-то подвижки есть в USB 3.0, хотя, может, что-то путаю.
скорее всего речь шла об interrupt end-pointНе понял что это. Это дёрганье контроллера клавиатуры? Ну и пусть дёргает, он ведь больше ничем не занимается :)
Даже на дешевых клавиатурах клавиши-модификаторы работают независимо от остальной матрицы и большая часть комбинаций с модификаторами проходит безболезненно, НО играть на таких клавиатурах становится невозможно — банально нажатие кнопок «вперёд» и «влево» могут уже привести к проблеме(где-то я уже слышал о такой проблеме очень давно: кому-то в офис закупили партию таких клавиатур и таким образом частично решили проблему игр на рабочем месте).
Допустим у нас 5-и кнопочная клавитатура:
00001 — 5-я клавиша
01001 — 2-я + 5я
ну и т. д.
7-байт = 56бит. Т.е. можно передать состояние 56 клавиш.
Почему в 7 байтов помещается только 6 + клавиша модификатор?
Понятно, что 56 клавиш маловато, но это и не 6 штук.
А что мешает сжимать данные?
Пусть клавиш 128 штук (с запасом, больше 115 не видел), соответственно 128 бит. У нас ограничение 8 байт, а нужно отдать 16
но одновременно на клавиатуре осознанно можно нажать10 клавиш. Даже пускай 20.
Соответственно в цепочке 128 нулей будет всего 10-20 единиц. Неужели в таком случае коэффициент сжатия будет менее 50%?
И еще по поводу клавиатурной матрицы:
Что мешает на клавиши добавить резисторы?
Например 11 клавиш в строке, резисторы соответственно 1,2,4,8,16,32,64,128,256,512,1024 кОм.
Столбцов тоже 11, но там резисторы уже не нужны.
Получаем 11 каналов строк на которых можем вычислить любые комбинации.
На таком принципе Covox для LPT работал… Простейший АЦП.
Сделать можно очень многое, но очень немногое проходит фильтры на технологичность и дешевизну.
Можно сделать хенд-мейд клавиатуру с собственным драйвером которая бы была способна держать одновременное нажатие хоть 200 клавиш… и тут ты задумываешься о смысле бытия, смотришь на затраты денежные и временные и офигеваешь во сколько встал этот фетиш… Зато теперь можно нажать все 200 клавиш одновременно.
Возможно, я не владею данными знаниями, но что за грабли каждый раз?
То больше 640кБ оперативки без HIMEM не задействуешь, то с объемом хардов больше 128мб свистопляска была,
теперь IP-V4 закончился, что за недальновидность?
Что нужно калибровать при допуске +/1 0,5 кОм? Это сопротивление не одной сотни метров провода!
Хорошо, предлагаю другую дешевую аппаратную реализацию:
1. Под клавишами проходит оптоволокно.
2. Нажатие на клавишу сгибает волокно.
3. Рефлектометр замеряет длину до каждой деформации.
Все вышеперечисленное возможно и с коаксиальным кабелем.
Все затраты — 2-3 метра волокна, корпус и подвижные клавиши.
Рефлектометр конечно штука не дешевая, но нам и не нужно стрелять на километры.
2-3 метра вполне достаточно. При массовом производстве будет дешевле. Можно реализовать на материнке.
Значит реализовать 1 клавиатуру как 6 HID устройств не проблема, а тут проблема?
для системы хоть 6 хид — ей пофиг, она обработает их как разные устройства. И реализовать не проблема, а вот стандартизовать, внедрить, устаканить баги и пр — это то ещё приключение. Китайцы вон придумали кастом, да и я проблем не вижу — взять любую клаву, зареверсить разводку, выкинуть контроллер и написать что-то своё в виде композитного устройства: HID + кастом. И будет счастие.
Возможно, я не владею данными знаниями, но что за грабли каждый раз?
То больше 640кБ оперативки без HIMEM не задействуешь, то с объемом хардов больше 128мб свистопляска была,
теперь IP-V4 закончился, что за недальновидность?
в определённый момент развития технологии существуют объективные причины сделать что-то так или иначе. Либо неизвестно как, и тогда принимается что-то с воздуха. Помимо этого, не всегда удаётся всё предусмотреть (привет разработка софта и изменчивые требования!): что-то решается без проблем, что-то малой кровью, что-то не сильно тривиально и прямо.
Хорошо, предлагаю другую дешевую аппаратную реализацию:
Предлагаю начать вам компанию на кикстартере, потом пропихнуть это как стандарт (пусть не в замену, но, хотя бы, в дополнение). Плюс, вы уже увидили как у вас не всё гладко с первым вариантов вышло. Думаете тут тоже всё продумано? А волокно одно? А если нажаты две клавиши, будет замеряно только до первой нажатой?
Подобный принцип применяется в периметровых системах охраны на коакссиальных кабелях (требоэлектрические).
Нет, пожалуй регистры это сильно дешевле, технологичней и стабильней.
Да и проблеме не в том как реализовать, а в том как сделать это стандартно.
Вот представьте себе зафигачили такую клавиатуру, пробили под неё стандарт… втыкаете в компьютер а он вам «нужен драйвер, до свидания».
Втыкаете в специфическую железку 2000-го года, а она вам болт… кто под неё будет писать реализацию нового стандарта? Да даже в современном железе поддержка нового стандарта будет не сразу, а только лет через 5 пока пройдут все круги ада. В итоге, клёвая клавиатура будет пылится в углу магазинов как геймерская с ограниченной поддержкой железа… типа виндовс-онли(ну ладно запилят на линукс года через два, и то если пойдет в массы).
Сила стандартов порой очень велика, и продвинуть новый стандарт в замен старого ой как непросто, когда тот укоренился в железе.
Я вот даже сейчас встречаю компы которые не имеют поддержки USB-клавиатур в БИОС-е.
А что мешает сжимать данные?
Ничто не мешает. Только спека HID. Ещё (!!!) встречаются мамки в работе, в которых не работает USB-клава в BIOS. Т.е. если сделать что-то новое, то оно ещё должно стандартизироваться и устаканиться. Мы делаем USB 3.0 UVC устройство, столько уже всякого непрятного наелись.
Что мешает на клавиши добавить резисторы?
цент на 1 резистор выльется уже в 1 доллар (примерно) на клаву, а теперь прикиньте массое производство. Удешевлять патаются на всём, что только можно. Плюс более сложная логика (читать: больше багов) в обработке. За примером далеко ходить не нужно: купил механику, а там, при выключенной подстветке определённый набор клавиш перестаёт работать. Причём воспроизводится не на всех контроллерах и не всегда на одном и том же. Благо в магазине согласились без вопросов обменять.
Дорожки из резистивного материала. Все равно на пленку какой то состав наносят, причем вероятнее
практически типографским способом. Пусть он будет резистивным.
Конечно неудобно, что сопротивление нам нужны разные, но что мешает делать 1, 2, 4 и т. д. параллельных дорожек для
разных сопротивлений. По моему станку наплевать, что печатать. Одну широкую или 1-11 тонких.
Да и вообще, внутри клавы проблем нет, почти все уже решены — на PS/2 проблемы NKRO не существует :) Проблема именно в контроллер клавиатуры — хост. HID не позволяет сделать NKRO. HID стандарт, вы можете просто продумать и пропихнуть свой стандарт — и будет счастье геймерам.
А что мешает сжимать данные?
Пусть клавиш 128 штук (с запасом, больше 115 не видел), соответственно 128 бит. У нас ограничение 8 байт, а нужно отдать 16
но одновременно на клавиатуре осознанно можно нажать10 клавиш. Даже пускай 20.
Соответственно в цепочке 128 нулей будет всего 10-20 единиц. Неужели в таком случае коэффициент сжатия будет менее 50%?
Все проще. Надо было не выдумывать, и остаться на старом протоколе: отдельно события нажатия на клавишу, отдельно события отпускания клавиши. Хватило бы как раз на 128 клавиш.
В очередной раз убеждаюсь, что жестянщиков, программеров и «эффективных» менеджеров
к написанию ТЗ и разработке пользовательских интерфейсов нельзя подпускать на пушечный выстрел.
Джобс что? Применил инопланетные технологии? Ничего необычного в iPhone 1-м не было, просто сделал доступно для
не компьютерных людей. Все просто, понятно, без замороченных меню и без видимой файловой системы, чего чайникам и не нужно.
Меня например всегда убивает в андроиде обилие непонятно кем когда и зачем созданных папок на карте памяти,
при том, что и без карты аппарат вполне работает обходясь внутренней. Тогда зачем так засирать карточку!
И вообще, зачем мне как обычному пользователю видеть папки типа DEV, ETC, MNT и пр.?
Для метя телефон/планшет/компьютер — это инструмент а не предмет для ковыряния. Мне наплевать из чего
и по какой технологии сделан замок в моих дверях. Я им просто пользуюсь и меня все устраивает.
А если из него будут торчать наружу всякие элементы механизма, он меня не устроит.
>А кого? Особенно как осадить аппетиты которые невозможно реализовать, но станет возможно лет через 5-10-25-100?
О каких аппетитах речь? В конце 20 века невозможно было передать лишний десяток байт?
П. С. Айфонами не пользуюсь принципиально. Мне нужно все и сразу, и пока альтернативы нет.
Лучше на костылях, но на свободе, чем на Феррари, но по тоннелю из которого не свернуть.
Джобс что? Применил инопланетные технологии? Ничего необычного в iPhone 1-м не было, просто сделал доступно для
не компьютерных людей. Все просто, понятно, без замороченных меню и без видимой файловой системы, чего чайникам и не нужно.
ок. для некомпьютерных людей проблемы NKRO нет вообще :) это раз. Два, для нуждающихся — есть «изящный хак» с несколькими HID устройствами. Думаешь iPhone, в угоду «некомпьютерным людям» всё сделано плавильно и без костылей. Ну-ну. Спроси разработчиков под него. Но, что с клавами, что с айфонами — выхлоп один: оно тупо работает.
О каких аппетитах речь? В конце 20 века невозможно было передать лишний десяток байт?
Когда проектировался HID был только USB 1.0 и мода LowSpeed, для interrupt endpoint в таком режиме возможна передача только 8 бит, дальше могут ехать тайминги и т.п. плюс большая нагрузка на CPU. Любая технология — набор компромиссов. Я разработчик USB устройств, меня тоже иногда шокирует от принятых решений комитетом, но при детальных разборах оказывается, что, по большей части, они оказываются или оказывались технически обоснованными.
П. С. Айфонами не пользуюсь принципиально. Мне нужно все и сразу, и пока альтернативы нет.
Лучше на костылях, но на свободе, чем на Феррари, но по тоннелю из которого не свернуть.
Ну так… не можете изменить ситуацию — измените отношение к ней. Любая экспрессия на форумах никогда и ни за что не сдвинет что-то в нужном вам направлении. Можете сделать свою сборку на базе андроида, где всё, как нужно вам :) Китайцы вон вообще штампуют «смартфоны» с непонятно чем внутри, но что выглядит как андроид. Они просто делают.
Прошу прощения за некропост :) Но в рамках моей основной работы мне потребовалось… Реализовать HID клавиатуру и мышку (плюс тачпад, но это для обхода уже других косяков).
И теперь я могу утверждать:
Проблемы NKRO на USB: во всём виноват USB HID
не совсем правда.
Вы правильно рассказали про HID Boot Protocol. В этом режиме хост не считывает HID дескриптов и делает предположение, что используется стандартный формат посылки — чисто для упрощения кода и что бы не писать парсер для HID дескриптора (а полный — очень сложный). Отсюда и лимиты на 6 клавиш.
Стандартный (а не специальный!) драйвер HID в OS уже работает по дефолтному протоколу HID Report Protocol, который предусматривает то, что драйвер считывает HID дескриптор и разбирает его. Так вот, сделать там можно любое количество клавиш. А 1024 (1023 точнее + модификаторы) могут влезть даже в одну посылку в режиме High Speed / Super Speed или до 63(+1) в режиме Full Speed. Хотя завязки на размер посылки-то и нет. Но как правило хорошего тона — вполне.
Судя по всему беда как раз в самой популярной и дружественной ОС: Windows. Даже могу предположить, что в XP, когда, в основном и пошёл бум USB клавиатур. Судя по всему она не обрабатывает посылки больше 8 байт и, по сути, работает в Boot протоколе. Проверить сейчас не могу — нет такой оси.
Косвенно подтверждается это тем, что буквально на днях "изобрёл" очередной BadUSB, который валит последние версии Windows (8, 8.1 и 10) в BSOD: https://htrd.su/wiki/zhurnal/2017/04/24/ideja_dlja_badusb.
Создаётся впечатление, что в драйверах используются фиксированные буфера или что-то захардкожено.
ЗЫ Если на проекте останется время, попытаюсь сделать дескприптор клавиатуры, который сможет послать 63 клавиши одновременно и проверю на Win8/10/Linux.
NKRO на USB. Проблемы и костыли при их решениях