Автоотключение мыши
Доброго времени суток. Проблема странная и наверняка решается легко при наличии соответствующих знаний. Поиск в гугле результатов не дал. Проблема следующая: мышь деактивируется (засыпает, перестает реагировать на движения) через несколько секунд ее не активности. Вернуть ее можно нажатием на любую кнопку, но опять же на несколько секунд. Пока мышь двигается, она не отключается, но если не трогать ее секунды 2-3, то она выключается.
Проблема странная, потому что неделю назад на этом же ноуте с этой же мышкой стоял этот же Gentoo и все работало, потом снес генту, поставил Arch linux, все работало без проблем, а сейчас решил вернуть генту и вот тебе на. Сначала грешил на gpm, потому что для него вроде как это поведение является нормальным (исчезновение курсора после недолгой неактивности), и в прошлый раз, когда стоял генту, я не использовал gpm. Снес его, не помогло. udev пересобирал, xorg (кстати он версии 1.8) и evdev тоже пересобирал. В конфигурации ядра отключил PS/2, да и вообще все дрова для мышки, оставил только event и HID. Мышка USB A4Tech XL-740K. Если у кого есть мысли, буду рад выслушать.
Загляните в lsusb и найдите там свою мышу, после этого, зная ее BusID и DevID, без труда отыщите ее в /sys/bus/usb/devices.
Там посмотрите, что за значение стоит в power/control. Если auto, то поменяйте на on и думайте, кто мог его установить туда(powertop, pm-powersave, etc).
Спасибо, сегодня после работы попробую.
Попробовал. Нашел файлик, поменял значение на on, перестала уходить в сон мышка. Но при перезагрузке нужно снова это проделывать. Если выдернуть вставить из юсб мышку, то тоже сбрасывается файлик, это навело на мысль что udev сам и прописывает эти значения. В подтверждение этого факта может выступать следующее: при старте системы мышка загорается и горит приблизительно пока не загружается udev, как строчка что он загрузился появляется мышка гаснет. Как варианты решения проблемы вижу два:
1. В интернете нарыл правило для udev (http://www.thinkpad-forum.de/software/linux/67929-2-6-30-maus-usb-autosuspend. ), в котором можно прописать данные об устройствах, для которых будет отключаться autosuspend. Но этот вариант не очень нравится из-за того, что если подключить другую мышку, то нужно будет редактировать правило.
2. Отключить в ядре suspend для всех юсб устройств. Этот вариант не нравится тем, что придется отказаться от одной из функций энергосбережения.
Есть ли другие варианты заставить udev отключать autosuspend для input устройств?
Установка генту свежая, никаких утилит для контроля питания (powertop, pm-powersave, laptop-mode и др.) еще не ставил, даже acpid еще нет (может стоит поставить как вариант решения проблемы?). В прошлый раз проблемы с мышкой небыло потому что опция suspend для всех USB устройств в ядре была выключена.
Выставляет значение, конечно, не udev, он просто подгружает драйвер usbшный. Поэтому мышка и горит, пока он не загрузился. Попробуйте такое правило, оно у меня работает, но у меня мышка беспроводная поэтому пришлось добавить строчку про ресивер:
ACTION=="add", SUBSYSTEM=="input", ENV=="mouse", ATTR="auto" ACTION=="add", SUBSYSTEM=="usb", ATTRS=="USB Receiver", ATTR="auto"Вам она может не понадобиться. Если не будет работать, киньте лог udevadm monitor —udev —property при втыкании/вытыкании мыши.
Спасибо, вечером попробую и отпишусь.
П.С. А у вас мышка работает а параметром power/control = auto? Если так, значит проблема у меня в мышке, которая неверно реагирует на комманды драйвера, связанные с энергосбережением?
Работает с power/control = on. Если выставить auto, то она тоже периодически «засыпает». Как оно и должно быть.
Мысль здравая. Попробовал, поэксперементировал. В итоге получилось достичь желаемого эффекта только с использованием следющей строки:
ACTION=="add", SUBSYSTEM=="usb", ATTR="on"С вашей строкой, и даже с такой строкой:
ACTION=="add", SUBSYSTEM=="input", ATTR="on"Проведя небольшое исследование вывода предложенной вам комманды, обнаружил несколько событий при подключении мышки. Есть события и с SUBSYSTEM==«input», но реакция на них не дает желаемого результата. Что же касается событий с SUBSYSTEM==«usb», реакция на любое из них ведет к желаемому результату. Т.е. если к работающей строке добавить условие, уникальное только для одного из событий с SUBSYSTEM==«usb», то мышка спать не уходит. Т.е. нет разницы, реагировать на каждое из них, или на какое-то одно. Но проблема в том, что в параметрах этих событий нет намеков на то, что подключена мышка, устройство ввода или HID-устройство. Все намеки на это есть только в событиях с другой SUBSYSTEM, реакция на которые не дает нужного эффекта. Т.е. что-бы создать привило отключения сна для моей мышки, а не для всех юсб устройств, мне нужно явно указывать модель, или хотя бы производителя, например так:
ACTION=="add", SUBSYSTEM=="usb", ENV==A4Tech, ATTR="on"Недостаток такого подхода в том, что мышка другого производителя этому правиду не подчинится. Как вариант решения вижу реакцию на событие с SUBSYSTEM==«input», но вместо задания атрибута вызывать скрипт, который должен нахдить соотв. устройство и напрямую редактировать файл power/control. Но в душе надеюсь, что этого удастся избежать и получится все сделать силами udev.
П.С. Только что нашел подходящее решение. В одном из событий с SUBSYSTEM==«usb», есть параметр
Таким образом следующее правило с реакцией на это событие отключит сон для всех (по идее) USB HID устройств:
ACTION=="add", SUBSYSTEM=="usb", DEVNAME=="/dev/usb/hiddev*", ATTR="on"Получается что проблема решена. Не думаю, что это подойдет для любой ситуации, но думаю что это максимально общее правило, которое будет работать для моей мышки. Если у вас есть идеи как сделать его еще более общим, буду рад выслушать. Но мне кажется что более общим его можно сделать только расширив новыми строчками вроде ваших. Т.е. для каждого конкретного случая, если он не попал под одно из предидущих правил, нужно будет добавить строчку, что на данном этапе мне не нужно.
Спасибо большое за идею с power/control и коммандой для мониторинга событий udev. Фактически ваши рекомендации и решили проблему.
В дополнение хотел выложить вывод комманды udevadm monitor —udev —property, но пишет что слишком большое сообщение, а куда в интернете выкладывать логи я не знаю. Если подскажете сайтик, выложу.
Рандомное отключение USB мыши
Возникла проблема с usb мышью a4tech x7. После запуска системы, мышь работает минут 10-20, потом просто «замораживается». Может вообще 1 минуту продержаться. При этом светодиоды на мышке горят и в логе lsusb она отображается, даже если ее выдернуть.
USB клавиатура и система работает исправно, в это время. Проверял на разных дистрибутивах: debian, ubuntu, mint, opensuse. Везде то же самое.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader
Bus 004 Device 002: ID 1a81:1004 Holtek Semiconductor, Inc.
Bus 003 Device 002: ID 09da:9090 A4 Tech Co., Ltd XL-750BK Laser Mouse
Прошу помощи. Если нужны какие-то сведенья, то спрашивайте. Я новичок в этой среде, поэтому не ругайте сильно :[
Это то понятно. Хотелось бы узнать в чем причина таких фризов.
Чего в dmesg? У меня подобное на ноуте есть, но там перетерся шлейф на вебку, поэтому периодически происходит закорачивание D+ на D- и ошибка USB шины. В итоге все, что на той же шине висит, тоже отваливается. В dmesg появляются соответствующие маты.
Если матов в dmesg по поводу ошибок шины нет, могут быть маты по поводу неправильного формата кадра. Это означает, что у мыши подыхает контроллер.
Если вообще матов в dmesg нет, кроме записей об отключении, то либо провод где-то перетерся, либо в гнезде хреновый контакт, либо контроллер мыши подыхает.
у меня точно такое же было, сперва пенял на 12309, потом увидел засранный лог сообщениями переподключения мыши, перетыкание в другой порт не помогло. потом заметил что на несколько секунд питание мышь теряет. т.к. комп рабочий — сменил мышу чем ковыряться в выяснении проблемы провод это или что.
irknet@debian:~$ dmesg | tail [ 717.776733] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 719.120048] usb 2-4: reset high-speed USB device number 2 using ehci_hcd [ 769.774751] sd 8:0:0:0: [sdb] Test WP failed, assume Write Enabled [ 769.776747] sd 8:0:0:0: [sdb] Asking for cache data failed [ 769.776754] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 773.124053] usb 2-4: reset high-speed USB device number 2 using ehci_hcd [ 821.774773] sd 8:0:0:0: [sdb] Test WP failed, assume Write Enabled [ 821.776773] sd 8:0:0:0: [sdb] Asking for cache data failed [ 821.776779] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 821.936047] usb 2-4: reset high-speed USB device number 2 using ehci_hcd Это во время замороженной мыши. Или вам нужен какой-то другой лог?
p.s. Мышь исправная, входы usb — тоже исправные. Такое случается только на linux.
Переставил мышь в другое гнездо.
irknet@debian:~$ dmesg | tail [ 376.795612] input: A4TECH USB Device as /devices/pci0000:00/0000:00:04.0/usb4/4-5/4-5:1.1/input/input11 [ 376.795874] generic-usb 0003:09DA:9090.0006: input,hidraw3: USB HID v1.11 Mouse [A4TECH USB Device] on usb-0000:00:04.0-5/input1 [ 419.778522] sd 8:0:0:0: [sdb] Test WP failed, assume Write Enabled [ 419.780536] sd 8:0:0:0: [sdb] Asking for cache data failed [ 419.780544] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 423.120045] usb 2-4: reset high-speed USB device number 3 using ehci_hcd [ 471.778544] sd 8:0:0:0: [sdb] Test WP failed, assume Write Enabled [ 471.780546] sd 8:0:0:0: [sdb] Asking for cache data failed [ 471.780553] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 475.120046] usb 2-4: reset high-speed USB device number 3 using ehci_hcd irknet@debian:~$ dmesg | tail [ 419.780544] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 423.120045] usb 2-4: reset high-speed USB device number 3 using ehci_hcd [ 471.778544] sd 8:0:0:0: [sdb] Test WP failed, assume Write Enabled [ 471.780546] sd 8:0:0:0: [sdb] Asking for cache data failed [ 471.780553] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 475.120046] usb 2-4: reset high-speed USB device number 3 using ehci_hcd [ 523.778570] sd 8:0:0:0: [sdb] Test WP failed, assume Write Enabled [ 523.780566] sd 8:0:0:0: [sdb] Asking for cache data failed [ 523.780574] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 525.120045] usb 2-4: reset high-speed USB device number 3 using ehci_hcd