LINUX.ORG.RU
Форум — Linux-hardware  

Dell Latitude 5430 произвольно просыпается

 ,


0

1

Заметил, что периодически ноутбук самопроизвольно просыпается из suspend. По крайней мере когда лежит в сумке. Есть подозрение, что из-за тряски нажимается какая-то кнопка (он вообще даже, если провести по тачпаду, просыпается). В биосе не нашёл ничего, что бы настраивало просыпание (например, чтобы просыпался только от открытия крышки или нажатия на кнопку питания).

Можно ли как что настроить в этом плане?

Вот такая команда тебе покажет, какие девайсы пробуждают комп:

grep . /sys/bus/usb/devices/*/power/wakeup

В моём случае (десктоп) выхлоп вот такой:

/sys/bus/usb/devices/1-1.4/power/wakeup:disabled
/sys/bus/usb/devices/1-1.5/power/wakeup:enabled
/sys/bus/usb/devices/1-1/power/wakeup:disabled
/sys/bus/usb/devices/2-1/power/wakeup:disabled
/sys/bus/usb/devices/usb1/power/wakeup:disabled
/sys/bus/usb/devices/usb2/power/wakeup:disabled

В этом выхлопе видно, что пробуждать разрешено только девайсу 1-1.5, – это мышка. Обычно по умолчанию в линукс устанавливается клавиатура (у меня во всех дистрах именно так). Однако в любом случае пробуждать должна кнопка Power (она не представлена в списке, то есть её здесь выключить не получится). В твоём случае, видимо, это будет клава, тачпад, крышка ноутбука и Power.

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

Выяснить к какому девайсу относится конкретное название я бы предложил методом тыка, то есть отключая по очереди. Например в моём случае, чтобы отключит мышку (1-1.5), надо так:

sudo echo disabled > /sys/bus/usb/devices/1-1.5/power/wakeup

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

Теперь как автоматизировать процесс

Я тебе просто изложу как сделал себе, а ты переделай под себя, или иди каким-то другим путём – тут дело хозяйское, на то оно и линукс, вариантов дофига.

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

/sys/bus/usb/devices/1-1.4/power/wakeup:enabled
/sys/bus/usb/devices/1-1.5/power/wakeup:disabled

или бывает так:

/sys/bus/usb/devices/2-1.4/power/wakeup:enabled
/sys/bus/usb/devices/2-1.5/power/wakeup:disabled

Первый – клава, второй – мышь, а мне надо наоборот.

Надо написать systemd-юнит, который будет триггериться на suspend и запускать нужный скрипт. Я сделал привязку к suspend, чтобы всегда иметь нужный результат перед засыпанием компа из-за смены имен девайсов (если у тебя такой проблемы нет, то можешь сделать одноразовый запуск при старте компа, хотя я не советую, всё равно может что-то слетать, КМК).

Создай файл /etc/systemd/system/название_сервиса.service. Знатоки systemd могут покритиковать, но у меня всё работает отлично:

[Unit]
Description=сюда описание своего сервиса
Before=sleep.target

[Service]
User=root
Type=oneshot
ExecStart=/opt/wakeup_by_mouse
#ExecStartPost=sleep 1

[Install]
WantedBy=sleep.target

(Закомментированная команда тебе может не пригодиться, это из-за проблем в старом гноме (долго объяснять), но если хочешь небольшую задержку перед suspend, то раскомментируй и напиши количество секунд)

Этот юнит будет одноразово срабатывать каждый раз перед suspend и запускать незатейлевый скрипт, который лежит в /opt, от имени пользователя root.

Скрипт делает уже известные тебе вещи:

#!/bin/bash

if [ -e /sys/bus/usb/devices/1-1.4/power/wakeup ]
  then
    echo disabled > /sys/bus/usb/devices/1-1.4/power/wakeup
    echo enabled > /sys/bus/usb/devices/1-1.5/power/wakeup
  else
    echo disabled > /sys/bus/usb/devices/2-1.4/power/wakeup
    echo enabled > /sys/bus/usb/devices/2-1.5/power/wakeup
fi

Активировать сервис: systemctl enable --now название_сервиса
Посмотреть как отработал сервис: systemctl status название_сервиса
Проверить отработал ли скрипт: grep . /sys/bus/usb/devices/*/power/wakeup

Перезагрузить комп, усыпить, пробудить, и снова проверить всё ли отработало.

Как-то так.

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

Проще написать правило udev, которое будет менять значене атрибута power/wakeup у устройства, когда оно появляется или изменяется:

# /etc/udev/rules.d/99-wakeup.rules
# disable all wakeup sources except of power button
ACTION=="add|change", KERNEL!="LNXPWRBN:00", ATTR{power/wakeup}=="enabled", ATTR{power/wakeup}="disabled"

Вместо KERNEL!="LNXPWRBN:00" тут можно использовать другие условия. Например, DRIVER!="atkbd" чтобы оставить wakeup с PS/2 клавиатуры.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

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

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

Я себе сделал только для ssd правило, но как-то просветление не наступило.

papin-aziat ★★★★★
()
Последнее исправление: papin-aziat (всего исправлений: 1)
Ответ на: комментарий от papin-aziat

udev слушает uevent-ы из ядра. В этих uevent-ах ядро уведомляет о появлении (ACTION=="add"), изменении (ACTION=="change"), и исчезновении (ACTION=="remove") объектов ядра. Речь идёт об объектах ядра, видимых через sysfs. Поэтому если понимаешь структуру sysfs, то разобраться с правилами udev не сложно. Правила udev просто говорят, какие действия выполнять при получении того или иного события.

В каждом правиле есть условия матчинга и действия. Операторы == и != выполняют матчинг события или объекта ядра, к которому это событие относится. Например, ACTION=="add" матчит тип события, KERNEL=="sd*" матчит sysfs-имя объекта, ATTR{partition}==1 матчит sysfs-атрибут объекта.

Операторы =, :=, +=, -= выполняют действия. Например, GROUP="disk", MODE=0660 меняет группу и пермиссии dev-файла устройства, SYMLINK="system-drive" создаёт симлинк на dev-файл устройства, ATTR{queue/scheduler}="none" меняет sysfs-атрибут объекта, NAME=lan меняет имя сетевого интерфейса, RUN{program}="hdparm -B 255 %devnode" запускает программу.

Синтаксис конечно уродливый, но все возможности описаны в man udev.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Интересно…

Я правильно понимаю, что до появления объекта в sysfs (я пока ничего не знаю про него) ничего сделать нельзя, а этот udev работает только с тем, что ядро уже обнаружило и именовало?

Поэтому, например, через udev нельзя решить проблему скачущих названий дисков, то есть гарантировать, чтобы конкретный девайс получил sda, а другой sdb и тд? Соответственно и на скачущие названия usb-портов в моём случае тоже повлиять нельзя?

То есть, мне придётся писать правило для двух случаев?

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

Да, на названия устройств повлиять нельзя. Ядро (и udev) поддерживает переименование только сетевых интерфейсов. Но можно ориентироваться не на имена, а на атрибуты устройства. Например условия SUBSYSTEM=="block", NAME=='nvme*', ATTR{device/serial}=="22405E800325" сматчат конкретный nvme диск, независимо от номера, которое назначило ему ядро.

Или я хочу запретить выход из сна с моей USB клавиатуры и разрешить с моей USB мышки. Я смотрю их USB idVendor и idProduct:

$ lsusb |grep -i -e mouse -e keyboard
Bus 003 Device 049: ID 413c:301a Dell Computer Corp. Dell MS116 Optical Mouse
Bus 003 Device 048: ID 1a2c:4094 China Resource Semico Co., Ltd USB Keyboard

и пишу правила:

ACTION=="add|change", SUBSYSTEM=="usb", ATTR{idVendor}=="413c", ATTR{idProduct}=="301a", ATTR{power/wakeup}="enabled"
ACTION=="add|change", SUBSYSTEM=="usb", ATTR{idVendor}=="1a2c", ATTR{idProduct}=="4094", ATTR{power/wakeup}="disabled"

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

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

lsusb |grep -i -e mouse -e keyboard

Удобно у тебя получается, а у меня такой выхлоп:

$ lsusb
Bus 001 Device 005: ID 093a:2533 Pixart Imaging, Inc. 
Bus 001 Device 003: ID 258a:0016  
Bus 001 Device 002: ID 8087:8000 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:8008 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Надо как-то понять ху из ху.

papin-aziat ★★★★★
()
Ответ на: комментарий от iliyap

Ага, ничтяк, работает! Спасибо за ликбез.

Правда в моём случае придётся всё равно оставить systemd-юнит, только убрать из него скрипт. Не знаю как в новых гномах, но на моём (3.32), если блокировка (lock-enabled) перед suspend выключена, то он глючит и может два раза подряд усыплять комп, и никакого другого решения кроме как добавить секунду перед suspend найти не смог. Где-то на просторах арчвики нашёл, оказывается такое не только в гноме бывает.

papin-aziat ★★★★★
()
Ответ на: комментарий от iliyap

У меня работает только если переткнуть usb-приемник.
Или руками echo disable > /sys/..../wakeup
Эти варианты работают до перезагрузки.

ACTION=="add|change", \
ENV{DEVTYPE}=="usb_device", \
SUBSYSTEM=="usb", \
ATTR{idVendor}=="046d", \
ATTR{idProduct}=="c534", \
ATTR{power/wakeup}="disabled"
dmitry237 ★★★
()
Ответ на: комментарий от papin-aziat

У меня всё diabled.

Методом тыка удалось вырубить пробуждение по тачпаду:

echo disabled >  /sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-VEN_06CB:00/power/wakeup

Пока вроде этого достаточно.

Wapieth
() автор топика
Ответ на: комментарий от Wapieth

Я ж подробно расписал. Если девайс не прыгает при перезагрузке, то вообще никаких лишних движений: положил свою команду в виде скрипта куда-нибудь в /opt и оформил сервис по шаблону, который я дал, там ничего менять не надо кроме пути к скрипту. Впрочем, можно и тупо прямо в ExecStart команду вставить.

Но интереснее надёжнее и проще — правило udev.

Пиши, если не получается.

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

sudo echo disabled > /sys/bus/usb/devices/1-1.5/power/wakeup

вроде как надо:

echo disabled | sudo tee /sys/bus/usb/devices/1-1.5/power/wakeup

на перенаправлении/пайпе права sudo кончаются, кмк.

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 1)
Ответ на: комментарий от Dimez

Дык вроде если сервис поддерживающий старый формат не активирован, а rc.local не исполняемый, то увы. У меня так и есть, хотя я ничего специально не делал по этому вопросу, то есть rc.local не работает.

papin-aziat ★★★★★
()
Ответ на: комментарий от etwrq

Наверное можно сказать так: оператор > —однокомандный, а | — двух (соответственно, если первая от рута, то вторая не становится такой из-за того, что рут ей что-то там передаёт на вход).

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

*возможно, подушню, но
\> и >> сущность шелла с текущей сессией и uid/gid.
а stdout/stderr возвращают выхлоп именно в текущую шелл-сессию, не важно в pipe/redirect.

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 1)
Ответ на: комментарий от etwrq

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

Мне баш очень интересен, но я пока ещё далёк от понимания многих вещей.

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

либо явно указывается
# echo 1 > /sys/somewhere/to
либо
$ echo 1 | sudo tee /sys/somewhere/to
так правильно, кмк.
но истина в исходниках ядра, coreutils и $SHELL
и в /sys||/proc readonly файлы есть - это дизайн.

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 1)
Ответ на: комментарий от papin-aziat

ну
$ sudo echo 1 > /sys/somewhere/to не сработает, тащемта - например.
а
$ sudo 'echo 1 > /sys/somewhere/to' сработает, например.
но это давно утерянные технологии))

а | — двух

это вроде вообще daisy chain, можно комбинить(+escape) вплоть до $CMD_LENGTH, примерно - я точно не вспомню названия переменной, но условно сколько сможет съесть $SHELL до переполнения ввода.

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 5)
Ответ на: комментарий от etwrq

sudo echo 1 > /sys/somewhere/to не сработает

Да, по памяти писал, надо перейти в sudo -i, конечно.

А почему так, можешь объяснить по-простому?

papin-aziat ★★★★★
()
Последнее исправление: papin-aziat (всего исправлений: 1)
Ответ на: комментарий от anonymous

Меня вот в этом /proc/acpi/wakeup удивляет такая фигня:

# grep PEG0 /proc/acpi/wakeup 
PEG0	  S4	*enabled   pci:0000:00:01.0
# echo PEG0 > /proc/acpi/wakeup
# grep PEG0 /proc/acpi/wakeup 
PEG0	  S4	*disabled  pci:0000:00:01.0

Как так, почему весь файл не затирается?

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

А почему так, можешь объяснить по-простому?

Потому что sudo заставляет только echo запускаться с правами root, а перенаправление выхлопа остаётся с правами текущего пользователя.

Dimez ★★★★★
()
Ответ на: комментарий от Dimez

перенаправление выхлопа остаётся с правами текущего пользователя

Чёрт подери, не ожидал такого поворота. Вот и ответ на мой вопрос выше. Приходится использовать tee через пайп, потому что его можно от sudo, а перенаправления никак (кроме этих ваших хаков).

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

$ man 5 systemd.unit
а systemd вроде от рута работает, там можно без sudo/su.
и в моём 7390, со стоковой ubuntu, acpi/dsdt прямые из коробки.
без лишних телодвижений всё работает(+no_turbo).

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 3)
Linux-hardware