Колесо мыши прыгает при прокрутке

Однако вышеприведенные решения не сработали для меня...

Решение для меня (у меня была проблема в течение нескольких месяцев!) Было немного сюрреалистичным, и, как и большинство людей, я не верил, пока не сделал это:

Оказывается, у некоторых мышей MS есть ошибка с колесом прокрутки.

Попробуйте отсоединить USB-кабель / ключ, а затем снова подключите.

Это оно!

Теперь моя мышь двигается нормально (одна строка за раз, а не половина экрана!)

Это сработало, хотя я использую 4-портовый KVM-блок с экраном / клавиатурой / мышью! Да уж!

Да , отключите и снова подключите USB-соединение. это сработало для меня. после стольких поисков ответа и терпения так долго!

У меня есть двойная загрузка Ubuntu 11.10 и Windows 7, и я только что добавил Microsoft Wireless 3500, и когда я загрузился с Windows, он установил некоторые драйверы для него. Когда я вернулся в Ubuntu, колесо прокрутки было наполовину нервным. Я отключил USB-ключ и снова подключил его, и все вернулось в нормальное состояние. Я думаю, что есть некоторые настройки, которые устанавливаются в самой мыши из драйвера Windows. Но вышеприведенное решение простого повторного подключения мыши работает для меня.

GTK динамически вычисляет правильное значение скорости прокрутки колесика мыши (количество прокручиваемых строк) в зависимости от размера окна. К сожалению, он пока не допускает каких-либо настроек, и об этом были поданы потерянные отчеты об ошибках.

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

Для меня исправлением было очистить внутреннюю часть мыши.

Правильный способ сделать это - аккуратно разобрать его и удалить волосы и пыль, скопившиеся возле датчика колеса мыши. Я просто очень сильно врезался в щель вокруг колеса. Сработало сразу.

У меня была аналогичная проблема с совсем новой мышью (полугодовалой). Во время прокрутки вверх мышь смешивала и некоторые события вниз. Наоборот. Сначала я подумал, что проблема в драйвере. Но ошибки были видны и в окнах.

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

Поэтому я предлагаю всем попробовать его на другой ОС, и если он тоже не работает, то попробуйте "почистить" кодировщик, даже если все вокруг выглядит чистым.

У меня была точно такая же проблема. Иногда я прокручивал вниз, и экран подпрыгивал.

ОС: VERSION="20.10 (Groovy Gorilla)" Мышь: универсальная беспроводная USB-мышь.

Я попробовал другую универсальную беспроводную USB-мышь (от другого производителя), и проблема была еще хуже.

Мое верхнее колесо - это кнопка 5, поэтому:

      xev | grep -B 2 "button 5"

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

Например

      --
ButtonPress event, serial 37, synthetic NO, window 0x7000001,
    root 0x7a5, subw 0x0, time 126819928, (119,90), root:(264,229),
    state 0x0, button 5, same_screen YES
--
ButtonRelease event, serial 37, synthetic NO, window 0x7000001,
    root 0x7a5, subw 0x0, time 126819928, (119,90), root:(264,229),
    state 0x1000, button 5, same_screen YES

Странно, что одна мышь была хуже другой. Обратите внимание, что плохая мышь настолько плоха, что иногда вы можете постоянно прокручивать вверх, а она просто продолжает прыгать посередине.

Итак, я попробовал другую мышь (идентичную первой), и она отлично сработала.

Затем я попытался измерить напряжение батареи в мыши, чтобы проверить, мог ли это быть сигнал.

Хорошая мышь: 1,24 В 40% Средняя мышь: 1,32 В 60% Плохая мышь: 1,40 В 70%

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

Интересно, что на плохой мыши я обнаружил, что время от времени получаю события «кнопки 4», даже когда я прокручивал вверх. Например, я видел много событий с:

      xev | grep -B 2 "button 4"

Я открыл мышь (это не так просто, как кажется) и подул на колесо.

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

Таким образом, с тремя мышами, которые у меня были, проблема оказалась в мыши и пыли на колесе, а не в Ubuntu. То есть плохая мышь, которая вообще не могла прокручивать, теперь работает хорошо.

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

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

В основном, команда:
xinput set-prop [MOUSE_ID] "libinput Scroll Method Enabled" 0, 0, 1
сMOUSE_IDявляющийся идентификатором вашей мыши, видимой вxinput listвыход.

У меня почти такая же проблема. При очень медленной прокрутке колеса все работает нормально, ровно пять строк одновременно в gedit. При вращении быстрее он случайным образом переходит вперед-назад назад с эффектом, при котором вы часто находитесь в одном и том же месте после прокрутки колеса на один оборот. В Windows он отлично работает без драйвера. Это мышь Thrust для мобильных телефонов BT.

У меня есть дикое предположение, в чем проблема.

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

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

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

Решение

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