Сылка:

• https://packages.debian.org/sid/x11/xserver-xorg-video-intel

Цитата:

Пакет: xserver-xorg-video-intel (2:2.99.917+git20171229-1 и другие) … Не рекомендуется использование данного драйвера с видеокартами, выпущенными позднее 2007 года: вместо этого удалите его, и графический сервер будет использовать встроенный драйвер установки режимов.

Не рекомендуется.

Замена: Xorg драйвер modesetting, встроенный драйвер, работающий со всеми KMS совместимыми драйверами в ядре.

По мотивам:

• https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/

При этом мнения по поводу адекватности замены расходятся (на правах заметок по разным источникам из сети):

• По данным тестов Phoronix, ускорение Glamor существенно проигрывает SNA от Intel в производительности и примерно сопоставимо с UXA в части 2D. При этом единогласно сходятся, что SNA до сих пор глючная и бажная, а путь современных графических библиотек в использование 3D:
  • Intel 2D GLAMOR vs. UXA vs. SNA On Ubuntu 14.04
  • Intel vs. Modesetting X.Org DDX Performance Impact
• Нашёл ровно одно утверждения без подтверждения фактами, что Glamor может выедать больше батарейки (кстати, этот режим ускорения можно включить и в драйвере Intel). Реальных сравнений у меня нет.
• Стабильность и реальная скорость обоих драйверов (и трёх вариантов ускорения на драйвере Intel) разнится от железки к железке.
• Исправлений для старых карт в драйвере Intel почти нет, хотя и рекомендуется к использованию как раз для старых карт.

Ссылки:

• https://wiki.gentoo.org/wiki/Intel
  • Тут хорошая табличка по поколениям графики и соответствующим архитектурам. Ivy Bridge, это HD4000 и Gen7. Debian рекомендует modesetting новее 2007 года, Gentoo говорит более конкретно (по ссылке выше): Gen 4+.

Будет пополняться. В контексте изучения проблемы:

• https://community.spiceworks.com/topic/152058-what-causes-a-laptop-to-turn-on-then-turn-off-again
  • перегрева нет
  • батарея не влияет
• https://bugzilla.kernel.org/show_bug.cgi?id=109051

CPU

• Кладезь: https://wiki.archlinux.org/index.php/Stress_Test
  • stress - есть в репозиториях

GPU

• https://www.pcsuggest.com/gpu-benchmarking-and-stress-testing-in-linux/
  • glxgears
  • glmark2
  • furmark из комплекта GpuTest

Наблюдения

К слову сказать, пока никаких реакций на стресс система не даёт. Судя по всему проблемы в интегрированном видео от Intel и не способностью правильно ходить между стейтами энергопотребления (pstates). Т.е. возможно нужно генерировать переменную нагрузку на видеоподсистему, что бы добиться воспроизведения проблемы.

В первую очередь для рабочего стола, не для WEB.

На текущий момент мне понравилось три решения, которые могут работать с отдельными файлами без создания проектов и так далее:

• PlantUML QEditor
• Расширение для Visual Studio Code - PlantUML
• Плагин для NetBeans

В первом не хватает подсветки синтаксиса. Третий достаточно тяжеловат (всё же сам NetBeans сам по себе - IDE), так что второй вариант - пока мой выбор. Раньше Visual Studio Code не использовал, и сейчас он больше для редактирования PlatnUML с предпросмотром, но со своими задачами справляется достойно. Не хватает, правда, Assistant, как в PlantUML QEditor.

PS в IDEA есть достаточно удобный плагин, особенно если в рамках проекта нужно диаграммы думать. Мне же больше по душе запуск без IDE проекта, дабы не отвлекаться. PPS для WEB: www.plantuml.com/plantuml/form быстро сгенерить или посмотреть.

На два канала:

ffmpeg -f lavfi -i "sine=f=1000:sample_rate=48000" -filter_complex "[0][0]amerge" -c:a pcm_s24le -f alsa "hw:1,0"

для увеличения: добавляем [0] перед amerge

Можно генерировать и разные синусы по кадому каналу, просто увеличиваем число lavfi входов:

ffmpeg -f lavfi -i "sine=f=1000:sample_rate=48000" <br/>
       -f lavfi -i "sine=f=400:sample_rate=48000" 
       --filter_complex "[0][1]amerge" <br/>
       --c:a pcm_s24le -f alsa "hw:1,0"

и не забываем в этом случае менять номера входов для amerge

Как-то пропустил сей момент, но в PlantUML появились Временные диаграммы (Timing Diagram):

• http://plantuml.com/timing-diagram

Жаль, что когда они были ооооочень нужны (сейчас не так), удобного инструмента я не нашёл.

Возникает путаница иногда что где и когда. Коротко:

1. USB 3.0 == USB 3.1 Gen1 (SuperSpeed), скорость до 5 ГБит/с. По сути - ребрендинг и переименование.
2. USB 3.1 == USB 3.1 Gen2 (SuperSpeed+), скорость до 10 ГБит/с.

По поводу коннектора Type-C: его появление связывают с появлением USB 3.1 Gen2. Но! Этим коннектором вполне может быть осуществлено подключение в устройствах, которые поддерживают только USB 3.1 Gen1, USB 2.x или даже USB 1.x (для 1.x и 2.x используются одинаковые дифпары независимые от режима 3.x). Иными словами, наличие Type-C коннектора не говорит о поддержки USB 3.1 Gen2, особенно, когда данный разъём используется на устройстве, а не на хосте, хотя в последнем случае тоже нужно проверять внимательно спеки на материнку или лаптоп.

По поводу коннектора Type-A: провода для USB 3.1 Gen2 никак не изменились, поэтому применение коннектора Type-A вполне себе возможно на хостах. Правда в текущем виде обычно наблюдается такая картина:

1. чёрные коннекторы - USB 2.x
2. синие коннекторы - USB 3.1 Gen1
3. Type-C коннекторы - USB 3.1 Gen2

Но есть платы расширения, которые использую коннектор Type-A для USB 3.1. Gen2. Т.е. снова - нужно смотреть спецификации.

Вообще, появление Type-C это очень хорошая работа над ошибками для устранения идиотских варианта Micro Type-B (Micro-B, Mini-B выполнен вполне сносно) в варианте USB 3.1 Gen1: они отличаются большими габаритами и низкой механической прочностью:

Правда установка данного типа коннектора на хост… Мне не по душе. Да, решаются две проблемы:

1. симметричность кабеля с обеих сторон: можно подключать устройство как к хосту, так и к другому устройству, если поддерживается OTG и использовать для этого один кабель,
2. симметричность самого коннектора как такового, но вот его прочность (хоть маркетинговый булшит вещает иначе) значительно ниже Type-A.

Моё мнение (на которое всем, ессесно, пофиг):

1. Type-A - оставить для хоста
2. Type-B - оставить для устройств, где необходима повышенная механическая прочность
3. Type-C - оставить для всех остальных устройств

Сегодня пришло уведомление о комментарии к тикету 111:

In the meanwhile QMapShack has a new brother called QMapTool. QMapTool is for referencing maps. It’s now part as a sub-repository of QMapShack.

И вот ссылка:

• https://bitbucket.org/maproom/qmaptool

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

Пока ещё не тестировал. В AUR mercurial версия QMapShack автоматом подтянет и QMapTool, когда будет релиз в Community - непонятно.

А так, ура!

Просто ссылка:

• AMD64 Linux Kernel Conventions

Более полная подборка для x86:

• x86 calling conventions

И более обобщённая информация (в т.ч. ARM):

• http://wiki.osdev.org/Calling_Conventions

В продолжение post/2017/08/25/qt_creator_baremetal_i_svjazka_gdb_7.7.1_openocd. Снова косяк и снова QtC не имеет прямого отношения к нему. Судя по всему, в самом GDB какие-то гонки.

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

В общем, пока откатился на GDB 7.8 от Linaro: https://aur.archlinux.org/packages/arm-none-eabi-gdb-linaro, оно, по крайней мере, работает.

Связанные ссылки и обсуждения:

• https://github.com/gnu-mcu-eclipse/eclipse-plugins/issues/186
• https://github.com/gnu-mcu-eclipse/eclipse-plugins/issues/167

PS текущая связка: GDB 7.8 + OpenOCD 0.10.0

И не только.

Для начала выполняем шаги, описанные в руководстве:

• Создание ресурсов общего доступа от имени обычного пользователя, или
• Creating usershare path

Если коротко и коспективно:

1. Создаём директорию usershare: mkdir -p /var/lib/samba/usershare
2. Создаём группу sambashare: groupadd sambashare
3. Правим права доступа к директории:``` chown root:sambashare /var/lib/samba/usershare chmod 1770 /var/lib/samba/usershare

  1. Проверяем конфигурацию `smb.conf`:```
...
[global]
  usershare path = /var/lib/samba/usershare
  usershare max shares = 100
  usershare allow guests = yes
  usershare owner only = yes
  ...

1. Разрешаем вашему пользователю создавать шары: usermod -a -G sambashare $USER
2. Рестартуем демоны smbd и nmbd
3. Перелогиниваемся в систему

Как минимум теперь вы сможете управлять пользовательскими шарами, используя командную строку:

net usershare help

Для использования этого функционала через Dolphin, потребуется поставить пакет kdenetwork-filesharing: pacman -S kdenetwork-filesharing

После чего в свойствах директории появится вкладка, ответственная за общий доступ к содержимому директории.

В qmmp есть плагин глобальных клавиш, который может обрабатывать кнопки переключения треков, паузы, проигрывания и остановки. Помимо этого он может перехватывать клавиши управления громкостью, выключения динамиков. И делает он это по умолчанию.

Так вот, это поведения очень нехорошо дружит с плазмоидом, который через трей выводит индикатор громкости. Точнее начинает глючить функционал, который собственно и обрабатывает мультимедийные кнопки управления громкостью и выводит OSD уведомление на экран.

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

Лечение простое:

1. в настройках qmmp для плагина глобальных клавиш убрать реакцию на кнопки управления громкостью.
2. открыть настройки трея и выключить и снова включить индикатор громкости.

PS подобное наблюдается и при использовании kmix. Более того, управления перехватывает последний запущенный механизм: или плазмоид или kmix. При закрытии одного из них, рекомендую перезагрузить оставшийся.

На днях заметил, что часть приложений время от времени перестают рисовать свои иконки в трее. С одной стороны, xembed - deprecated, но, судя по всему, плазма как-то пытается его использовать и отображать иконки в трее для “устаревших” приложений. Но не всегда это получается (ниже чуть подробнее).

По сути, нормально работать будут только приложения, которые поддерживают appindicator api.

Я делаю так:

ffmpeg -f v4l2 -i /dev/video0 -f alsa -i hw:1 -c:v copy -c:a copy -f matroska - | ffplay -autoexit -f matroska -

matroska может запаковать RAW/YUV/RGB данные, поэтому она. MPEG-TS не может, поэтому не подходит.

Или не менее наркоманский вариант, используя только FFMPEG:

ffmpeg -f v4l2 -i /dev/video0 -f alsa -i hw:1 -vcodec rawvideo -pix_fmt yuv420p -c:a copy -f sdl2 default -f alsa default

Конвертация в yuv420p нужна для SDL2.

Памятка:

• https://stackoverflow.com/questions/3882467/defining-operator-for-a-struct (второй ответ)
• http://www.cplusplus.com/reference/tuple/tuple/operators/

Т.е. используя std::tie() вполне, без труда и пыли, можно сделать операторы сравнения для сложных структур. Сложности могут возникнуть, если нужно переопределить операторы сравнения для отдельных элементов (например: критерии сравнения строк).

Почему tie, а не напрямую tuple? tie захватывает аргументы по ссылке - экономия на копировании.

Когда PulseAudio стартует, оно захватывает устройства и если пробуем запустить какое-то приложение, которое может только ALSA, то получим сообщение о невозможности открыть устройство, так как оно уже занято.

Что бы решить проблему нужна пара простых (по факту, но не по пути, которым к ним пришёл) шагов. Но для начала нужно посмотреть соответствующий раздел в вики Арчика: https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device

Идея проста: сказать пульсе работать через dmix для воспроизведения и через dsnoop для записи.