Это логическое продолжение
этого с учётом
нововвидений по добавлению файлов.
Весь “код” разместил на GitHub:
qtc-other-files-helper. Там же есть и детальное описание.
Тезисно:
- Так же используем вспомогательный файл
- Так же используем кастомный таргет
- Но уже не сканируем дерево: отдаём на откуп пользователю, что добавить, что убрать. Что бы не конфликтовать с существующими файлами.
- Не используется
CMAKE_TOOLCHAIN_FILE, вместо него - CMAKE_PROJECT_INCLUDE.
- Доработано решение для использования как на уровне per-project, так и глобально, на уровне Kit. Но бросить файлик второй в директорию с проектом всё равно нужно будет.
Из косяков:
- При добавлении файлов, QtC стремиться создать новую запись
target_sources() в CMakeLists.txt верхнего уровня. Приходится вручную вырезать и вставлять в qtc-other-files.cmake
Ну и в старом способе была проблема, что эти файлы попадали в кодовую модель и мешали парсеру. Детально не разбирался в новых реалиях.
На выходных, 22-23 июня 2023, отлично прогулялись с сыном по двум водопадам у подножия хр.Большой Воробей: Березняк и Маруськины слёзы.
Как обычно в мемориз.
Раньше был тул abs, потом вся структура мигрировала на Git. Теперь что бы получить пакет нужен тул
Arch Build Source Management Toolили коротко - asp. Не путать с
ASPLinux… Да был когда-то такой.
Ставится:
Получить PKGBUILD:
или:
Например:
Далее работам как обычно с PKGBUILD: makepkg с полезными опциями. Сам спек правим по необходимости.
На чистом Arch Linux ещё есть пакет
devtools, который содержит тул pkgctl, который позволяет достичь той же цели: получить PKGBUILD для сборки:
pkgctl repo clone PKGNAME
На производных, типа Manjaro (мой случай) этого тула может не быть. А вот
asp -
есть.
Полезные ссылки:
-
Arch Build System
Итак, обновляю свой
CMakeProjectManager2 и что я вижу:
71eb0ab9f8e98df9bd021c1c49d7ec00a66492cb - завезли парсер CMake в стоковый плагин.d41365610ff80478d8c6c2812299d95d139561ec - его интегрировали в билд.d8be2491a5f5cfdc512f63c766a550dd43694063 / 13 апреля 2023 - реализовали добавление новых и существующих файлов к таргету, причём файл пытается добавляться прямо в CMakeLists.txt: файл будет добавлен последним элементов к соответствующей “well-known” функции (они захардкожены) типа add_executable(), add_library(), qt_add_executable(), qt_add_library(), qt6_add_executable(), qt6_add_library(). Для кастомных функций будет добавлен вызов target_sources(), что тоже неплохо. Уже можно начинать пользоваться.039baab6e70160bc8130ef95e499141f7c875225 / 20 апреля 2023 - реализовали вышеперечисленное для QtQuick проектов, в список “well-known” функций добавились: qt_add_qml_module(), qt6_add_qml_module()54af6bd5b3f5ba5e3396f5cb9eb539f198abafff / 21 апреля 2023 - разрешили переименовывать файлы. Работает как для явно указанных файлов, так и для добавленных через file(GLOB|GLOB_RECOURSE).411b2e05b8ac4442d1ef179381dc7c37492ab37b / 24 апреля 2023 - разрешили удалять файлы.5c2b2966e78129dcbd220e35e15f6278a1b3d05d / 27 апреля 2023 - разрешили добавлять существующую директорию. Пока, как я понял, добавляются все файлы, а не add_subdirectory(). Что, по мне, более логично: все операции target-ориентированные.874b1133d9cfaef179851aa925b7d6b96e85019b / 26 апреля 2023 - пофиксили удаление и переименование, что бы оно срабатывало и с файлами, которые указываются через переменные для таргета.
Ну и пачка мелких фиксов.
На текущий момент, меня огорчает отсутствие вывода всех файлов их проектной директории (например, README.md или скрипты вспомогательные, которые вполне можно редактировать в QtC), но уже можно начинать пытаться нормально работать.
Собственно в рамках CMakeProjectManager2 я теперь попытаюсь реализовать возможность отобразить всех файлов, по аналогии с текущей реализацией и подключить добавление файлов из апстрима.
А вообще, тенденция к тому, что CMakeProjectManager2 можно будет выкинуть меня радует!
Сегодня мне не хватило такого (C++20):
for (std::tie(m_imageWidth, m_imageHeigth) : sizes) {}
Пришлось так:
for (auto const &size : sizes) {
std::tie(m_imageWidth, m_imageHeigth) = size;
}
В мемориз:
Подборка полезный утилит и стандартов связанных с дисплеями: 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 и что последний более богат - это не может не радовать.
Для дополнительного чтения:
…ну и росы %)
Наконец-то получилось пройти этот маршрут. До этого в разное время года по разным причинам мне этого сделать не удавалось.
