Кстати, и командочку переврал:
bash$ echo -n $'AT\rATI9\r' > /dev/ttyS0
Окончание истории не достигнуто, поэтому Chip не пишу. Но новые (глупые)
вопросы мышь поставила.
Попробую выполнить read() на /dev/ttyS0. Так как X сервер открывает этот
файл, перезагружаюсь в rc3 режиме. Итак:
bash$ cat /dev/ttyS0 | hexdump -C
Теперь медленно двигаю мышь вправо
87 00 00 87 00 00 87 00 00...
или вниз
87 ff 00 87 ff 00 87 ff 00...
Но это уж слишком! Я ожидал 5, ну 4, байта в пакете, но не 3 же.
Переключим на Microsoft:
c0 81 80 c0 81 80 c0 81 89...
или
c0 80 81 c0 80 81...
И, естественно, если в /etc/sysconfig/mouse прописать правильный протокол,
то всё будет хокей, но без третьей кнопки.
Вопрос однако.
Вопрос: пакеты MouseSystems по 5 байт. Куда 2 дел?
И вообще не пойму, что вернул read().
Но с помощью этой технологии можно хотябы понять, отвечает мышь, или нет.
Итак, на tty0 выполняю
bash$ cat /dev/ttyS0 > mouse.b
На tty1
bash$ echo -n $'AT\rATI9\r' > /dev/ttyS0
Курсор дёргается.
bash$ hexdump -C mouse.b
30 c7 00 01 fc
Если повторять несколько раз, числа будут не всегда одни и те же.
Например можно увидеть
30 c7 01 fc
или
30 e0 c0 01 fc
Или даже
e0 00 79 87 30 01
И когда числа другие, то курсор дёргается иначе.
Вообще, если послать ей один байт
bash$ echo -n $'.' > /dev/ttyS0
то она не ответит, а если
bash$ echo -n $'b' > /dev/ttyS0
то ответит единственным
ff
Замечу, что только -n $'AT\rATI9\r' гарантированно даёт желаемое
оздоровление.
Если выдернуть кабель, то никакого ответа.
Глюк, наверно, не в мыше, а в драйвере, или ещё выше. Это издевательство
над бедным животным было бы не интересно, если пресловутая команда не
была бы достаточно простым (и единственным мне известным) способом её
реанимации.
Думаю, факт, что мышь отвечает (но не стабильно) можно считать
установленным. Но мне не понятно, полную ли чушь она пищит, или это
что-то осмысленное (содержание 9-го регистра 4-го позвонка её хвоста,
например).
Намекните, хотябы, почему read() вернул три байта, а не 5?