Представлен (http://lists.freedesktop.org/archives/wayland-devel/2015-Aug...) первый полнофункциональный релиз библиотеки Libinput (http://cgit.freedesktop.org/wayland/libinput), развиваемой разработчиками Waylabnd с целью создания единого унифицированного стека ввода для различных графических систем и приложений, избавляя их разработчиков от необходимости повторной реализации типовых функций работы с устройствами ввода. В частности, Libinput даёт возможность использовать одни и те же средства обработки событий от устройств ввода в композитных серверах на базе Wayland и системах на основе X.Org. Код библиотеки поставляется под лицензией MIT.В своё время библиотека ответвилась от кодовой базы композитного сервера Weston и продолжила развитие в качестве самостоятельного проекта. В настоящее время поддержка libinput реализована в GNOME, Xfce, Enlightenment, Clutter и других открытых проектов. Кроме обработки событий ввода, библиотека предоставляет средства для определения устройств и управления устройствами, абстрагируя данные операций от конкретных реализаций.
Для систем на базе X.org Libinput позволяет решить проблему обработки всех видов устройств ввода и их конфигураций без задействования специфичных для каждого устройства драйвера. Например, Libinput ограничивается одним драйвером xf86-input-libinput, выступающим в роли обвязки над Libinput, вместо отдельных драйверов evdev и synaptics, которые логически отделены друг от друга, в то время как модули Libinput образуют единую шину обработки событий от клавиатур, манипуляторов типа мышь, сенсорных экранов и тачпадов.<center><img src="http://www.opennet.me/opennews/pics_base/0_1440613754.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></center>
<center><img src="http://www.opennet.me/opennews/pics_base/0_1440613769.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></center>При обработке событий могут учитываться координаты масштабирования с сенсорных экранов, генерироваться события изменения позиции указателя для тачпадов, определяться ускорение перемещения указателя и т.п. Также поддерживается эмуляция средней кнопки мыши, прокрутка колесом на мыши, определение программных кнопок для кликпадов, симуляция кликов через прикосновения к тачпаду, прокрутка жестом (касание двумя пальцами с последующим перемещением), определение случайных касаний тачпада, обработка жестов для тачпадов и нажатий несколькими пальцами.
URL: http://lists.freedesktop.org/archives/wayland-devel/2015-Aug...
Новость: http://www.opennet.me/opennews/art.shtml?num=42852
Очень хорошо.
Уже взлетело.$ rpm -q --whatrequires 'libinput.so.10()(64bit)'
kwin-libs-5.3.2-1.fc22.x86_64
kwin-5.3.2-1.fc22.x86_64
clutter-1.22.4-1.fc22.x86_64
mutter-3.16.3-2.fc22.x86_64
efl-1.14.2-1.fc22.x86_64
libinput-0.21.0-3.fc22.x86_64
qt5-qtbase-gui-5.5.0-15.fc22.x86_64
> Например, Libinput ограничивается одним драйвером xf86-input-libinput, выступающим в роли обвязки над Libinput, вместо отдельных драйверов evdev и synaptics, которые логически отделены друг от друга, в то время как модули Libinput образуют единую шину обработки событий от клавиатур, манипуляторов типа мышь, сенсорных экранов и тачпадов.systemd, ты?
И тянет за собой как обязательные зависимости mtdev (мультитоуч) и libevdev (которому питон нужен). Ну и естественно без udev это все работать не будет.Сейчас на десктопе/ноуте можно поставить xf86-input-keyboard и xf86-input-mouse - всего два пакета и (о чудо!) все работает и даже без udev ;)
c xf86-input-mouse на последних ноутах пошли оооочень большие проблемы. Сейчас в моду входят мультитачные кликпады (весь тачпад является 1-й большой кнопкой и других нет) с отсутствием жестопроцессора в relative-mode.
Т.е. если у тебя ядерный драйвер не догадается переключить тачпад в абсолютный режим и сам делать пересчет координат в относительные, отслеживать жесты и softbuttons перед отправкой в X-ы, то сам тачпад будет неюзабельным вообще (c xf86-input-mouse а не с evdev/synaptics).
Sad but true.
Хотя даже дешевые ELAN-ы с древнючих EEEPC большинство фокусов умело в firmware в relative-mode
> Т.е. если у тебя ядерный драйвер не догадается переключить тачпад в абсолютный режим и сам делать пересчет координат в относительные, отслеживать жесты и softbuttons перед отправкой в X-ы, то сам тачпад будет неюзабельным вообще (c xf86-input-mouse а не с evdev/synaptics).Не совсем понял: если в ядре включить CONFIG_MOUSE_SYNAPTICS_USB, получим эмуляцию USBHID мыши. Насколько я понимаю, ядерный драйвер synaptics умеет эмулировать кнопки (в отличии от ядерного драйвера мыши).
p.s. Проверил бы сам - но в пределах досягаемости у всех ноутов есть аппаратные клавиши.
> Не совсем понял: если в ядре включить CONFIG_MOUSE_SYNAPTICS_USB, получим эмуляцию USBHID мыши.Синаптики, если мне не изменяет склероз, делают не чистые мультитачи, а полуторапальцевые - дают координаты середины точки касания+число пальцев. Из-за этого у них простой не менющийся протокол с постоянным набором фич и эта беда не касается. А вот, например, у ELAN-ов в последней (4-й) версии hardware протокол: 5!-пальцевый честный мультитач (зачем им столько?) в absolute mode. Зато нифига не умеют в relative
Кто-нибудь в реале эту штуку палочкой тыкал? Оно рабочее или очередная серебряная пуля?
Уже давно пользуюсь им под X11, проблем не замечено (впрочем, у меня из устройств ничего экзотического нет - обычные клава и мышь).
Xfce4 поддерживает xf86-input-libinput для настройки мыши/клавиатуры.
С мышкой разницы не почувствуешь, а вот для тачпадов вещь отличная. Всякие двухпальцевые скроллы, и прочие плюшки без возни с конфигурацией. Правда вот с трекболом пока беда, ибо ScrollModifier аналога я там не нашёл. Если впилят - будет совсем замечательно.
Вот как прочёл про "без возни с конфигурацией" - сраз плохое заподозрил, полез-таки в документацию. И не зря.У них там та же архитектурная проблема, что в вейланде в целом - они не дают возможности глобально задать полиси. Другими словами, библиотека может конфигурироваться кучей способов - но сделать это может только клиент, никаких вариантов для конфигурации извне нет. То есть что в клиенте не сделали - того не будет, и простого способа перетащить куда-то привычную конфигурацию ввода тоже нет. Есть система, в которой на выбор можно запустить вейланд или иксы - с вероятностью ввод буде себя вести по-разному.
Они это даже в FAQ честно указали - "This has an effect on the availability of configuration options: if an option is not exposed by the intermediary, it cannot be configured by the client."
Ещё одна странность - нормализация: "libinput does partial normalization of relative input. For devices with a resolution of 1000dpi and higher, motion events are normalized to a default of 1000dpi before pointer acceleration is applied. As a result, devices with 1000dpi and above feel the same".
Плюс к тому значения dpi и частоты оно берёт из udev, и переопределить откуда-то ещё их нельзя.
в общем, странное оно на первый взгляд. Идея хороша, но реализация...
> Ещё одна странность - нормализация: "libinput does partial normalization of relative input.
> For devices with a resolution of 1000dpi and higher, motion events
> are normalized to a default of 1000dpi before pointer acceleration is
> applied. As a result, devices with 1000dpi and above feel the
> same".Х.з. что они имели ввиду, но это юзера, по крайне мере меня, не затрагивает. Тачпады дают absolute input, А к мышам dpi применимо очень так-сказать опосредованно и может самими мышами выбираться на ходу
> Плюс к тому значения dpi и частоты оно берёт из udev, и
> переопределить откуда-то ещё их нельзя.dpi и timestamp берет из evdev-а
У мышей DPI - это характеристика сенсора. Они тупо обрубили преимущества хороших мышей, вот и всё.DPI берёт из udev - если, конечно, они в своей же доке не наврали.
> У мышей DPI - это характеристика сенсора. Они тупо обрубили преимущества хороших мышей, вот и всё.Только сообщить мышь может любое значение ибо она не тачскрин/тачпад и не привязана к сетке координат. У меня просто на мыши кнопкой переключается 5 значений dpi на ходу. Все, к чему это приводит - к изменению скорости движения курсора.
> DPI берёт из udev - если, конечно, они в своей же доке не наврали.
У меня фряха и вместо удева - затычки чтобы libinput просто мог скомпилироваться. Тем не менее libinput вполне определил dpi тачскрина на ноуте. (Выражается в том что был определен размер (Size) - т.к. он пересчитывается в мм из размера в точках через dpi (реально evdev сообщает не dpi а dots per mm)
[aspire] ~% sudo libinput-list-devices
... бла ... бла ... бла
Device: ELAN Touchscreen, class 0/0, rev 2.00/0.10, addr 2
Kernel: /dev/input/event3
Group: 4
Seat: seat0, default
Size: 269.71x150.86mm
Capabilities: touch
Tap-to-click: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: identity matrix
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
К сетке - не привязана. А вот точность позиционирования - разная выходит, если скорость курсора присвести к одной и той же, изменив sensitivity.
> Все, к чему это приводит - к изменению скорости движения курсора.Так и должно быть. На самом деле, то что написано на мышках, означает следующее "800DPI означает, что когда мышь двигается по поверхности стола на расстояние в 1 дюйм, курсор двигается по экрану монитора на 800 пикселей". Это из инструкции к a4tech f5 с так называемым переключателем dpi. Если еще крутить программную чувствительность, это, конечно, сбивается.
Может, я капитаню, но хочу внести ясность в эти мышиные dpi
Нормализация используется для правильного вычисления ускорения. По идее авторов все мыши должны иметь одинаковую динамику, зависящую только от настроек, а не от DPI сенсора. Это не отменяет того факта, что мыши с высоким DPI будут иметь более точное позиционирование на высоких настройках чувствительности.
Точнее, нормализация используется для вычисления координат с учётом ускорения. Либо забирай без ускорения, но с полной точностью - либо с ускорением, но нормализованные. Опять же - это из доки: This normalization only applies to accelerated coordinates, unaccelerated coordinates are left in device-units. It is up to the caller to interpret those coordinates correctly.Справедливости ради - 1000 DPI - это много, так что эта нормализация особой проблемой не является. Но зачем так делать - всё равно не особо понятно. Им что, точности вычислений жалко было? Идентичной динамике полная точность не помеха.
> Идентичной динамике полная точность не помеха.Так и есть. Под нормализацией подразумевается, что если подключить мышь с большим DPI, то курсор не будет бегать быстрее, а увеличится точность позиционирования.
Ага, примерно понятно, спасибо.в сущности, нормализация, как я уже говорил, не является особой проблемой, а вот отсутствие внешнего конфига и надежда на то, что конфигурацию хранит клиент - это жаль, конечно. Раз уж делали единый компонент - так надо было его компонентом и делать, с возможностью иметь свои настройки.
Только боковой скролл у меня на тачпаде не работает :( Но может уже и починили.
> Кто-нибудь в реале эту штуку палочкой тыкал? Оно рабочее или очередная серебряная пуля?У меня под даже под фряхой работает, правда под фряхой "очень необычной". Значительных отличий от evdev-а ни в "+" ни в "-" не обнаружено.
оно в федоре из коробки с весны. работает отлично.
Не совсем понятно, можно ли вообще удалить evdev и synaptics? Будут ли работать мышь и клавиатура в таком случае? Как насчет ноутбучных клавиатур?
Можно.
оголтело реквестирую systemd-libinputd
не смог с libinput сделать следующее:Section "InputClass"
Identifier "touchpad catchall"
Driver "synaptics"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
#for events debug
#Option "SHMConfig" "true"#setting empty touchpad-zone. Scroll has full zone
Option "LeftEdge" "0"
Option "RightEdge" "0"
Option "TopEdge" "0"
Option "BottomEdge" "0"#scroll sensitivity
Option "VertScrollDelta" "333"
Option "HorizScrollDelta" "333"
#enable scroll
Option "VertEdgeScroll" "1"
Option "HorizEdgeScroll" "1"
Option "VertTwoFingerScroll" "0"
Option "HorizTwoFingerScroll" "0"
Option "CircularScrolling" "0"
EndSection
Управление курсором с тачпада мне не нужно, а нужна поверхность скролла (типа как в смартфонах, но без тапов). Libinput не имеет нужных ручек. synaptics рулит.
О, вот и началось то, чего я ожидал. наверняка найдётся ещё море других частных случаев, которые эта штука не умеет. Примерно такое общее ощущение от неё и возникло.
Удобно получается? Видимо есть трекпоинт для курсора или что-то вроде этого?
да, это thinkpad с клитором. мне - очень удобно. не выношу курсор на тачпаде. а тут: курсор на трекпоинте, медленный скролл на тачпаде (с конфигом выше), быстрый скролл трекпоинт+средняя кнопка (https://infotomb.com/nhvkv.jpg )
> быстрый скролл трекпоинт+средняя кнопкаИ зачем понадобился дополнительно еще и медленный?
Спасибище! Отличная идея. Утащил к себе на ноут.
> Спасибище! Отличная идея. Утащил к себе на ноут.Хм... Попробовал — все-таки, очень непривычно. Но идея интересная.
> Хм... Попробовал — все-таки, очень непривычно. Но идея интересная.На вкус и цвет, понятно. Зато руки всегда над клавиатурой, не надо тянуться двумя пальцами к тачу, а скроллить большим пальцем (возможно, даже левой руки!), держась указательным за трекпоинт.
Одна из главных фич для меня - простой горизонтальный скролл. В современных интерфейсах, когда все плюют на удобство, очень часто возникает необходимость горизонтального скролла.
Имею мышь a4tech wop-49. Второе колесо - горизонтальный скролл. Сегодня решал обратную задачу: при подключении такой мыши, автоматом переводить горизонтальный скролл второго колеса в вертикальный. А две дополнительные кнопки большим пальцем сделал ZoomIn/ZoomOut. Накипело :)
Графические планшеты Wacom поддерживает, нет?
