Уведомление о безопасности libinput

РЕШЕТО, весь этот ваш wayland от лукавого
сижу на безопасных иксах, libinput не установлен:

* dev-libs/libinput
     Available versions:  1.28.1(0/10)^t {doc test INPUT_DEVICES="wacom"}
     Homepage:            https://www.freedesktop.org/wiki/Software/libinput/ https://gitlab.freedesktop.org/libinput/libinput
     Description:         Library to handle input devices in Wayland

* x11-drivers/xf86-input-libinput
     Available versions:  1.5.0
     Homepage:            https://www.x.org/wiki/ https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput
     Description:         X.org input driver based on libinput

предварительно скомпилированный байт-код,
Плагин, вызывающий функцию Lua

Зачем это нужно в библиотеке, работающей с устройствами ввода?
И да, такое же у меня мнение по поводу wireplumber - нехрен тащить модульность и скриптовые плагины в основные компоненты. Зачем там lua и байт-код???

Это конец...

Р Е Ш Е Т О !

А так libinput это вайландовое поделие выходит?

А как определить используется ли оно или нет к текущих запущеных иксах?

Зачем это нужно в библиотеке, работающей с устройствами ввода?

это касается GNOME 50’s mutter

И эти же остервенелые фанатики HIG'а вырезают нормальную годную функциональность ради «простоты» и «безопасности»...

Нет, но оно безальтернативно используется большинством композиторов
Для иксов есть два драйвера ввода, поддерживающих evdev - собственно evdev и libinput. libinput не привязан к иксам и так же может использоваться другим софтом. У меня он сейчас не установлен. Раньше пользовался, но не нашёл каких-то отличий в x11-only сценарии.

cat /var/log/Xorg.0.log|grep input 

(II) Using input driver 'evdev' for (устройство)

А так libinput это вайландовое поделие выходит?

Только wayland от него не зависит, в отличии от xorg-server.

grep libinput /proc/`pgrep Xorg`/smaps

Может быть эти скрипты в wireplumber и libinput реально полезны, но я пользы от них не видел, как и от использования js в polkit
А вот проблемы были. в polkit это излишнее раздувание, когда часами приходилось собирать спидорманки-мозжс, либо ставить древнюю версию.
С wireplumber - так оно просто молча крашилось в арче после демонизации, оставляя систему без звука и с happy debug
А с libinput вон оно как получилось
На самом деле я не против, если у libinput/wp/polkit будут модули с какой-то простой апишкой и один из опциональных модулей будет реализовывать этот самый скриптинг. Но даже так бывают проблемы, вспомнить тот же glibc+nss, который ломает ресолвинг в статических сборках glibc, заставляя статические бинари фейлить ресолвинг, либо вообще падать

Зачем это нужно в библиотеке, работающей с устройствами ввода?

Затем, что большая часть libinput не имеет никаких натсроек относительно всяких функций, и это сознательная политика разработчиков libinput. Благодаря луа ты можешь описать какую-то хитрую логику взаимодействия с хидом. А иначе у всех всё должно работать одинаково - тогда уменьшается комбинаторика при тестировании.

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

А изменения вообще смешные: отключить нахрен жесты тачпада и уменьшить таймаут распознавания касания/прокрутки.

diff -u -r a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
--- a/src/evdev-mt-touchpad.c   2024-08-19 02:26:22.000000000 +0300
+++ b/src/evdev-mt-touchpad.c   2024-09-30 15:31:07.791202640 +0300
@@ -41,7 +41,8 @@
 #define DEFAULT_KEYBOARD_ACTIVITY_TIMEOUT_1 ms2us(200)
 #define DEFAULT_KEYBOARD_ACTIVITY_TIMEOUT_2 ms2us(500)
 #define FAKE_FINGER_OVERFLOW bit(7)
-#define THUMB_IGNORE_SPEED_THRESHOLD 20 /* mm/s */
+//#define THUMB_IGNORE_SPEED_THRESHOLD 20 /* mm/s */
+#define THUMB_IGNORE_SPEED_THRESHOLD 1000 /* mm/s */

 enum notify {
    DONT_NOTIFY,
diff -u -r a/src/evdev-mt-touchpad-gestures.c b/src/evdev-mt-touchpad-gestures.c
--- a/src/evdev-mt-touchpad-gestures.c  2024-08-19 02:26:22.000000000 +0300
+++ b/src/evdev-mt-touchpad-gestures.c  2024-09-30 02:19:34.217714813 +0300
@@ -1463,7 +1463,8 @@
 static bool
 tp_gesture_are_gestures_enabled(struct tp_dispatch *tp)
 {
-   return (!tp->semi_mt && tp->num_slots > 1);
+// return (!tp->semi_mt && tp->num_slots > 1);
+   return false;
 }

В оправдание libinput могу сказать, что он хорошо и довольно понятно написан. Пожертвовали настраиваемостью в угоду поддерживаемости.

ну кстати да, можно и влоб маппинги проверить

а xorg-server то от него каким боком зависит?

я помню, как его добавляли. Для мультитача, чтобы пальцами по экрану елозить. А вот про плагины слышу впервые.

synaptics

https://github.com/kekekeks/waynaptics

каким боком зависит?

xorg-server зависит от xf86-input-libinput, который зависит от libinput

не зависит, выше правильно сказали, можешь испоьзовать xf86-input-evdev

Спасибо, но я уже приготовил либинпут :) У меня было не очень много уникальных опций, как видно из патча.

не зависит

Я сужу по пакетному менеджеру, в нем зависит:

pacman -Qi xorg-server xf86-input-libinput | grep 'Depends'

Depends On      : libepoxy  libxfont2  pixman  xorg-server-common  libunwind  dbus  libgl  xf86-input-libinput  nettle  libxdmcp  sh  glibc  libxau  systemd-libs  libtirpc  libpciaccess  libdrm  libxshmfence  libxcvt
Depends On      : libinput  glibc

libinput для клавиатуры, synaptics для тачпада

ну я так, увидел знакомое слово :) может кому пригодится

libinput для клавиатуры

нет, libinput и тачпад и тачскрин поддерживает

Что «нет»? Я не писал что он поддерживает или не поддерживает, я написал что мои иксы используют.

Что за дурацкое название? Они не в курсе что Synaptics это фирма-производитель, околомонопольный, тачпадов? Ждём драйвера wayvidia, waytel и waydeon.

в арче просто жестко задали зависимость, для сборки не требуется https://gitlab.archlinux.org/archlinux/packaging/packages/xorg-server/-/blob/main/PKGBUILD?ref_type=heads#L117

ну а почему нет, это уже устоявшаяся практика, портировать иксовые утилиты с чуть измененным названием, с приставками w/wl/wlr, как например xev-wev. А в икса synaptic кто запилил, фирма?

Так в том и дело, что это не утилита с таким названием, это драйвер к продукции фирмы Synaptics. Кто его написал - не знаю.

Чтобы подчеркнуть вайландовость могли бы way-synaptics назвать хотя бы: вайландовский драйвер к синаптиксу.

хм, он разве не универсальный? мне помнится, что использовал этот драйвер с тачпадом Elantech. Да и вообще, разве есть еще какие-то драйвера в иксах для тача помимо этих двух?

Ну, видимо остальные тачпады синаптиковский протокол используют. У меня тоже Elantech оказывается.

глаза протри, у меня libinput отсутствует, а xorg собрался

то что рач опять наложил в штаны то здесь причём? В дебиане ещё больше паразитных зависимостей, но на сам xorg-server это никак не влияет

у меня libinput отсутствует, а xorg собрался

Отсутсвует, ну и хорошо. У меня присутствует, и тоже не плохо.

@temak вижу твой лик и поднятую руку: 🤡

Что-то хочешь сказать, как-то дополнить? Я весь внимание.

Вяленый опять смог. ###ШЕРЕТО###

А так libinput это вайландовое поделие выходит?

По сути да. У X11 своя подсистема ввода.

так вот почему оно тормозит - даже тему для этого создал Тормозит мышь на кликах - оказывается атака, повезло еще что

wlroots, sway и river не подвержены атаке

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

$ sudo apt --purge autoremove libinput*
REMOVING:                   
  labwc*                   libqt6webenginecore6*
  libb2-1*                 libqt6webenginecore6-bin*
  libdouble-conversion3*   libqt6webenginequick6*
  libei1*                  libqt6webenginewidgets6*
  libgudev-1.0-0*          libqt6widgets6*
  libharfbuzz-subset0*     libqt6xml6*
  libicu78*                libseat1*
  libinput-bin*            libsfdo0*
  libinput10*              libts0t64*
  libliftoff0*             libwacom-common*
  libmd4c0*                libwacom9*
  libminizip1t64*          libwlroots-0.19*
  liboeffis1*              libxcb-composite0*
  libpcre2-16-0*           libxcb-cursor0*
  libproxy1v5*             libxcb-errors0*
  libpython3.13*           libxcb-ewmh2*
  libqt6core6t64*          libxcb-icccm4*
  libqt6dbus6*             libxcb-image0*
  libqt6gui6*              libxcb-keysyms1*
  libqt6network6*          libxcb-render-util0*
  libqt6opengl6*           libxcb-res0*
  libqt6openglwidgets6*    libxcb-xinput0*
  libqt6positioning6*      libxslt1.1*
  libqt6printsupport6*     libyaml-0-2*
  libqt6qml6*              python3-jinja2*
  libqt6qmlmeta6*          python3-markupsafe*
  libqt6qmlmodels6*        python3-pyqt6*
  libqt6qmlworkerscript6*  python3-pyqt6.qtqml*
  libqt6quick6*            python3-pyqt6.qtquick*
  libqt6quickwidgets6*     python3-pyqt6.qtwebchannel*
  libqt6sql6*              python3-pyqt6.qtwebengine*
  libqt6sql6-sqlite*       python3-pyqt6.sip*
  libqt6test6*             python3-yaml*
  libqt6webchannel6*       qutebrowser*
  libqt6webchannelquick6*  sse3-support*
  libqt6webengine6-data*   xwayland*

на такое пойти не могу, если от вяленого можно отказаться, то от qutebrowser отказаться не могу.

Можно ещё так:

dpkg -r --force-depends libinput10

Но я не обещаю что после этого у тебя не появится чёрный экран вместо гуи.

чёрный экран вместо гуи

только не бросайте в терновый куст - у меня все системы без исключения в ядерную консоль стартуют

dpkg -r –force-depends libinput10

а что потом? если выполнить autoremove не потрет все остальное?

Потом apt тебе на каждое действие (не autoremove а вообще на любое) будет ругаться про сломанные пакеты и предлагать «починить», но соглашаться не следует - может и правда что-то не то сделать.

будет ругаться про сломанные пакеты

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

Если нужно только сменить libinput на evdev то удалять libinput для этого не обязательно, надо в xorg.conf что-то прописать.

А так узнать какой драйвер сейчас используется:

grep -F 'Using input driver' xorg.log(тут путь к актуальному логу)

надо в xorg.conf что-то прописать

уже все прописано и по этому иксы не лагают, а вот с вяленым засада - вначале клацаю потом колесико кручу.

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

Новость с названием «Уведомление о безопасности libinput», а в теле идет речь о небезопасности libinput, может всё-таки назвпние должно быть «Уведомление о небезопасности libinput»?

хочу что бы в вяленом мышь не тормозила на кликах, в 64-бит версии не тормозит и в 32-бит версии хочу что б не тормозила, тут походу у меня одного 32-х битная машина так как не встречал таких у кого аналогичные симптомы

Просто выкинуть вяленый не вариант? Обычно его ставят фанаты новомодного, и они же конечно ставят 64 бита.

фанаты новомодного

оно реально отрисовывет лучше даже на 4-ом пне - по этому с jwm на labwc перешел.

а говорил разницу на глаз не видно, ай-ай-ай :)

Это нужно, чтобы на луа написать дебаунсилку: В кедах есть минимальная скорость даблклика, но нет настройки «потолка скорости».

На неплохой мыши x7 очень сильно пугает, когда свои поделия заливаю через FTP, потому-что если под лекарствами нарушена мелкая моторика — прижим кнопки на 300 миллисекунд из-за дребезга контактов (термин в электронике) превращается в двойной клик, и выделение файлов в FileZilla превращается в заливку на сервер последнего кликнутого файла, или в его скачивание…

Т-е, возможность написания такого плагина, — уменьшает «почти-физическую-боль» от умеренных «спец-эффектов паркинсоны», когда в палец не идёт сигнал, чтобы прожать кнопку дважды… Очень страшное чувство, как будто в пальце нет сил, чтобы одолеть сопротивление кнопки. «Тактильные страдания»

на глаз не видно

тесты и бенчмарки показывают превосходство… взять тот же mitigations=off что с ним что без него - разницы не видно, но я знаю - с ним будет быстрей и по этому он в параметрах ядра.