Как обычно, на первые выходные октября собрал группу на мой традиционный выход. Правда традиция оказалась больше традицией для меня, но всё же: назвался груздем - полезай в кузов, или: назвал традицией - чти :)

Потребовалось сделать в приложении анонсирование и поиск себе подобных. Причём без завязки на системный Avahi.

Выбор пал на три реализации mDNS/DNS-SD:

• mDNSResponder
• libmicrodns
• и mdns

Первый отбросил из рассмотрения, так как показался слишком переусложнённым. Потом пошёл смотреть на libmicrodns - получилось собрать прототип очень быстро - мало кода. Но… жирный крест поставило то, что они до сих пор не исправили косяк, что нужно JOIN TO GROUP делать. Без этого анонсирование работает нормально, а вот запросы/поиск будет только на неком дефолтном, первом интерфейсе.

Пошёл на mdns. Для интеграции нужно больше кода, но почти весь можно как есть взять из примера mdns.c, библиотека без внутренних аллокаций. И очень неплохо дружится с внешними event-loop’ами, будь то libev или asio.

В общем, мой выбор - mdns.

А под катом - небольшая табличка сравнительная. Жирным - критерий преобладающий над соперником. Если ничто не выделено - нет приоритета.

Короткая заметка и ссылки. Возможно потом дополню информацией о разрешении (resolution) временных меток.

• FAT/FAT32
  • Хранит локальное время, без указания Timezone. Поменяешь в системе зону - время создания файлов останется без изменений. Т.е. нужно помнить в какой ТЗ они создавались.
  • Windows сохраняет вот прям вот локальное время
  • Linux добавляет час, при переводе часов
  • timestamp:
    • дата 16 битное число: 7 бит - год, 4 бита - месяца, 5 бит - день. Год в диапазоне 1980-2107.
    • время 16 битное число для часов, минут, секунд
• exFAT:
  • Время хранится локальное. Но есть нюанс.
  • Временная зона хранится в 1 байте. Vista SP1 не использует его. Что бы нормально жилось, старший бит сигнализирует - применять или нет смещение зоны. 0 - не применять. 1 - применять. Остальные 7 бит - 15минутные интервалы для смещения. Положительное направление - на восток.
  • Т.е. если бит 7 в TZ поднят, то система будет пересчитывать время файла в UTC, что бы корректно отобразить в системе при смене часового пояса. Эдакая обратная совместимость.
• NTFS
  • Время хранится в UTC
• EXTx (EXT2/3/4)
  • Время хранится в UTC

Это логическое продолжение этого с учётом нововвидений по добавлению файлов.

Весь “код” разместил на 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… Да был когда-то такой.

Ставится:

sudo pacman -S asp

Получить PKGBUILD:

asp checkout PKGNAME

или:

asp export PKGNAME

Например:

asp checkout kdiff3

Далее работам как обычно с PKGBUILD: makepkg с полезными опциями. Сам спек правим по необходимости.

На чистом Arch Linux ещё есть пакет devtools, который содержит тул pkgctl, который позволяет достичь той же цели: получить PKGBUILD для сборки:

pkgctl repo clone PKGNAME

На производных, типа Manjaro (мой случай) этого тула может не быть. А вот asp - есть.

Полезные ссылки:

1. 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;
}

В мемориз:

• https://glenwing.github.io/
  • https://github.com/Glenwing/glenwing.github.io - репозиторий сайта: можно запустить локально хоть через встроенный в Python WEB сервер: python -m http.server 9000

Подборка полезный утилит и стандартов связанных с дисплеями: HDMI, DP:

• https://glenwing.github.io/docs/

К сожалению, свежие стандарты HDMI 2.0, 2.1 чувака заставили удалить из публичного доступа (почитайте письмо, которое ему написали).

Помимо этого есть спеки ITU/BT - там можно поискать коэффициенты RGB-YUV конвертаций для различных режимов (Rev.601 vs Rec.709 vs BT.2020, а вот про BT.2100 я уже не слышал) - бывает полезно (наипался, когда программировали матричный pCSC).

Офигенный раздел по кабелям и переходникам:

• https://glenwing.github.io/adapters/

и его “продакшн” версия:

• https://linustechtips.com/topic/729232-guide-to-display-cables-adapters-v2/

Так же раздел, для расчёта параметров монитора (например, DPI) по разрешению и диагонали:

• https://glenwing.github.io/diu/

В мемориз.

Предыстория: досталась Б/У “железная” дорога Tomica (японческий оригинал), а там оказался один локомотив, у которого два варианта управления:

1. Пультом
2. Свистком

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

А потом решил поискать какой-то генератор тона, что бы более точно подобрать частоту.

Собственно в мемориз:

• Online Tone Generator

Проблема: при питании от батареи, время от времени не можем уйти в сон. После чего наблюдаем:

• фриз при вызове 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

Читаем:

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

Просканировать прочие устройства:

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"

Краткое пояснение:

1. Реагируем только на действия add, change, bind
2. По умолчанию, для все подсистем, у которых есть атрибут power/wakeup выставляем его в disable
3. После чего, включаем только нужные источники пробуждения, у меня это LID и SLPB/WakeUp button.

Далее варианты:

1. Перегрузиться - самый простой
2. Вручную перегрузить правила (sudo udevadm control -R) и стригерить каждое устройство:

   sudo udevadm trigger /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00
   

3. Так же перечитать правила и вызвать однострочник выше, а если уж прилетит change action, то уже отработается правилами udev.

В общем, какой удобнее - тот и использовать.