Board.KolibriOS.org

SVN r.4588 функция 2 (получить код нажатой клавиши) доработана, теперь кроме ASCII еще одновременно возвращается и SCANCODE. Эта доработка необходима для реализации поддержки Ctrl+C|V в Editbox, поскольку в режиме ASCII ранее было проблематично однозначно определить нажатие нужных комбинаций клавиш, из-за меняющегося от языковой раскладки кода. Изменение API описано в файлах sysfuncr.txt и sysfuncs.txt. Также возможно возникновение глюков, в программах написанных без учета подробностей документации ф.2, так что просьба быть внимательными и сообщать на форуме о возникновении проблем в работе с клавиатурой после этой ревизии.

Стоит ли убрать из сборок приложение scancode?

CleverMouse wrote:Стоит ли убрать из сборок приложение scancode?

Нет. KEYASCII показывает только нажатие и не для всех клавиш.

У меня есть мысль переписать все в одно приложений, но пока внедрение поддержки буфера обмена в Editbox имеет больший приоритет.

А ещё сканкод break например не поместится в 16 бит.

Как то всё сильно совпало... Эта программа не на что не претендует, написана в учебных целях для статьи.

eAndrew wrote:Как то всё сильно совпало... Эта программа не на что не претендует, написана в учебных целях для статьи.

Красиво, удобно, может заменить KEYASCII, но не заменит SCANCODE по тем же причинам. Вот если бы сделал вторую вкладку (пока можно хоть кнопками) и добавил еще и в режиме сканкодов, объединив функционал обоих программ, то было бы очень хорошо.

Начиная с ревизии 4599 появилась проблема в обработке клавиш в KFAR. Проблема наблюдается как в реальной машине, так и в Qemu.
Воспроизведение: При загрузке выбираем режим 640*480, запускаем KFAR и по Alt+F2 меняем отображаемый диск, при этом курсор должен находиться в левой панели. Перестают работать стрелки и таб. При этом Alt+F1|F2 продолжает функционировать. Если выбрать другой отображаемый диск, то клавиши разблокируются или можно развернуть окно приложения на весь экран (двойной клик по заголовку).

З.Ы. У данной ревизии, как и у предыдущей невнятное описание в логе SVN ("2" и "r4599" соответственно). Может быть имеет смысл добавить пару слов к описанию?

Во-первых, УМВР, во-вторых, r4599 заведомо ни при чём, это сугубо внутренняя оптимизация ядра, не видимая с прикладного уровня. Поэтому и сообщение такое - как показывает практика, всё равно сообщений никто не понимает, а так его нельзя понять неправильно. По существу проблемы - возможно, Alt "западает"?

CleverMouse wrote:По существу проблемы - возможно, Alt "западает"?

"Симптоматика" описанная выше похожа на ту что я указывал в теме "тестируем поддержку USB", но ответа на сообщение не было

P.S. И похоже это начало проявлятся не только у меня.

CleverMouse wrote:Во-первых, УМВР, во-вторых, r4599 заведомо ни при чём, это сугубо внутренняя оптимизация ядра, не видимая с прикладного уровня. Поэтому и сообщение такое - как показывает практика, всё равно сообщений никто не понимает, а так его нельзя понять неправильно. По существу проблемы - возможно, Alt "западает"?

Вечером видео запишу - продолжу славную традицию Кирилла.
З.Ы. Вообще в живую проверял на U800 нетбуке, а Qemu запускался на работе на ноутбуке ASUS, так что западание Alt несколько не вписывается в концепцию.

CleverMouse wrote:Во-первых, УМВР, во-вторых, r4599 заведомо ни при чём, это сугубо внутренняя оптимизация ядра, не видимая с прикладного уровня. Поэтому и сообщение такое - как показывает практика, всё равно сообщений никто не понимает, а так его нельзя понять неправильно. По существу проблемы - возможно, Alt "западает"?

Я приношу извинения - был не прав и поторопился с выводами.

Чтобы уменьшить влияние ревизии 4588, я сделал дополнительную логику в SVN r.4612. Теперь сканкод в старших битах возвращается только в ASCII режиме. В режиме сканкодов работает прежняя логика, бывшая до ревизии 4588. Проблемы с обработкой клавиш в KFAR более не наблюдается.

В последней сборке "отловил" глухое зависание системы на реальном железе при попытке закрыть FAR мышкой.
C чем связано не знаю и будет ли повторятся далее.

P.S. Какие варианты фиксации произошедшего могут быть задействованы в Kolibri в данной ситуации?

Kopa wrote:Какие варианты фиксации произошедшего могут быть задействованы в Kolibri в данной ситуации?

Сначала надо определить проблемную ревизию, условия повторения и не является ли это аппаратной проблемой (ну, там коннектор у памяти окислился или еще чего).

Mario_r4 wrote:

Kopa wrote:Какие варианты фиксации произошедшего могут быть задействованы в Kolibri в данной ситуации?

Сначала надо определить проблемную ревизию, условия повторения и не является ли это аппаратной проблемой (ну, там коннектор у памяти окислился или еще чего).

ХЗ. Может что и окислилось, но так явно встретил только в описанном случае.

P.S. Используя Web браузер Haiku OS замечаю разной степенью глюки в процедурах регистрации и захода на какие то ресурсы i-neta. Браузер (система) выдаёт сообщение о завершении и возможности записать баг репорт. Есть ли какая то корреляция и с вышеописанным случаем или это "внутренняя нестабильность" данной ОС тоже непонятно.
Можно было бы публиковать и эти репорты данной ОС в форуме проекта Kolibri OS если был бы какой то смысл в этом.
Новые сборки Haiku OS тоже периодически обновляю, но те или иные глюки в ней всплывают с "постоянной периодичностью".
Использую в основном из-за браузера т.к. поддержана сетевая карта, видекарта и разных SVN, CVS, GIT клиентов для обновления интересных мне репозитариев программных проектов.
Пробовал упаковывать/распаковывать репозитарий Kolibri проекта. в ней. Так вот архивирование по времени ещё терпимо, а разархивация лучше сразу "убиться" или уйти "гулять" как по времени так и по загрузке процессора (хотя вроде интенсивно используется для этого ОЗУ -1Гб)

SVN r.4631 viewtopic.php?f=44&t=1598&start=44 программа KFM более не использует ф.18.11, если нет других программ использующих эту функцию, то можно удалить ее из API. В ядре еще требуется проделать некоторый немалый объем работы, чтобы убрать зависимость от старой модели формирования списка устройств (например, допилить весь код работы с ATAPI).