Странное поведение РS/2 контроллера

Тема в разделе "WASM.OS.DEVEL", создана пользователем gektor, 12 сен 2009.

  1. gektor

    gektor New Member

    Публикаций:
    0
    Регистрация:
    12 авг 2009
    Сообщения:
    23
    Готовность порта проверяю так:
    Код (Text):
    1. BOOLEAN wait_kbd()
    2. {      
    3.     BOOLEAN is_wait_ok = FALSE;  
    4.     for (ULONG i = 0; i < 10000; i ++)
    5.     {      
    6.         UCHAR chr = READ_PORT_UCHAR(0x64);
    7.         if ((chr & 0x02) == 0)  
    8.         {
    9.             is_wait_ok = TRUE;
    10.             break;
    11.         }      
    12.                 KeStallExecutionProcessor(1000);
    13.     }          
    14.     return is_wait_ok;
    15. }
     
  2. cppasm

    cppasm New Member

    Публикаций:
    0
    Регистрация:
    18 июл 2006
    Сообщения:
    923
    А данные как выводишь?
     
  3. gektor

    gektor New Member

    Публикаций:
    0
    Регистрация:
    12 авг 2009
    Сообщения:
    23
    1. ждем готовности порта
    2. пишем в порт 64 команду 0xD2, означающую, что сейчас будем передавать данные в контроллер.
    3. еще раз ждем готовности порта
    4. пишем байт данных в порт 60

    Кстати все операции ожидания успешны.
     
  4. cppasm

    cppasm New Member

    Публикаций:
    0
    Регистрация:
    18 июл 2006
    Сообщения:
    923
    Вроди всё правильно, я на счёт 0xD2 как раз и имел ввиду.
    А Ack от контроллера получаешь?
    Как вариант можно ещё попробовать 0xFE - Resend.
     
  5. o14189

    o14189 New Member

    Публикаций:
    0
    Регистрация:
    19 июл 2009
    Сообщения:
    320
    ясно все )
     
  6. Wizard109

    Wizard109 New Member

    Публикаций:
    0
    Регистрация:
    6 ноя 2006
    Сообщения:
    346
    Хм... цикл был бы проще с while(!is_wait_ok) :)
    А с возвратом данных... кода бы побольше.
     
  7. Wizard109

    Wizard109 New Member

    Публикаций:
    0
    Регистрация:
    6 ноя 2006
    Сообщения:
    346
    З.Ы. Посмотрел щас. У меня в подобной тулзе задержка 2500 мс
    З.З.Ы. http://konstantinv.boom.ru/appar/3.htm. Мож поможет :)
     
  8. ams007

    ams007 New Member

    Публикаций:
    0
    Регистрация:
    28 апр 2007
    Сообщения:
    86
    а на тех машинах случайно не используются kvm свитчи? у очень многих из них неадекватная реакция наблюдается.
     
  9. gektor

    gektor New Member

    Публикаций:
    0
    Регистрация:
    12 авг 2009
    Сообщения:
    23
    100% нет. Большонство (но не все) из "пробелмых" компьютеров - ноутбуки со всроенной клавиатурой.
     
  10. o14189

    o14189 New Member

    Публикаций:
    0
    Регистрация:
    19 июл 2009
    Сообщения:
    320
    Дело в задержках скорее всего
     
  11. valterg

    valterg Active Member

    Публикаций:
    0
    Регистрация:
    19 авг 2004
    Сообщения:
    2.105
    http://ilocals.ru/page/10/
    А вот возможно в чем корень зла. Кроме готовности нужно убедится, что буфер пуст :

     
  12. o14189

    o14189 New Member

    Публикаций:
    0
    Регистрация:
    19 июл 2009
    Сообщения:
    320
    valterg
    без того что ты указал софт бы вообще не работал, дело в задержках скорее всего, но т к ТС не приводит ни кода, ни хотя бы бинаря драйвера, говорить о чем-то нет смысла - обычные гадания
     
  13. ams007

    ams007 New Member

    Публикаций:
    0
    Регистрация:
    28 апр 2007
    Сообщения:
    86
    ACPI коды проблемных клавиатур стандартные? Столкнулся на 2х машинах - с кривыми кодами на одной и с их отсутствием на другой(О_о) - когда пишешь в буфер обратно данные - то что ты только что записал - потом вычитывается, а далее буфер пуст, хотя там до записи 100% были данные.
     
  14. ams007

    ams007 New Member

    Публикаций:
    0
    Регистрация:
    28 апр 2007
    Сообщения:
    86
    ACPI\PNP030X, где Х- 16я цифра. это честные коды.
     
  15. gektor

    gektor New Member

    Публикаций:
    0
    Регистрация:
    12 авг 2009
    Сообщения:
    23
    В смысле? Как определить стндартные они или нет? Я оперирую с ACPI только для того, чтоб маскировать прерывания.