Быстрый скроллинг на тачпаде в Fedora

Как ты пытался решить эту проблему?

Всякие аддоны подключал к хрому, но это ужас, половина сайтов начинает скроллить нормально, половина почти перестает скроллить совсем. В системе не понял как это менять, xinput выдает это:

WARNING: running xinput against an Xwayland server. See the xinput man page for details.
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer:16                     	id=6	[slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:16            	id=7	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer-gestures:16            	id=8	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ xwayland-keyboard:16                    	id=9	[slave  keyboard (3)]

но там у меня был X11

Сделай чтобы и тут был и незачем жрать вайландокактус.

Нормальный он только в настройках системы и в Firefox

Ну и использовать гуглоподелку при наличии относительно нормального браузера тоже незачем.

See the xinput man page for details.

Здесь смотрел?

Это если квалификация позволяет.

В гнум эту настройку так и не завезли под вяленым. Мердж ревестам уже 4 года, всем плевать.

А вот в кедах это все есть, хехе.

Сделай чтобы и тут был и незачем жрать вайландокактус.

Тут я с тобой, пожалуй, соглашусь.

Ну и использовать гуглоподелку при наличии относительно нормального браузера тоже незачем.

Удивительно, но тут тоже согласен - Firefox, пожалуй, лучший браузер на сегодняшний день.

Я использую хром для интернета без VPN, а Firefox с VPN (туннель короче), и альтернативные браузеры типа Brave мне не понравились. Даже если перейду на другой, проблема останется в телеграме.

Никто не мешает использовать файрфокс для обоих вариантов.

В гнум эту настройку так и не завезли под вяленым. Мердж ревестам уже 4 года, всем плевать.

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

For Wayland, there is no libinput configuration file. The configurable options depend on the progress of your desktop environment’s support for them (see #Graphical tools) or by applying desktop-agnostic udev rules (see Calibrating Touchscreen#Do it automatically via a udev rule and #Via Udev Rule). To configure options that your desktop environment does not yet support (e.g. touchpad scroll speed on GNOME) libinput-config-gitAUR may be used as a work-around. Available options for that tool are documented in the libinput-config README.

Вроде как получается что со стороны libinput на вяленом предполагается что DE будут это сами пилить на уровне своих композиторов и настроек (тут я не силен, но представляется мне примерно так).

Кеды зделоли, причем давно (щас еще от них ждем уже наконец-то нормальный инерциальный скроллинг). И там эта настройка действует на все приложения (во всяком случае, которыми я пользуюсь).

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

Проблема, которую описывает ОП известна уже 4 года. Как-то так.

щас еще от них ждем уже наконец-то нормальный инерциальный скроллинг

Всегда удивляло, что там этого не было. И нормального в ближайшее время тоже не будет.

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

Тут косяк с их стороны, не спорю.

Просто в данном конкретном случае скорость прокрутки у товарища разная. И возможность сменить дефолт на другое значение это никак бы не исправило. И вот это и смущает.

И нормального в ближайшее время тоже не будет.

Для QT-приложений уже реализовано, будет в новой версии KDE Frameworks, которая выходит через полторы недели. Хех.

Для QT-приложений уже реализовано, будет в новой версии KDE Frameworks, которая выходит через полторы недели. Хех.

Вот только это лишь для приложений на QtQuick, а вот приложения на Qt Widgets в пролёте. Т.е. в половине приложений эта инерционная прокрутка будет работать, а в половине нет. К — консистентность!

Именно поэтому я и написал «нормального». Какой-то будет, а вот нормального нет.

Именно поэтому я и написал «нормального». Какой-то будет, а вот нормального нет.

Я больше к тому что работы ведутся и реализуются, а не кладутся на дальнюю полку на 4 года как у некоторых ;)

Я больше к тому что работы ведутся и реализуются, а не кладутся на дальнюю полку на 4 года как у некоторых ;)

А сколько до этого эти работы были на дальней полке? В GTK kinetic scrolling реализован где-то с версии 3.4, вышедшей в 2012 году.

В GTK kinetic scrolling реализован где-то с версии 3.4, вышедшей в 2012 году.

Это было про libinput (вышедший в 2017) и управлению скоростью скролла тачпада, кагбе, т.е. про изначальную тему обсуждения. Нет, ну ок, спору нет, одни сделали одно, другие другое. Просто, блин, управление скоростью скролла - это прям базовый функционал, а kinetic scrolling - это уже шашечки, кмк.

Просто, блин, управление скоростью скролла - это прям базовый функционал, а kinetic scrolling - это уже шашечки, кмк.

Для кого как.

Мне вот, например, менять скорость прокрутки ни разу за 20 с лишним лет не понадобилось, поскольку дефолт полностью устраивает. (Интересно было бы узнать, какому проценту пользователей это нужно.)

А вот инерционной прокруткой пользуюсь буквально каждый день, и без неё жуть как неудобно. У меня и мышка теперь с подобной функциональностью.

Кеды зделоли, причем давно

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

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

То же самое касается и, например, спинбоксов, которые в нормальном режиме делают ±1 значение, а после изменения настройки начинают перескакивать сразу через несколько.

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

В идеале должен быть способ сообщить элементу интерфейса коэффициент скорости прокрутки, и тот уже сам сможет решить, применять его (в случае scroll area) или нет (в случае spinbox/tabbar). Видимо, вокруг этого копья и ломаются.

У тебя подверженные браузеры и телега не из флатпака? И в новом gnome вроде ж есть настройка скорости прокрутки, а в gnome-tweaks или в dconf есть настройка ускорения.