В субботу был запланирован пешкодрапинг в окрестностях Владивостока, в целях самоизоляции и ограничения социальных контактов посредством транспортировки своей тушки в лес, подальше от этого самого социума и неблагополучной эпидемиологической обстановки в городе. Кроме того, в планах стояла задача государственной важности в части борьбы с треклятым вирусом, путём проведения опытов над людьми (Женевская конвенция? Не, не слышал!) в части стимуляции иммунной системы нечеловеческими (даже живодёрскими) методами, а именно:
- насильственным вдыханием свежего воздуха;
- непомерными нагрузками на двигательный аппарат, сердечно-сосудистую и дыхательные системы;
- стимуляции и манипуляции психикой при помощи созерцания жутких картин живописных видов, буйства дикой природы.
Программа экспериментов открыта и допускается к расширению в полевых условиях.
Число. Подпись.
Изучал
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, то он:
- сам не загрузится (это так на практике) и
- что бы
xlnx_snd_probe() что-то нашла, через него нужно пропустить ВСЕ platform_device… но не всех же платформенных устройств в platform_data вообще именно этот тип данных будет!
Второе оказывается не так. Это “виртуальный” драйвер, а другой,
реальный для этого устройства, вызовом функции
platform_device_register_resndata() собственно создаёт platform_device, и в качестве второго аргумента оно принимает имя, по которому будет отфильтровываться, какому драйверу оно может быть передано. В данном случае “xlnx_snd_card”. И этот же вызов регистрирует pdev->dev.platform_data, в нужном для целевого драйвера виде.
А уже матчинг подходящего платформенного драйвера для вновь созданного платформенного устройства будет происходить здесь:
platform_match(). В данном случае - по имени устройства и по имени драйвера.
Тяжело идёт.
PS разные верии ядра роли не играют.
Суть проблемы, если коротко, в том, что подключая внешний монитор к ноутбуку в том случае, если он логически расширяет экран влево (находится левее основного экрана), то все открытые окна с экрана ноутбука перемещается на вновь подключенный экран.
Вообще, проблема актуальна не только для ноутбука, но частое подключение и отключение мониторов более присуще именно ноутбукам.
Решения проблемы не существует на данный момент. Ну… или я его не нашёл. Но буквально сегодня разыскал занимательный хак, как вернуть окна, если они прыгнули на левый (в прямом и переносном смысле) монитор:
Под катом сохраню копию, на всякий случай. Вообще, как грубое решение в лоб работает. Повесил на горячую клавишу 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 со следующим содержимым:
И пробуем:
$ 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
Ура!
Выводы
Только два:
- При обновлении системы убрали дефолтный
/etc/mdns.allow. Но пакеты, где бы он мог находиться в последнее время не обновлялись.
- Изменились настройки сети провайдера
Собственно, скорее всего пункт 2.
Небольшой хинт:
Если в двух словах:
- делаем альбом и генерируем ссылку на него
- открываем её из другого браузера, где вы не залогинены. Можно в режиме инкогнито - тоже пойдёт.
- копируем ссылку и пользуемся
В конце ссылки есть “=w1236-h825” - это размер. Можно скорректировать под свои нужды. Если заменить на “=d” - скачаем оригинальную картинку (оригинальный размер).
Посмотрим, как работать будет :)
UPD: проблема в том, что при вставке большого числа изображений на страницу, не все будут открываться. Гугл будет ругаться на слишком частые обращения.
UPD: ну и небольшие дополнительные утилиты:
Немного фотографий:
Просто немного фотографий:
Небольшой хинт по настройке автодополнения адресов из адресной книги LDAP в Thunderbird:
Если коротко, в расширенных настройках создать строковое свойство:
ldap_2.servers.[ADDRESSBOOK].autoComplete.filterTemplate
Где [ADDRESSBOOK] - индивидуально для каждой книги.
со значением примерно такого вида:
(|(mozillaNickname=%v*)(cn=%v*)(sn=%v*)(mail=%v*)(displayName=%v*))
Проблема:
- Этот фильтр не работает в адресной книге
- Фильтр вообще не работает в диалоге приглашения в Календаре
- Если что-то начинается со
*, то нужно вводить как \*
Более подробно: не получается слинковать только при указании свойства caps у appsink или вставки между
videoconvert и
appsink фильтра
capsfilter с нужным форматом. Но об этом подробнее под катом.
