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

самопроизвольно просыпается

У меня такое бывает если пива на ночь надуюсь.

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

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

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

Как-то так.

Проще написать правило 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 клавиатуры.

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

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

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

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.

Интересно…

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

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

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

Да, на названия устройств повлиять нельзя. Ядро (и 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"

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

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

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

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

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

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

ACTION=="add|change", \
ENV{DEVTYPE}=="usb_device", \
SUBSYSTEM=="usb", \
ATTR{idVendor}=="046d", \
ATTR{idProduct}=="c534", \
ATTR{power/wakeup}="disabled"

У меня всё diabled.

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

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

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

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

Чувствую, что легче будет добавить в sudo, чтобы без пароля, и в автозапуск DE ) Спасибо Лёне за это, что убрал rc.local.

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

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

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

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

Ну, проверить легко.

echo >> user.txt
sudo echo >> root.txt
ls -l @(user|root).txt

Спасибо Лёне за это, что убрал rc.local.

Когда это?

ну да, pipe||redirect отдельный процесс видимо)

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

Ну сделал файл, сделал запускаемым и всё, он выполняется юнитом. Как и в олдовом варианте.

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

А если она отработает раньше инициализации устройства? Впрочем в системд тоже не всегда есть за что зацепиться (для меня) и начинается колхоз.

А если она отработает раньше инициализации устройства?

Что? :))

rc.local отрабатывает самый последний :-)

А вот это хорошо! Не знал, спасибо, впрочем пользоваться все равно не буду (не цепляюсь за старое) 😁

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

Потерял мысль, сложно.

https://wiki.archlinux.org/title/Power_management/Wakeup_triggers

echo 1 | sudo tee /sys/somewhere/no_turbo
например.

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

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

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

Дык есть случаи, когда > не справляется, а Т — да?

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

а | — двух

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

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

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

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

первый вариант - два оператора,
второй - один оператор, - одной строкой.
а вообще правильно, емнип, это sudo su -
со всеми инициализациями и переменными.

Меня вот в этом /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

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

а вообще правильно, емнип, это sudo su - со всеми инициализациями и переменными

Проверил, по альясам всё одинаково – не моё.

$ sudo ‘echo 1 > /sys/somewhere/to’ сработает

$ sudo 'echo XHC > /proc/acpi/wakeup'
sudo: echo XHC > /proc/acpi/wakeup: command not found

виноват, $ su -c «cmd»

Дык пароль рута вводить надо, такое себе 😀

Ну оберни в

sudo su -c 'echo XHC > /proc/acpi/wakeup'

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

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

Фига ты кудесник, работает!

если так надо и это системно, то можно в unit/rc обернуть.
я, например, сделал так с no_turbo - 1.6ghz+quick_sync+gl_gui = 12ч на батарее.

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

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

unit/rc

Не знаю что это такое, у меня systemd.

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

а systemd вроде от рута работает

Да, если не указывать юзера или точно указать — User=root.