Изучал https://github.com/Xilinx/linux-xlnx/blob/xlnx_rebase_v4.19/sound/soc/xilinx/xlnx_pl_snd_card.c

Конкретно функцию xlnx_snd_probe() и не мог понять… Как в pdev->dev.platform_data оказываются нужные ноды, в нужной последовательности (сначала PLAYBACK, потом CAPTURE), причём, если PLAYBACK нет, то там будет NULL.

Так как у драйвера нет of_match_table, то он:

1. сам не загрузится (это так на практике) и
2. что бы xlnx_snd_probe() что-то нашла, через него нужно пропустить ВСЕ platform_device… но не всех же платформенных устройств в platform_data вообще именно этот тип данных будет!

Второе оказывается не так. Это “виртуальный” драйвер, а другой, реальный для этого устройства, вызовом функции platform_device_register_resndata() собственно создаёт platform_device, и в качестве второго аргумента оно принимает имя, по которому будет отфильтровываться, какому драйверу оно может быть передано. В данном случае “xlnx_snd_card”. И этот же вызов регистрирует pdev->dev.platform_data, в нужном для целевого драйвера виде.

А уже матчинг подходящего платформенного драйвера для вновь созданного платформенного устройства будет происходить здесь: platform_match(). В данном случае - по имени устройства и по имени драйвера.

Тяжело идёт.

PS разные верии ядра роли не играют.

Суть проблемы, если коротко, в том, что подключая внешний монитор к ноутбуку в том случае, если он логически расширяет экран влево (находится левее основного экрана), то все открытые окна с экрана ноутбука перемещается на вновь подключенный экран.

Вообще, проблема актуальна не только для ноутбука, но частое подключение и отключение мониторов более присуще именно ноутбукам.

Решения проблемы не существует на данный момент. Ну… или я его не нашёл. Но буквально сегодня разыскал занимательный хак, как вернуть окна, если они прыгнули на левый (в прямом и переносном смысле) монитор:

• Shell script to force all your windows to your your primary display (useful for people with a secondary monitor to the LEFT of their primary)

Под катом сохраню копию, на всякий случай. Вообще, как грубое решение в лоб работает. Повесил на горячую клавишу Super+P.

Так получилось, что поймали акционные билеты до Петропавловска, на троих человек - около 22 тыр. Глядя на цену сразу мысль - надо брать!

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

Все фото можно посмотреть в галерее на Google Photo.

В один прекрасный момент, на ровном месте перестал работать mDNS и перестали резолвится хосты в зоне .local.

При этом демон Avahi был запущен, сервис systemd-resolved остановлен и в /etc/nsswitch.conf всё в порядке (присутствуют mdns4_minimal и mdns4, в общем, всё как в ArchWiki).

Более того, вызов:

avahi-resolve -n 35002201.local

завершается успешно и возвращает адрес хоста.

Исследование привело к команде getent. Вызов:

getent hosts 35002201.local

выдал пустой результат. Хмм… как говорит документация, эта утилита точно работает через NSS.

Что делает пытливый ум линуксоида в таком случае? Правильно! Запускает команду через strace (я убрал лишний вывод, оставил только суть):

$ LANG=C strace -f getent hosts 35002201.local
execve("/usr/bin/getent", ["getent", "hosts", "35002201.local"], 0x7ffef387b638 /* 98 vars */) = 0
brk(NULL)                               = 0x5618ad268000
...
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=372, ...}) = 0
read(3, "# Name Service Switch configurat"..., 4096) = 372
read(3, "", 4096)                       = 0
close(3)                                = 0
...
openat(AT_FDCWD, "/usr/lib/libnss_mdns4_minimal.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \20\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=18104, ...}) = 0
mmap(NULL, 20496, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2bef77a000
mmap(0x7f2bef77b000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f2bef77b000
mmap(0x7f2bef77d000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f2bef77d000
mmap(0x7f2bef77e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f2bef77e000
close(3)                                = 0
...
openat(AT_FDCWD, "/etc/mdns.allow", O_RDONLY) = -1 ENOENT (No such file or directory)
...
exit_group(2)                           = ?
+++ exited with 2 +++

Хмм… А что это за файл /etc/mdns.allow, который во моей системе отсутствует? Читаем и видим, что рекомендованная конфигурация - это отсутствие этого файла. Всё как у меня. Тогда, выполняется некоторая эвристика:

• Если запрос не заканчивается на .local. или .local, он отклоняется
• Если в запросе есть точка (появяляется домент третьего уровня, например foo.bar.local), то он тоже отклоняется
• Если системный unicast DNS (если проще: обычный DNS, работающий через 53 порт), указанный в /etc/resolv.conf отдаёт SOA запись для local, запрос тоже отклоняется. Иными словами, запрос отклоняется, если запрос host -t SOA local верунл что-то отличное от Host local not found: 3(NXDOMAIN).

Хм, а вот третий пункт уже интересней. Вводим команду и видим:

$ host -t SOA local
local has SOA record ns1.inetvl.ru. support.inetvl.ru. 2017062801 28800 3600 1209600 86400

Оппа… Создаём файл /etc/mdns.allow со следующим содержимым:

.local.
.local

И пробуем:

$ getent hosts 35002201.local
192.168.101.2   35002201.local

$ ping 35002201.local
PING 35002201.local (192.168.101.2) 56(84) bytes of data.
64 bytes from 35002201.local (192.168.101.2): icmp_seq=1 ttl=64 time=0.216 ms
64 bytes from 35002201.local (192.168.101.2): icmp_seq=2 ttl=64 time=0.271 ms
64 bytes from 35002201.local (192.168.101.2): icmp_seq=3 ttl=64 time=0.247 ms
^C
--- 35002201.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2029ms
rtt min/avg/max/mdev = 0.216/0.244/0.271/0.022 ms

Ура!

Выводы

Только два:

1. При обновлении системы убрали дефолтный /etc/mdns.allow. Но пакеты, где бы он мог находиться в последнее время не обновлялись.
2. Изменились настройки сети провайдера

Собственно, скорее всего пункт 2.

Небольшой хинт:

• https://support.google.com/photos/thread/9590592?hl=en&msgid=9603023

Если в двух словах:

1. делаем альбом и генерируем ссылку на него
2. открываем её из другого браузера, где вы не залогинены. Можно в режиме инкогнито - тоже пойдёт.
3. копируем ссылку и пользуемся

В конце ссылки есть “=w1236-h825” - это размер. Можно скорректировать под свои нужды. Если заменить на “=d” - скачаем оригинальную картинку (оригинальный размер).

Посмотрим, как работать будет :)

UPD: проблема в том, что при вставке большого числа изображений на страницу, не все будут открываться. Гугл будет ругаться на слишком частые обращения.

UPD: ну и небольшие дополнительные утилиты:

• https://www.publicalbum.org/blog/embedding-google-photos-albums - встроить весь альбом в страницу
• https://www.publicalbum.org/blog/embedding-google-photos-image - автоматически получить ссылку на фото. Отмечу, что даже одно фото гугл шарит как анонимный альбом с единственной картинкой.

Немного фотографий:

• https://photos.app.goo.gl/guFiJJQ2dVHdi9ni7

Просто немного фотографий:

• https://photos.app.goo.gl/PBWiq8HZrGhjWUa87

Небольшой хинт по настройке автодополнения адресов из адресной книги LDAP в Thunderbird:

• https://www.aligrant.com/web/blog/2013-08-05_thunderbird_ldap_autocomplete
• https://www.tf.uni-kiel.de/itg/en/services/email/ldap-address-book-pdf-eng, страница 3 в самом конце

Если коротко, в расширенных настройках создать строковое свойство:

ldap_2.servers.[ADDRESSBOOK].autoComplete.filterTemplate

Где [ADDRESSBOOK] - индивидуально для каждой книги.

со значением примерно такого вида:

(|(mozillaNickname=%v*)(cn=%v*)(sn=%v*)(mail=%v*)(displayName=%v*))

Проблема:

1. Этот фильтр не работает в адресной книге
2. Фильтр вообще не работает в диалоге приглашения в Календаре
3. Если что-то начинается со *, то нужно вводить как \*

Более подробно: не получается слинковать только при указании свойства caps у appsink или вставки между videoconvert и appsink фильтра capsfilter с нужным форматом. Но об этом подробнее под катом.

Кросс-компиляция в Meson достаточно проста. Выполняется, как и в CMake при помощи вспомогательного файла:

[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'aarch64'
endian = 'little'

[binaries]
c = 'aarch64-linux-gnu-gcc'
cpp = 'aarch64-linux-gnu-g++'
#ld = 'gold'
ar = 'aarch64-linux-gnu-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'pkg-config'
#exe_wrapper = 'wine' # A command used to run generated executables.

[properties]
c_args = ['-DCROSS=1', '-DSOMETHING=3']
c_link_args = ['-some_link_arg']
sys_root = '/some/path'

Сохраняем его под именем cross-build.ini и передаём meson:

mkdir build
cd build
meson --cross-file ../cross-build.ini ..

Стоит отметить, что meson ОЧЕНЬ чувствителен к значениям переменных типа CC ,CXX и LD. Он рассчитывает, что если они установлены, то они отсылают к компилятору, который генерирует код для билд-машины, иными словами - нативный код. Это актуально для среды LTIB, которая настраивает окружение таким образом, что эти переменные окружения ссылаются на кросс-компилятор. Для случая autotools и большинства случаев использования CMake - это нормально. А вот Meson может сломаться.

Ещё одной особенностью является задание линкёра - ld = xxx. Он не задаёт конкретный бинарник, а отсылает к типу: gold (бинарник ld.gold или аналогичный), bsf (ld.bsf или аналогичный). Я задал его некорректно изначально, и только запуск Meson под strace позволил выяснить причину его недовольства.

Небольшое введение.

Есть два поведения для большого количества вкладок:

• Путь Google Chrome и производных: максимально сжимаем вкладки (правда потом они не отображаются и приходится неочевидным способом прокручивать колесиком мыши или горячими клавишами):

• Путь Firefox: заполнять вкладками всё пространство, как будет занято, начинать их сжимать, если размер достигнут какого-то минимального значения, включать полосу прокрутки плюс добавляется выпадающий список:

Моё мнение, что прокрутка стимулирует создавать ещё больше вкладок, а так как с моей личной организованностью в этом плане дела обстоят не очень хорошо, то мне нужен внешний стимул, что бы заняться чисткой открытых страниц. Отсутствие визуального различия во вкладках (сильно налеплены) - хороший стимул в этом.

Корабль [космический] такое место, где любая потерянная вещь рано или поздно находится. Но это обычно не радует.

– Шумил Павел, “Три, четыре, пять, я иду искать”, цикл Окно контакта

PS а порекомендуйте годной космофантастики?

Буквально сегодня состоялся разговор по поводу того, что на GitLab Pages нет возможности автоматически обновлять сертификаты Let’s Encrypt (которые протухают каждые 90 дней) и что данная возможность есть на GitHub Pages.

Кроме того, сегодня как раз подошла череда обновления сертификата, заодно что-то меня потянуло поглядеть статью в документации GitLab по настройке интеграции с Let’s Encrypt: Let’s Encrypt for GitLab Pages

И что же я там вижу:

Let’s Encrypt for GitLab Pages (manual process, deprecated)

Warning: This method is still valid but was deprecated in favor of the Let’s Encrypt integration introduced in GitLab 12.1.

Воу! С радостным предчувствием иду по указанной ссылке и таки да, они завезли автообновление сертификатов!

Но если интересно, как это было сделано вручную, добро пожаловать под кат.

Очень полезный ресурс от Андрея Пономаренко (тыц, тыц) как для разработчиков библиотек, так и для маинтейнеров разного рода софта. Позволяет мониторить изменения в API/ABI интерфейсах библиотек:

• https://abi-laboratory.pro/

Вообще функционал ресурса достаточно богат и интересен:

• можно помониторить список C/C++ библитек на предмет изменений в API/ABI (инструмент ABI Tracker)
• можно поискать неизвестный символ (в т.ч. в “mangled” виде) при помощи инструмента ABI Navigator
• для разработчиков модулей ядра Linux может показаться интересным инструмент Linux ABI
• ну и схожий инструмент для Windows API

Все доступные инструменты можно глянуть на странице Reports.

Инструменты, используемые для анализа можно изучить на странице Open Source. При помощи оных вполне можно организовать мониторинг изменений для вашего проекта или библиотеки.

С удивлением для себя обнаружил, что Homebrew, который использовал несколько раз для установки пакетов и сборки/портирования софта на macOS, вполне себе может использоваться и на Linux и даже в среде WSL на Windows:

• https://docs.brew.sh/Homebrew-on-Linux

В целом неплохо, но:

1. это ещё один шаг к dependency hell
2. нет возможности (если есть - поправьте) зафиксировать версию/срез репозитория

Второй пункт особенно полезен для создания воспроизводимых окружений для сборки софта с последующей дистрибуцией. В этом отношении MXE даёт фору: там попросту можно восстановить окружение используя номер коммита GIT.

Ну и для Windows я бы предпочёл окружение MSYS2 с pacman в качестве пакетного менеджера.

Но, оно может оказаться полезным для установки более свежего софта без прав администратора с возможностью быстро откатиться (просто удалить директорию с установленным барахлом) на всяких LTS дистрибутивах.