Чувствительность колеса прокрутки мыши

Это же должно быть что-то про частоту опроса устройства, нет?

Нет, частота опроса может влияет только на время отклика от действия, но не на результат, к тому же по дефолту используется частота опроса, которую сообщает устройство

А как посмотреть/сравнить состояние системы под разными ядрами? Что-нибудь вроде сделать снимок /sys/devices/system?

Я бы для начала 1) убедился, что эксперимент корректен - т.е. что колесо в обоих случая прокручивается на равное количество отсечек, а количество пикселей смещения оказывается разным; 2) сделал бы diff конфигов ядер

используется частота опроса, которую сообщает устройство

Может быть 6.1 стало лучше понимать, что ему сообщает Logitech Performance MX ?

Можно сравнить частоту или интервал опроса в обоих случаях https://wiki.archlinux.org/title/mouse_polling_rate

Интересно, спасибо.

Посмотрел - никакой разницы не вижу там между 5.15 и 6.1 у себя.

Наверное где-то в другом месте надо искать разницу, действительно.

По-идее, скорость прокрутки задается через xorg.conf или xinput, а ядро к ней никаким боком относиться не должно.

В том и вопрос.

Через XOrg я уже проходил эту игру по настройке колеса. На другой машине.

Тут 100% полностью идентичное окружение. Только ядро меняется. И оно влияет на то, на что вроде бы не должно было влиять.

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

Проверил.

xfce4-terminal, DBeaver, Code-OSS, MSEdge - под 6.1 листают со страшной скоростью по колесу.

Посмотрел в
/home/Sources/linux-6.0/drivers/hid/hid-logitech-hidpp.c
и
/home/Sources/linux-6.1/drivers/hid/hid-logitech-hidpp.c

Очень интересно. Но ни черта не понятно )

Может где-то тут:

	{ /* MX Master mouse over Bluetooth */
	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb012),
	  .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },

В исходнике 6.1 нет этого HIDPP_QUIRK_HI_RES_SCROLL_X2121

Недавно видел в libinput, что перевели часть устройств на hi-res scrolling. Вероятно, для корректной поддержки нужен еще и обновлённый libinput.

Вот тут ещё что-то про REL_WHEEL_HI_RES мышиный, и даже именно Logitech'овский. https://flaviutamas.com/2020/understanding-linux-mouse-drivers Позже внимательнее почитаю.

Скажите, а мышиные настройки как-то связаны с мониторными?

У меня тут особенность в том, что монитор 4К. Но я не могу на такое смотреть, слишком мелко. И в xorg.conf, и в параметрах ядра установил насильно 1920x1080. В 6.1 мышиный драйвер случайно не может умничать самостоятельно, видя гипотетические 4К, и под такое разрешение подгонять шаг прокрутки?

У меня с M705 было похожее, будто debouncing перестал работать. Переподключал, перезагружал, отключил smooth scrolling в solaar, что-то из этого помогло.

Да не, точно что-то в самом ядре Linux изменилось. Под 5.15 же работает нормально. Ну, как «нормально» - привычно.

Может под 6.1 считается, что именно так вот теперь будет = «нормально» и надо докурчивать под себя отдельно в X.

Пока просто поставил загрузку по умолчанию в Arch-lts.

С экспериментами по той ссылке на flaviutamas.com смешно получилось. usbhid-dump захватил весь Logitech, Inc. Unifying Receiver. Вместе с мышью и клавиатурой на нём же ) И всё, капец, ни того, ни другого в машине ) Сиди, смотри на перехваченные события ) Пришлось кнопкой выключать компутер )

Скажите, а мышиные настройки как-то связаны с мониторными?

Нет, не связаны.

У меня тут особенность в том, что монитор 4К. Но я не могу на такое смотреть, слишком мелко. И в xorg.conf, и в параметрах ядра установил насильно 1920x1080.

Используйте масштабирование или задайте корректный DPI.

Используйте масштабирование

Так оно и так получается масштабирование. Только на более низком уровне, насколько я понимаю. Картинка меня полностью устраивает в FullHD. Зачем видео-серверу делать лишнюю работу по впихиванию 4 пикселей в одну точку своими средствами, если это может делать драйвер видео, который ближе к железу? Мне казалось это и быстрее и легче должно быть. Очень удивлюсь, если и тут ошибаюсь.

Поставил 4К разрешение. Покрутил колесом. Ну, в принципе, наверное 4К-шное разрешение лучше подходит под такую скорость прокрутки. Чуть руку набить, можно и на FullHD будет привыкнуть, если так и не пойму как вернуть старое поведение на новом ядре.

Про libinput - там по ссылке человек, как я понял, наоборот говорил в 2020 году - мол, libinput уже умеет, теперь надо чтоб ядро сумело. Видимо мечта того человека сбылась, надо понимать.

А почему вообще нет регулировки количества строк за один щёлк? Или меня одного во всём мире это интересует?

Пришлось кнопкой выключать компутер

В man'е написано, что таймаут по умолчанию 60 секунд. Не работает?

Честно говоря не уверен, что ждал 60 секунд. Понял, что остался без мыши и клавиатуры, похихикал, да пошел кнопку нажимать. Там нормальный poweroff по кнопке, graceful, ничего страшного.

---

Вот, наконец, увидел разницу:

sudo libinput debug-events

 event19  POINTER_SCROLL_WHEEL    +47.606s	vert 15.00/120.0* horiz 0.00/0.0 (wheel)
 event19  POINTER_SCROLL_WHEEL    +47.710s	vert 15.00/120.0* horiz 0.00/0.0 (wheel)

 event15  POINTER_SCROLL_WHEEL    +28.005s	vert 7.50/60.0* horiz 0.00/0.0 (wheel)
 event15  POINTER_SCROLL_WHEEL    +30.804s	vert 7.50/60.0* horiz 0.00/0.0 (wheel)

В обоих случаях - минимально возможный поворот колеса.

Насколько я понимаю - тупо в два раза больше частота (?что там еще может означать 120 и 60?) и соответственно в два раза больше считается смещение. Видимо. И, похоже, никакое это не HI_RES. Нормальный такой SCROLL_WHEEL

120, оказывается, в терминах libinput это и есть «один щелчок». Презабавно.

``libinput_event_pointer_get_scroll_value_v120()`` returns a value normalized into the 0..120 range, see below. Any multiple of 120 should be treated as one full wheel click.

Откуда ж тогда под 5.15 ядром там libinput видит 60 ?

Так оно и так получается масштабирование.

Скейлинг средствами монитора. Зачем в таком случае вообще 4K-монитор покупать, чтобы использовать четверть разрешения, да еще и теряя на субпиксельном сглаживании шрифтов?

Зачем в таком случае вообще 4K-монитор покупать

Конечно же просто ошибся. Хотел модную игрушку без особого представления на кой ляд она мне нужна. Не понравилось - не выбрасывать же. Увёз на дачу и разжаловал в FullHD ) Эх, кабы это была единственная ошибка в жизни )

А про минимальный шаг в 120 (под 6.1) и в 60 (под 5.15) можете что-нибудь подсказать? Как вы думаете - это может быть ошибкой в мышином драйвере ядра, или наоборот это исправили старую ошибку и теперь надо подстраиваться под 120?

А про минимальный шаг в 120 (под 6.1) и в 60 (под 5.15) можете что-нибудь подсказать?

Увы, нет. Лучше спросите в багтрекере libinput или ядра.

Уже какое-то ЖЖ.

Нарыл еще вот такую штуку: sudo libinput record > 111.txt

Под 6.1 всегда события такого вида:

- [  0,      0,   2,   8,      -1] # EV_REL / REL_WHEEL                -1
- [  0,      0,   2,  11,    -120] # EV_REL / REL_WHEEL_HI_RES       -120

- [  0,      0,   2,  11,     -15] # EV_REL / REL_WHEEL_HI_RES        -15

Продолжаю наблюдения.

Ха!

Так не «примерно один раз на десяток» - а ровно 8. Пальцем посчитал - один REL_WHEEL на восемь REL_WHEEL_HI_RES.

Вот и получается, что под 5.15 эти 120 размазаны по 8 ХайРезам с шагом в 15. (8 * 15 = 120 же? Ничего не путаю?)

А 6.1 видимо не умеет так «размазывать» и фигачит ровно один в один. По 120 на каждый.

Уже даже почти начал понимать всю эту кухню )

Продолжаем ЖЖ.

Приехал в город. Тут обычная USB-мышь. Практически - деревянная. Logitech B110 Silent.

И колесо у неё простое до невозможности. Никакой тебе инерционности и гладкого вращения. Щелк, да щелк, как трещотка на колесе велосипеда.

Так вот для неё - хоть 5.15, хоть 6.1 ядра - всё равно всегда

- [  0,      0,   2,   8,      -1] # EV_REL / REL_WHEEL                -1
- [  0,      0,   2,  11,    -120] # EV_REL / REL_WHEEL_HI_RES       -120

Т.е., я так понимаю, 6.1 ядро делает из дорогой Performance MX обычную дешевую мышь.

Ну, можете ещё дойти до usbhid-dump (в паре hidrd-convert), они, вроде как, позволяют видить что приходит по USB, до обработки в /dev/event. То есть понять, что приходит от мыши, понять в ядре неправильно обрабатывают или неправильно программируют мышь. Пишут, что мыши с HI_RES колесом позволяют задать режим (множитель) колеса, и это как-то может влиять.

Вернулся на свой «лесной» стационарник. Чтобы провернуть фокус с usbhid-dump надо подключить другую мышь/клавиатуру, видимо. Пока лень лезть на чердак, искать что-нибудь живое.

Я тут нашел саму заплатку, которая меняет поведение ядра для Logitech'овских мышей.

https://lore.kernel.org/lkml/CA jURcvMcKgLzrCxXoYoxvR9uQY-J5GfQhcrpkm6mBgqqKH...

Насколько я понимаю - до 6.1 наличие/отсутствие различных HiRes было просто перечислением устройств. В случае с Performance MX - по коду устройства 0x101a (посмотрел у себя в dmesg - оно действительно такое) выставлялся флаг поддержки HI_RES_SCROLL_1P0 (что бы сие не означало, UPD: видимо поддержку HID++ 1.0 это означает).

Начиная с 6.1 эти флаги выставляются без перечисления устройств - по свойствам из hidpp_root_get_feature. Полагаю - эта Performance что-то не то там докладывает о своих возможностях.

Человеки там пишут, что тестировали на M705 и на Master MX. Мою Performance, так понимаю, не тестировали.

Попробую ядро сам собрать, потыкать там насильно в «я могу в HiRes» для Performance для начала.

---

Кстати - человек там пишет, что тестировал на M705, а у него в логах 0x406D устройство. А это другая firmware, и неё другое HIRES, судя по перечислению устройств. Не от HID++ 1.0

Опс. Истекло время для правки сообщения. Придётся новым комментарием:

Вот тоже интересная мысль: https://patchwork.kernel.org/project/linux-input/patch/20181205004228.10714-5...

Попробую ядро сам собрать

Не то чтобы прям «ядро». Там достаточно один только модуль hid-logitech-hidpp ковырять, собирать, да подсовывать смотреть что получилось.

Пока не могу победить.

Вставил в модуль

printk(KERN_WARNING "Device: %s, Caps: %ld\n", hidpp->name, hidpp->capabilities);

Пытаюсь уже без всяких проверок устанавливать в любом случае multiplier = 8 для всех попавшихся логитехов (других-то все равно нет), так не хочет слушаться, хоть тресни. Что-то упускаю.

А. Ну, вроде победил. Надо не только насильно multiplier в 8 поставить, но и насильно capabilities назначить HIDPP_CAPABILITY_HIDPP10_FAST_SCROLL

На текущий момент - если выкинуть всё, что есть в static int hi_res_scroll_enable(struct hidpp_device *hidpp) и заменить её кишки на

int ret;
u8 multiplier = 8;
ret = hidpp10_enable_scrolling_acceleration(hidpp);
hidpp->vertical_wheel_counter.wheel_multiplier = multiplier;
hidpp->capabilities |= HIDPP_CAPABILITY_HIDPP10_FAST_SCROLL;
return 0;

Осталось придумать как это более/менее аккуратно оформить и попытаться попросить внести изменения в этот модуль у его хозяина.

Cast mky, ValdikSS. Вдруг интересно.

Точнее даже hidpp10_enable_scrolling_acceleration лишнее. Прям совсем хардкодом работает:

static int hi_res_scroll_enable(struct hidpp_device *hidpp)
{
	hidpp->vertical_wheel_counter.wheel_multiplier = 8;
	hidpp->capabilities |= HIDPP_CAPABILITY_HIDPP10_FAST_SCROLL;
return 0;
}

Вроде, между 5.14 и 6 у hid-logitech-hidpp не так много коммитов. Может хозяину модуля просто сообщить о проблеме на уровне выхлопа libinput и ″u8 multiplier = 1;″ Пусть сам решает как лучше сделать подобный ″workaround″ для конкретных моделей мышей...

между 5.14 и 6

В 6.0 еще было по-старому, через коды устройств.

Это только в 6.1 приняли тот патч про capabilities, видимо. ( Речь про https://lore.kernel.org/lkml/CA jURcvMcKgLzrCxXoYoxvR9uQY-J5GfQhcrpkm6mBgqqKH... )

Изменения-то принципиальные. И, в целом, логичные/понятные. Вместо того, чтобы перечислять поштучно и выставлять вручную какое устройство чего может - считывать его возможности из самого устройства. Это я к тому, что вообще без разницы сколько было коммитов между 5.14 и 6. Вот в 6.1 коммит, так коммит. Полностью всё иначе. Все устройства Logitech, которые так не умеют и которых не было под рукой у разработчика на проверку - тупо в мусор.

У меня когда-то помощник админа примерно так делал. Выдергивал непонятный патч-корд и ждал кто прибежит. Если никто не прибегал - значит патч-корд был лишний.

Выдергивал непонятный патч-корд

Бывает такое. Кто-то выключает непонятные автоматы (автоматические выключатели), пока не обесточит соту, кто-то срезает старую телефонную лапшу со стен, пока не вызовет сработку сигнализации, кто-то выдергивает патч-коды, пока не отключит СОРМ...

тупо в мусор.

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

В вашей ссылке я не увидил заявления, что не «кривые» мыши идут побоку. С их точки зрения они потестировали и у них УМВР. ИМХО, имеет смысл написать им, что не всё так хорошо, как им кажется.

Пока остановился на варианте:

--- hid-logitech-hidpp.c	2023-01-03 09:50:22.690241477 +0700
+++ hid-logitech-hidpp.c	2023-01-04 14:01:23.900314413 +0700
@@ -3479,7 +3479,7 @@
 						  HIDPP_GET_REGISTER,
 						  HIDPP_ENABLE_FAST_SCROLL,
 						  NULL, 0, &response);
-		if (!ret) {
+		if (!ret || hidpp->hid_dev->product == 0x101a) {
 			hidpp->capabilities |= HIDPP_CAPABILITY_HIDPP10_FAST_SCROLL;
 			hid_dbg(hidpp->hid_dev, "Detected HID++ 1.0 fast scroll\n");
 		}

---

Но тут другая загадка - никак не могу добиться чтобы этот (именно этот) hid_dbg() писал своё Detected в dmesg.

Долго тупил с флагом CONFIG_HID_DEBUG. Оказывается его выпилили сто лет назад. Потом долго тупил с тем, как передать параметр модулю, который встроен в ядро. В теории там hid_debug должен взводиться в 1 по параметру «debug» у модуля «hid». Но он же встроен. Через /etc/modprobe.d не подхватывает.

Наконец дошло, что можно в параметрах ядра указать hid.debug=1

Чудненько. Теперь флудит всеми сообщениями от HID в dmesg.
Всеми.
КРОМЕ этого, едри его, «Detected HID++ 1.0 fast scroll\n».
Точно должен быть. Но нету.

Полностью параметры ядра:

root=UUID=319cfe49-3eb9-49a9-b0e5-4d8d5236e2e0 rw resume=UUID=431d0646-fe3a-4edc-a90f-1244f982ebfb audit=0 mitigations=off video=HDMI-A-1:1920x1080 debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 earlyprintk=vga,keep sched_debug hid.debug=1

Может кто-нибудь знает, что ещё упустил?

Случайно printk не может по каким-то своим соображениям пропускать вывод отдельных сообщений?

Всё. Вроде понял.

hid_dbg() при флаге CONFIG_DYNAMIC_DEBUG это вроде бы простой printf в итоге, который и виден только под отладчиком.

А вот dbg_hid() это как раз при флаге hid_debug становится printk().

Смотрю в AltLinux CONFIG_DYNAMIC_DEBUG не установлен. Можно как-нибудь потом поиграть под AltLinux в hid_dbg(). В теории там он должен быть printk.

Сегодня просто праздник закрывания тем какой-то.

До AcrhLinux долетело ядро 6.2.5, в котором починили эту мышку.

https://elixir.bootlin.com/linux/v6.2.5/source/drivers/hid/hid-logitech-hidpp.c

#define HIDPP_QUIRK_HI_RES_SCROLL_1P0		BIT(29)

Больше не надо самому пересобирать этот модуль с самодельными модификациями )