Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 47
а не проще сделать простенькое расширение браузера (одна строка js), меняющее navigator.wakeLock.request на заглушку? бонус: расширение будет работать не только в chrome, но и в firefox и safari.
Это системная функция браузера, не факт что сработает.
Ну и Хром такой не один, как только в systemd сделали дырку для управления питанием — понеслось, теперь и плееры и видеоредакторы и калькуляторы лезут блокировать засыпание.
В Firefox оно, вроде, штатно отключается через about:config (dom.screenwakelock.enabled и media.video-wakelock, не вникал детально, в чём разница в этих двух параметрах)
А по поводу того, как проще - тогда уж надо бы PR в XFCE оформлять, который добавляет настройку "Allow apps to request wakelock", лучше ещё и с выбором приложений, которым можно или нельзя. Иначе пересобирать со своим патчем при каждом обновлении будет, хм... утомительно.
Это еще один невозможный с точки зрения технических специалистов PR, уже проходили с открытием диалога.
не вникал детально, в чём разница в этих двух параметрах
Судя по всему, первое отключает поддержку Wake Lock API, а второе меняет поведение самого браузера при просмотре видео.
То есть, если нужно лишь запретить сайтам рулить отключением экрана по их усмотрению, но хочется, чтобы при просмотре видео браузер всё же не давал увести тачку в сон, нужно крутить первую настройку. А если хочется, чтобы экран отключался, невзирая на происходящее - то обе.
А можно раскрыть, в чем проблема? Вы хотите, чтобы комп засыпал, пока вы кино смотрите?
Проблема в том, что "дырку для кино" стали использовать все подряд, например чтобы сделать блокирование перехода в спящий режим все время пока открыта страница сайта.
В качестве "фишки".
Соотвественно теперь возможно такое, что если оставляете включенным ноутбук с открытым сайтом в браузере, он легко может и не заснуть, полностью разрядив батарею.
Да, интересно, не сталкивался сам, если честно.
А не смотрели, что приходит в reason? Может там можно различть как-то когда сам браузер запрашивает или это шаловливые ручки сайтописателя?
На скриншотах же видно сообщение "Playing audio", так что оно достаточно общее, хотя и обязательное (судя по коду).
На самом деле сам факт программной инициации из JS столь системного действа как управление питанием - лишь половина проблемы, есть и вторая:
задумайтесь, что произойдет если браузер отправит сообщение через dbus на запрос перехвата и оно будет принято, а затем браузер упадет.
спойлер:
блокировка засыпания останется висеть и убрать ее не получится, тк таймаут обрабатывается на стороне браузера, но не в менеджере питания.
Цирк короче.
"дырку для кино"
В Firefox это грамотно разделено на две сущности: сайт может блокировать гашение экрана независимо от типа контента, параллельно сам браузер блокирует гашение при воспроизведении видео. Соответственно, можно отключить вредное первое, не лишаясь полезного второго.
Если в Хроме это всё отдали исключительно на откуп сайтам, да ещё сделали не отключаемым... ну, что ж, очередной повод любителям Хрома взглянуть в сторону более дружелюбных браузеров.
Извините за критику, но это не решение, а временный костыль.if (strstr(IN_appname,"chrom") != NULL ) {
А если пользователь откроет Brave|Firefox|Opera|любой другой браузер?
А не перезапишется ли патч при обновлении? А если не перезапишется, а у XFCE API для менеджера управления питанием поменялось?
А что насчёт других DE?
Суть проблемы не решена. При просмотре одного видео (фильма) ноут засыпать не должен, а при просмотре другого (рекламы) - должен. Но с точки зрения браузера разницы никакой нет!
Проблема злоупотребления полезной технологией не нова. С уведомлениями на сайтах тоже самое - полезно для условного Gmail, но маркетологи начали злоупотреблять, браузеры начали запрашивать разрешения и теперь на каждом втором сайте нужно отклонять "разрешите показывать вам уведомления".
Я думаю, что с этой проблемой случится то же самое - если злоупотребление станет массовым, то блокировку засыпания просто добавят в список разрешений, требующих одобрения пользователя, как доступ к микрофону, камере, уведомлениям сейчас.
Ну а пока можно просто закрывать крышку ноутбука, отправляя его в сон принудительно.
А если пользователь откроет Brave|Firefox|Opera|любой другой браузер?
Тогда он быстренько изучает С и добавляет условие для этого браузера.
А не перезапишется ли патч при обновлении?
Обязательно перезапишется и придется заново повторять процесс. Теперь понимаете ценность source-based дистрибутивов?
А если не перезапишется, а у XFCE API для менеджера управления питанием поменялось?
Если будет любое расхождение версий - все немедленно сломается. И придется повторять все шаги для новой версии. Зато сможете на себе ощутить роль ментейнера пакета, всю боль и страдания при обновлениях апстрима.
Суть проблемы не решена.
Это к Минобороны, только они смогут жахнуть по штаб-квартире Гугла, или где там сидит центр разработки Хрома.
Ну а пока можно просто закрывать крышку ноутбука, отправляя его в сон принудительно.
Вы не поняли глубину пробемы )
Браузер заблокирует засыпание, даже если вы закроете крышку ноутбука (если она управляется через менеджер питания). В статье есть скриншот с сообщением пользователя, который как раз очень огорчился, когда ноутбук не заснул после закрытия крышки.
Теперь понятен смысл статьи?
даже если вы закроете крышку ноутбука
ну это уже свинство конечно.
Браузер заблокирует засыпание, даже если вы закроете крышку ноутбука (если она управляется через менеджер питания).
Я не настоящий линуксоид, но похоже на проблему приоритетов. Неужели в systemd нет что-то похожего?
Теперь понимаете ценность source-based дистрибутивов?
А на source-based дистрибутивах энергопотребление на пересборку программ при обновлениях не перекрывает проблему энергопотребления из-за бессонницы браузера?
Извините за критику, но это не решение, а временный костыль.
Это вполне решение, но подходит оно очень ограниченному кругу пользователей.
Вот так и получаются новые дистрибутивы или форки софта. Когда авторы делают какую-то несусветную дичь. По крайней мере, по мнению автора форка.
Интересно, а насколько глубоко мейнтейнеры дистрибутива могут лазить руками в код и менять его? Вот можно выпилить данную функцию из XFCE и положить в репозитории своего БолгенОС?
Я не про лицензию или про технические возможности. Я про логику и некую политику - где граница возможностей мейнтейнера дистрибутива. Когда он становится уже разработчиком?
а насколько глубоко мейнтейнеры дистрибутива могут лазить руками в код и менять его?
Очень глубоко, примерно по локоть :) В качестве примера так выглядит список патчей для Хрома от команды FreeBSD.
Когда он становится уже разработчиком?
Сразу с рождения ) На самом деле это достаточно абстрактные вещи, как и самоопределение программистов.
Гляньте список патчей, которые Debian или Red Hat накладывают на ядро Linux или на тот же Firefox, там могут быть сотни исправлений, так что технически мейнтейнер может выпилить эту функцию, да, но политически вряд ли. Будет слишком сильное расхождение с апстримом, которое потом будет больно поддерживать.
Если правильно помню, можно запретить управление питанием через политики dbus при помощи конфига в недрах /etc/dbus-1.
Правда, не помню, с какой точностью это можно запретить, то есть, можно ли это запретить только для приложения.
Конечно можно, но прежде чем запрещать, стоит осознать сущность бытия механизм работы:
Хром посылает сообщение о перехвате, DBus его пропускает в специальный обработчик inhibit, которым является xfce4-power-manager, который решает что с этим делать.
Если xfce4-power-manager решает что можно - посылает еще один сигнал через DBus уже к systemd для реализации этой самой блокировки.
Если запретить механизм inhibit - менеджер управления питанием не сможет работать, поскольку он точно также лишь "отсылает сигналы".
И абсолютно все участники этой сложной схемы просто хотели как лучше, разумеется.
Патчить системные компоненты вручную это конечно круто и по хакерски, но это путь воина-одиночки
Как верно заметили в комментариях, после первого же apt upgrade весь ваш патч улетит в трубу. Более системное решение это либо PR в апстрим, либо создание своего пакета с патчем для своего дистрибутива, либо как предложили, настройка политик dbus
Можно, да. Только проблема в том что апстрим это чинить не спешит, тикеты там годами висят. Поэтому пока дойдёт до фикса, проще собрать свой маленький пакет с патчем и обновлять его вместе с системой
dbus-политики вариант норм, но иногда режут и нужные вещи. Тут уже каждый выбирает что ему больнее: жить с багом или подправить поведение под себя
apt mark-hold xfce4
Хотя любители тайловых менеджеров — особая раса
сверхлюдей, понять мотивы которых обывателю не дано, так что не буду даже пытаться.
Ничего сложного. Если у вас все окна всегда открыты на весь экран и повышенные требования к производительности и повышенная толерантность к сыроватому софту и повышенные требования к настраиваемости, то тайловые менеджеры — для вас.
В остальном, статья хорошая, но решение, мягко выражаясь, очень спорное. В первую очередь — конкретным приложениям не место в сердце управления питанием. Потому что завтра вы поменяете хромиум на бромиум и вся конструкция развалится. Не говоря о том, что вам теперь поддерживать этот патч.
Если приложение не умеет само отключать нужный функционал (кстати, хороший броузер умеет), то можно как-то отфильтровать такие вызовы на dbus.
Если приложение не умеет само отключать нужный функционал (кстати, хороший броузер умеет), то можно как-то отфильтровать такие вызовы на dbus.
Тогда вопрос архитектурному гуру: что будет когда ваш "хороший браузер" обновится и утеряет важную настройку, отвечающую за вопрос с питанием?
А это постоянно происходит и с хорошими браузерами и с плохими и даже с самими systemd и DBus, по той простой причине, что серьезная поддержка миграций конфигурации стоит чудовищных затрат и является проблемой даже в коммерческом софте, например в Windows.
Так что ваш совет безусловно идеологически правильный (можете вставить в резюме), но увы не жизнеспособный.
что будет когда ваш "хороший браузер" обновится и утеряет важную настройку, отвечающую за вопрос с питанием?
Тогда придётся фильтровать dbus вызовы. В любом случае эта странная конфигурация останется на этой странной машине
Так что ваш совет безусловно идеологически правильный (можете вставить в резюме), но увы не жизнеспособный.
Потеряв голову по волосам не плачут (с). Это ваш костыль ужасно выглядит и никому больше не подойдет. Говорю как чувак, что патчил 2 месяца ollama, чтобы она поддерживала мою видюху. Надоело очень быстро и выкинул её в топку решением, которое делает это из коробки.
Перепись оверинженегров. Просто в кроне проверяем заряд батареи и на Х% говорим shutdown +1
Даже не думал что wake lock в браузере стал такой проблемой
Как и Page Visibility API.
Задумывалось для того, чтобы веб-приложение могло корректно обработать событие "я не в фокусе". В реальности используется, например, YouTube, чтобы пользователи без платной подписки не могли слушать музыку на мобильных устройствах с выключенным экраном или переключившись на другое приложение.
Надеюсь для мобильных версий они до такой штуки не додумались? По крайней мере, если браузер в фоне, а не на первом плане.
У меня была похожая проблема где-то в начале лета. ChatGPT Электронный болван посоветовал отслеживать статус воспроизведения видео/аудио через Wire Plumber. Идея была проверена и доведена до рабочего решения в виде такого bash скрипта:
#!/bin/bash
IDLE_LIMIT_MS=900000 # 15 minutes
while true; do
idle_ms=$(xprintidle)
# if wpctl status | awk '/Streams:/,/Video/ {print}' | grep -B1 'playback_' | grep -q '\[active\]'; then
if wpctl status | grep 'playback' | grep '\[active\]'; then
echo "$(date): Audio playing, skip suspend"
sleep 60
continue
fi
if [ "$idle_ms" -gt "$IDLE_LIMIT_MS" ]; then
echo "$(date): Idle and no audio — suspending..."
systemctl suspend
fi
sleep 60
doneЕще понадобится xprintidle - он выводит число миллисекунд без активности пользователя. Раньше wpctl умел и видео отслеживать, но с каким-то апдейтом он то ли перестал это делать, то ли мне было лень разбираться, почему сломалось, поэтому я его закомментировал.
Получается, каждую минуту смотрим wpctl status, если проигрывается аудио, то ждем минуту и возвращаемся в начало цикла. Если аудио нет и вывод xprintidle больше чем 15 минут, то отправляем систему в сон, иначе ждем минуту, все.
Кладем этот скрипт, например, куда-нибудь в ~/.local/bin, добавляем в автозагрузку, да хоть в том же xfce при логине пользователя и пользуемся. Не надо ничего патчить и перекомпилировать, нет проблем с апдейтами, после окончания фильма сам уснет через 15 мин.
Может, я не уловил, в чем проблема, но почему просто не зайти на chrome://settings/content/idleDetection и не отключить эту опцию по умолчанию? Или это только в Chromium есть?
Во-первых как уже неоднократно упоминал: настройки часто слетают при обновлении,
во-вторых может быть запрос на самом сайте из серии "для продолжения работы пожалуйста включите опцию", как это происходит с веб-камерой и микрофоном.
Плюс такое поведение не у одного только Хрома и отучать все приложения - рука устанет.
1) Поискал по тексту статьи и комментам - все упоминания про проблемы при обновлении относятся к правкам в менеджере питания XFCE. При чем тут настройки Хрома, которые ну никак не должны слетать при обновлении?
2) Про это вообще не было разговора. Приведите пример такого сайта.
3) Сколькими браузерами вы постоянно пользуетесь на одном компьюетере? Я не знаю ни одного человека, кто использовал бы больше одного (фронтендщики на своих сайтах не в счет). Ну и даже отключение в 10 браузерах быстрее, чем то, что описано в статье. И не слетает при обновлениях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Chrome, Xfce и очень страшное кино