Xlib, как правильно послать клик мышкой в окно

Я не понимаю ничего. Я комментировал проблему, при которой частично закрытые окна не получают события по нажатию мышки. Это событие «глотает» приложение, которое находится поверх. Можешь проверить это, наложив два одинаковых окна приложения (два раза запустить одно приложение) друг на друга и посылая клик нижнему. Несмотря на указанный window id нижнего, событие получит верхнее окно, которое тебя не интересует. Это легко проверяется xdotool-ом.

Это всё я понял и прочувствовал втч и с помощью xdotool'а, вопрос про system-wide мониторинг нажатых клавиш клавиатуры, и граббинг мыши(тача) для окна.

вопрос про system-wide мониторинг нажатых клавиш клавиатуры

X Record Extension.

ftp://www.x.org/pub/xorg/current/doc/libXtst/recordlib.html

ftp://www.x.org/pub/xorg/current/doc/libXtst/recordlib.html

Ставишь GNU Xnee. Дальше набираем:

$ cnee --record --mouse --keyboard -o /tmp/test

Возюкаем мышкой, клацаем. Прерываем.

$ cnee --replay -f /tmp/test

Смотрим кино. :)

Xnee использует Record Extension.

вопрос про system-wide мониторинг нажатых клавиш клавиатуры, и граббинг мыши(тача) для окна.

Вот, кстати, конкретно мониторинг нажатых клавиш клавиатуры можно попробовать сделать, вызвав XSelectInput на окно root. По идее должно работать.

Надо попробовать, я так понял что XSelectInput только для окна с фокусом работает.

Ну как и было сказано в документации, только когда рут под фокусом, на другие окна не распространяется. Только если пройти по дереву и на каждое окно повесить XSelectInput, видимо на этом придётся остановится, так как это проще и прозрачнее чем создавать callback для X Record Extension и писать все события в очередь, потом эту очередь проверять на наличие сочетаний...

Надо попробовать, я так понял что XSelectInput только для окна с фокусом работает.

А как, по-твоему, оконный менеджер перехватывает свои комбинации? Он первым получает все события клавиатуры, а потом уже приложения. Вот прямо сейчас я назначил кнопку «a» на оконный менеджер. Результат: активное приложение больше букву «a» не получает вообще. Оконный менеджер первый ее забрал.

А как ты пытался букву «а» получить? Через XGrabKey или XSelectInput?

пройти по дереву и на каждое окно повесить XSelectInput

И появление новых окон отслеживать, которых не было до XQueryTree

Еще можешь попробовать

$ xinput --test <id клавиатуры, увидеть можно по xinput --list>

Оно и мышку покажет, если укажешь ее id

Интересно, а как новые окна отслеживать? Есть событие?

CreateNotify называется, да... :)

На root window повесить при помощи XSelectInput либо MapNotify/UnmapNotify, либо CreateNotify/DestroyNotify, чтобы апдейтить дерево. Но вообще идея с деревом - это какое-то чесание левого уха правой рукой.

UPD. что-то типа такого

    dpy = XOpenDisplay(NULL);
    root = DefaultRootWindow(dpy);
    XSelectInput(dpy, root, SubstructureNotifyMask);

    while (1) {
        XNextEvent(dpy, &event);

        /* Слушаем сообщения */
    }

Но вообще идея с деревом - это какое-то чесание левого уха правой рукой.

С деревом, конечно, есть и профит, на первый взгляд: можно узнать, какому окну пришло сообщение. Если просто устройства ввода слушать, то идут обезличенные координаты и коды кнопок, а если слушать события окон, то ты знаешь всегда, какое окно слушаешь. И даже можешь узнать, что вот эти последовательности пошли в окно FF, а эти — в терминал. Хотя надо будет уточнить, какой идентификатор окна придет в событиях...

С деревом, конечно, есть и профит, на первый взгляд

Хотя... в событиях XDeviceMotionEvent, XDeviceKeyEvent, XDeviceButtonEvent и др. из X Input Extension тоже в событии идет event window (поле event), но там, похоже, сообщается окно, над которым указатель находится. Надо проверить.

http://www.x.org/archive/X11R7.6/doc/inputproto/XIproto.txt

3.1 Button, Key, and Motion Events

               DeviceKeyPress
               DeviceKeyRelease
               DeviceButtonPress,
               DeviceButtonRelease
               DeviceMotionNotify
                       device: CARD8
                       root, event: WINDOW
                       child: Window or None
                       same-screen: BOOL
                       root-x, root-y, event-x, event-y: INT16
                       detail: <see below>
                       state: SETofKEYBUTMASK
                       time: TIMESTAMP

   These events are generated when a key, button, or valuator
   logically changes state. The generation of these logical
   changes may lag the physical changes, if device event
   processing is frozen. Note that DeviceKeyPress and
   DeviceKeyRelease are generated for all keys, even those mapped
   to modifier bits. The “source” of the event is the window the
   pointer is in. The window with respect to which the event is
   normally reported is found by looking up the hierarchy
   (starting with the source window) for the first window on which
   any client has selected interest in the event. The actual
   window used for reporting can be modified by active grabs and
   by the focus window.The window the event is reported with
   respect to is called the “event” window.

Мне для клавиш окно совсем не интересно, мне сам факт, что были нажаты такие то клавиши интересен, и от окна в фокусе ничего не должно зависеть...

Мне для клавиш окно совсем не интересно, мне сам факт, что были нажаты такие то клавиши интересен, и от окна в фокусе ничего не должно зависеть...

Так речь я веду не о зависимости от окна, а от знания, от какого окна приходило событие. Ты можешь не обрабатывать эту информацию, но она может быть полезна. Просто за компанию в событии приходит параметр event window.

И посмотри, как сделано в утилите xinput (параметры --test и --test-xi2). Там предельно все просто. Получишь коды нажатых клавиш вообще вне зависимости от всего, но с особенностью: модификаторы тоже будут коды клавиш слать. В xinput, как следует из названия, используется X Input (1 и 2).

Ну я ещё когда с тачем разбирался задумывался об использовании расширения xinput, только второй версии, хотел без расширений решить всё, но видимо так оптимальней будет...

Интересно, можно послать на устройство какой нибудь сигнал и проверить ответ, чтобы знать что устройство не подвисло?

Например

char buf[] = "что то на что ответит не зависшее устройство";
write(deviceFd, buf, sizeof(buf));
int res = pselect(...);
if (res == -1)
{
//reset device
}

только второй версии, хотел без расширений решить всё, но видимо так оптимальней будет...

В качестве каприза можно попробовать.

Интересно, можно послать на устройство какой нибудь сигнал и проверить ответ, чтобы знать что устройство не подвисло?

А что значит, подвисло? Ну, собсна, в X Input есть список устройств ввода и их свойства. Если ты что-то от USB отключаешь, то устройство пропадает. Вот и проверили. С PS/2 и COM, врочем, не уверен, что пройдет фокус. А так ядро сообщает, что что-то отключилось, а X-сервер отрабатывает. Но вот что такое «подвисшее» состояние... Драйвер завис?

Имеем хаб usb2.0, на нём большой светодиод, в него включено несколько устройств, предполагается что он активный, выключаем питание из розетки, включаем подсветку на клавиатуре - мышь светится, в списке устройств присутствует, по пока не подашь внешнее питание на хаб, курсор на движения мыши не реагирует, как этот момент проверить?

Я уже второй день ищу как с помощью xinput2 слушать устройство... Все примеры втч код из GTK и QT, предполагает делать так

XISelectEvents(...)

• Идём по дереву и вешаем на каждое окно XSelectEvent, отслеживаем создание новых окон и на них тоже ставим прослушку
• Не пользуемся xinput2, но используя xinput1 слушаем устройство вне зависимости от окна

  XOpenDevice(...)

Неужели xinput2 не предусматривает прослушивание устройства вне зависимости от окна?

Подводя итог хочу всем кому нужна рабочая программа для современных иксов без поддержки старых версий, юзайте xinput2, экономит кучу времени, даже несмотря на то, что требуется больше времени для написания.