В мемориз:
Подборка полезный утилит и стандартов связанных с дисплеями: HDMI, DP:
К сожалению, свежие стандарты HDMI 2.0, 2.1 чувака заставили удалить из публичного доступа (почитайте письмо, которое ему написали).
Помимо этого есть спеки ITU/BT - там можно поискать коэффициенты RGB-YUV конвертаций для различных режимов (Rev.601 vs Rec.709 vs BT.2020, а вот про BT.2100 я уже не слышал) - бывает полезно (наипался, когда программировали матричный pCSC).
Офигенный раздел по кабелям и переходникам:
и его “продакшн” версия:
Так же раздел, для расчёта параметров монитора (например, DPI) по разрешению и диагонали:
В мемориз.
Предыстория: досталась Б/У “железная” дорога Tomica (японческий оригинал), а там оказался один локомотив, у которого два варианта управления:
- Пультом
- Свистком
Пульта, понятное дело, не нашлось. Изучая логотип свистка и помедитировав на картинки с этим локомотивом, где изображён этот самый свисток, сначала своим свистом попытался запустить, что через минут 15 удалось… Представьте себе картину маслом: сидит взрослый человек, и свистит на игрушечный тепловоз. Понравилось? :)
А потом решил поискать какой-то генератор тона, что бы более точно подобрать частоту.
Собственно в мемориз:
Проблема: при питании от батареи, время от времени не можем уйти в сон. После чего наблюдаем:
- фриз при вызове lspci
- фриз при попытке сделать sudo
- фриз при попытке перегрузиться или выключиться
- фриз при запуске sddm, если включаться на батарее
- 100% и стабильное воспроизведение при запуске
sudo powertop, и тоже фриз
Проблема: когда мы в ArchLinux и производных дистрибутивах обновляем ядро и если поменялась минорная цифра сменилась, то меняется и директория для модулей, а старая удаляется. В результате чего после обновления вы или сразу должны перезагрузиться с новым ядром или получать эпичные глюки: флешка там не примонтируется или ещё чего.
Очевидное решение: временно сохранить текущую диреторию для ядра. Почистить потом можно, на загрузке, к примеру.
Решение ниже - хуки для pacman, которое это делают.
На системах с ядром 5.10.4+ dmesg доступен только для root. Делаем его доступным и для группы wheel и, по необходимости, добавляем туда пользователей. К слову, если не уверены, лучше не делайте. Мне в dmesg нужно очень часто во время разработки лезть. Можно в терминале запускать сессию от другого пользователя без привилегий, но в группе wheel:
mkdir -p /etc/pacman/hooks
cat > /etc/pacman/hooks/10-dmesg-wheel-access.hook << EOF
[Trigger]
Operation = Upgrade
Type = Package
Target = util-linux
[Action]
Description = Allow dmesg wheel access...
When = PostTransaction
Exec = /bin/sh -c '/usr/bin/chown root:wheel /usr/bin/dmesg ; /usr/bin/chmod 750 /usr/bin/dmesg ; /usr/bin/setcap cap_syslog=ep /usr/bin/dmesg'
EOF
А оказывается, что почти всеми (скорее вообще всеми) LED, которые присутствуют на этом лаптопе можно управлять через sysfs:
$ ls /sys/devices/platform/thinkpad_acpi/leds/ -1
platform::micmute
platform::mute
tpacpi::kbd_backlight
tpacpi::lid_logo_dot
tpacpi::power
tpacpi::standby
tpacpi::thinklight
tpacpi::thinkvantage
Основные контрольные файлы:
brightness - собственно для включения или выключения: 0 - выключить. Максимальное значение зависит от следующего параметра.max_brightness - максимальное значение для предыдущего параметра. Если 1, то LED работает как On/Off. Если отличное, то поддерживается установка яркости: максимальное значение - максимальная яркость.trigger - можно задать системный триггер, который будет управлять этим LED. Типичный пример - активность жёсткого диска. Чтение из файла: список доступных триггеров и выбранный триггер, запись - назначение триггера.
Но вот я ни один LED не смог настроить на системный триггер disk-activity.
К слову, LED на крешке в букве i в Thinkpad:
/sys/devices/platform/thinkpad_acpi/leds/tpacpi::lid_logo_dot/
Проблема: просыпается при шевелинии мышкой Logitech MX Master, Unify receiver подключен в правый USB TypeA порт.
Старый метод через /proc/acpi/wakeup работает не для всех устройств:
cat /proc/acpi/wakeup | grep enabled | awk '{print($1)}' | grep -v 'SLPB\|LID' | while read line; do echo $line | sudo tee; done
Читаем:
Просканировать прочие устройства:
find /sys/devices -name 'wakeup' -a -type f | while read line; do sts=$(cat "$line"); echo "$line: $sts"; done | grep enabled
Сверяемся с выводом cat /proc/acpi/wakeup на предмет нужных устройств. К примеру, у меня:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/power/wakeup - LID
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/power/wakeup - SLPB
И выключаем:
find /sys/devices -name 'wakeup' -a -type f | grep -v 'PNP0C0D:00\|PNP0C0E:00' | while read line; do echo 'disabled' | sudo tee "$line"; done
Отражение состояния в /proc/acpi/wakeup тоже будет.
Но есть нюанс: устройствам может прилететь change и они могут опять включить этот источник пробуждения. Или /etc/rc.local вызваться в момент, когда ещё не все устройства проинициализированы.
Окончательное “лечение” проблемы: через udev, как по ссылке выше. Для себя я составил такой /etc/udev/rules.d/99-wakeup.rules:
ACTION!="add|change|bind", GOTO="wakeup_disable_end"
# Disable all by default
SUBSYSTEM=="*", ATTR{power/wakeup}=="*", ATTR{power/wakeup}="disabled"
# Enable for selected:
# LID
# /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00
#DEVPATH=="/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00", ATTR{power/wakeup}="enabled"
KERNEL=="PNP0C0D:00", ATTR{power/wakeup}="enabled"
# SLPB
# cat /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/uevent
#DEVPATH=="/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00", ATTR{power/wakeup}="enabled"
KERNEL=="PNP0C0E:00", ATTR{power/wakeup}="enabled"
LABEL="wakeup_disable_end"
Краткое пояснение:
- Реагируем только на действия
add, change, bind
- По умолчанию, для все подсистем, у которых есть атрибут
power/wakeup выставляем его в disable
- После чего, включаем только нужные источники пробуждения, у меня это LID и SLPB/WakeUp button.
Далее варианты:
- Перегрузиться - самый простой
- Вручную перегрузить правила (
sudo udevadm control -R) и стригерить каждое устройство:
sudo udevadm trigger /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00
- Так же перечитать правила и вызвать однострочник выше, а если уж прилетит change action, то уже отработается правилами udev.
В общем, какой удобнее - тот и использовать.
16.03.2016, Жека, помним.
Проблема: VLC при попытке проиграть видео падает:
libva error: /usr/lib/dri/i965_drv_video.so init failed
[00007f437c007840] glconv_vaapi_x11 gl error: vaInitialize: unknown libva error
libva error: /usr/lib/dri/i965_drv_video.so init failed
[00007f437c007840] glconv_vaapi_drm gl error: vaInitialize: unknown libva error
libva error: /usr/lib/dri/i965_drv_video.so init failed
[00007f437c007840] glconv_vaapi_drm gl error: vaInitialize: unknown libva error
А vdpauinfo говорит:
libva error: /usr/lib/dri/i965_drv_video.so init failed
И рапортует, что не поддерживает ничего.
Решение: поставить новый драйвер от Intel и не забыть бридж VA-API → VDPAU:
sudo pacman -S intel-media-driver libvdpau-va-gl
Старый libva-intel-driver работал для графики на T530, но тут уже нет. В целом, наверное, его можно удалить.
После установки успешно отрабатывает и VLC, vdpauinfo и vainfo.
Для надёжности, наверное, стоит ещё задать:
# VA API (Firefox)
export LIBVA_DRIVER_NAME=iHD
# VDPAU
export VDPAU_DRIVER=va_gl
К слову, vainfo рапортует много больше возможностей по декодированию, по сравнению с vdpauinfo. Вики Debian
говорит что он действительно более ограничен, но иногда (не наш случай), это единственный вариант. В общем, с учётом того, что тот же Firefox для аппаратного декодирования использует VAAPI и что последний более богат - это не может не радовать.
Для дополнительного чтения:
…ну и росы %)
Наконец-то получилось пройти этот маршрут. До этого в разное время года по разным причинам мне этого сделать не удавалось.
