Здравствуйте!
Пишу приложение - должно работать а-ля банкомат  (фул-скрин, нет хоткеев, виртуальных консолей и т.д.)
Столкнулся со следующей проблемой. Если запускаю приложение без оконного менеджера (в xinit указываю скрипт, который запускает приложение и затем while : ; do: ; done), то не могу получить ввод пользователя с клавиатуры (мышка нормально работает).
В дебажном режиме можно переключаться в консоль (например tty1) - так вот в консоле ввод работает.
Если в скрипте запуска вместо бесконечного цикла запустить какой-нить мэнеджер, то всё работает нормально (из под мэнеджера).
Если остановить иксы и опять запустить в бесконечном цикле, то опять проблема с вводом.
И чего делаю ввывод что проблема в конфигурации иксов, которую выполняет оконный мэнеджер.
По этому поводу два вопроса:
1. Можно ли в программе реализовать необходимую настройку иксов (допустим функцией system() - не уверен что сработает после запуска иксов)?
2. Какие именно настройки иксов необходимы?

Запускал на трёх системах: Mandriva 2009.0 64-bit (работает всё), Mandriva 2009.01 Spring (не работает), openSUSE 11.1 32-bit (не работает)
Полагаю второй вопрос немного офф-топ. Заранее извиняюсь.

P.S. - отказ от оконного мэнеджера позволяет не беспокоиться о "горячих клавишах" (надо тока в xorg.conf и inittab пару опций прописать - остальное не обрабатывается), и бережёт от багов самих мэнеджеров (киваю в сторону кед).

Предположение - твой while : ; do: ; done грузит систему на 100%, так что до клавиатуры просто не доходит. Вставь в цикл sleep

1. Есть минималистичные оконные менеджеры (десятки строк кода). Я бы сам погуглил их за вас ради интереса, но я уже в пижаме.

2. Перехват клавиш в первую очередь происходит в иксах, а уже потом во всяких кде и прочее. Т.е. об этом можете не беспокоиться.

xvr, спасибо за ответ, но проблема видимо не в while true. Если запускать мою программу, с ключом -e -то она не делает форк и не отпускает консоль - в данном случае проблема с вводом с клавиатуры всё равно остаётся. К тому же если бы до клавиатуры дело не доходило из-за того, что система занята на 100%, то я бы не мог и мышкой работать, но мышка работает без каких либо проблем.

djamshud, спасибо, полдня ковырялся в исходниках - было очень познавательно .

Я тут на следующий факт наткнулся: моя программа состоит из двух модулей - первый - контролирующий демон (наследуется от QtService), второй Гуи-приложение (QMainWindow). Демон запускает гуи, и в случае какого-либо окончания гуишного процесса (закрыли, убили, упал и т.д.) запускает его заново. Если запускать сразу гуи (как тот же icewm) - то всё ок, но не вписываюсь в ТЗ. Думаю проблема может быть в том, что Демон каким-то образом получает "фокус" ввода, и до Гуи он уже не доходит. Дошло недавно  - ща уже в пижаме - завтра буду копать.

Кстати: проверял не трёх машинах (рабочий ноут и два декстопа) - так вот на ноуте под моим родный аккаунтом всё ок, на том же ноуте под другими аккаунтами не работает, на дектопах тоже не работает (там же нет моего аккаунта) - я думал, что дело в содержимом моей домашней папки, но до конца проверить не успел. кроме .xsession-erros в домашней папке на ноуте ничего нет, скрипт выглядит как xinit <programm> -e 
ключ -e для того, что бы контролирующий модуль не делал форк, иначе он запускается и иксы закрываются и он с ними.

"Дело было не в бабине..."
Очень извиняюсь, но проблема была не там, где я думал - прошу модераторов не зверствовать - я не специально.
Прогу пишу c использованием библиотеки Qt. Проблема связана с багом библиотеки, который связан с элементом QLineEdit - проявил себя только без оконного мэнеджера (оконный мэнеджер перекрывал этот баг и его заметно не было), да и то, только с окошком, создающимся динамически, с теми окнами, которые созданы при старте и просто спрятаны баг себя не проявляет. В двух словах - если в динамическом окошке есть лайн-эдит ( хотя бы один) то он перехватывает фокус и куда-то его теряет !!!. Фиксится назначением для виджета содержащего лайн-эдит этот лайн-эдит (в случае если их несколько, то первый создаваемый) как фокус-прокси setFocusProxy(my_lineedit_ptr); и направлением фокуса на данный лайнэдит my_lineedit_ptr->setFocus();
Имхо шаманство, но работает именно так - проверил в трёх местах в своей проге.
Баг пофиксили в версии 4.6, судя по багтреку обнаружили в версии 4.5.2, а у меня как раз Qt версии 4.5.2.
Полагаю что все описанные выше финты программы на разных машинах (где-то работает, где-то нет) можно списать на баг, то теряет фокус - то нет, при достаточно большом кол-ве попыток прога всё-таки стала валиться в любом виде на любой машине (без оконного мэнэджера)

Вообщем ещё раз извиняюсь - не со зла...

Да, ещё выяснилось следующее запуск проги в иксах - достаточно
xinit <prog>
но иксы закроются, как только прога вернёт управление (закроете окошко)
тип проги не важен - это может быть и консольное приложение (как у меня консольный демон, запускающий гуи) и непосредственно гуи приложение.
без оконного мэнэджера горячии клавиши (за исключением Ctrl+Alt+F<x> и Ctrl+Alt+Backspace - которые можно отключать в xorg.conf) ни кем не обрабатываются, если конечно запущенная вами прога сама их не обрабатывает

Прошу прощенья если не совсем вник в суть вопроса...

У меня когда-то была похожая проблема - не мог ввести текст в поля ввода Qt-шного приложения даже если мышкой туда щелкаешь без запущенного оконного менеджера (именно как у вас вроде).

Нашел в Qt documentation текстовку что надо самим после show() вызывать метод setActiveWindow().

Надеюсь поможет кому-нибудь... (пост староват как-то    )