Обновил ядро до 4.4.0 - железка несколько ожила. Стали светиться лампочки . При попытке выполнить что echo «HELLO» > /dev/ttyS1, что cat < /dev/ttyS1 загорается светодиод rx, но tx не загорается вовсе и данные не передаются. Замкнуты 2 и 3 контакты. Скачал arch, но на ночь глядя связываться с ним неохота

Сейчас попробую обновиться в рамках убунту, потом уже к arch пойду.

Может проще ядро обновить до 4.4 на самой ubuntu? На Arch текущем ядро 4.3, gentoo и вовсе от августа 2014...

Там кроме обещаний ничего больше и нет. Запросил дистрибьютеров - пока тишина.

Как-то экстремальненько... Никогда с ними дела не имел, хотя с генту всегда было интересно познакомиться.

Ожидаемо (см. про нормальную работу из под виртуалки) не помогло.
Что делать-то? Просто "грешить на ядро" как-то очень уж не конструктивно

Да, добавлен, в dialout. Из под рута тоже пробовал. Кроме того, повторюсь на виртуалке в ubuntu всё работает сразу и без шаманств.
Похоже, действительно ядро как-то коряво взаимодействует с этими портами. То есть видит их как нормальные

Bash
acs@acs-CEM860:~$ dmesg | grep ttyS
[    1.456871] 00:04: ttyS4 at I/O 0x240 (irq = 11, base_baud = 115200) is a 16550A
[    1.477404] 00:05: ttyS5 at I/O 0x248 (irq = 11, base_baud = 115200) is a 16550A
[    1.497913] 00:06: ttyS6 at I/O 0x250 (irq = 11, base_baud = 115200) is a 16550A
[    1.518463] 00:07: ttyS7 at I/O 0x258 (irq = 11, base_baud = 115200) is a 16550A
[    1.539043] 00:09: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    1.559597] 00:0a: ttyS1 at I/O 0x2f8 (irq = 4, base_baud = 115200) is a 16550A
[    1.580162] 00:0b: ttyS2 at I/O 0x3e8 (irq = 4, base_baud = 115200) is a 16550A
[    1.600717] 00:0c: ttyS3 at I/O 0x2e8 (irq = 4, base_baud = 115200) is a 16550A
 

А писать/читать не может

Там вообще ttyS... до 31 нумеруются, но только на первых 8 есть сведения о том, что оно на UART16550A, на остальных - "нет данных". Да и IRQ и номера физических портов для этих первых 8-ми совпадают с теми, которые были в свойствах портов в windows. Понятно, что все ttyS0..7 я перепробовал с одинаково нулевым результатом.

Есть не вполне обычная коробченка Axiomtek eBOX730-860-FL (http://ipc2u.ru/news/new/eBOX730-860-FL/) с 8 изолированными COM портами.
Ставлю на неё Windows - COM порты работают вполне ожидаемо, причём в диспетчере устройств никаких необычных контроллеров в части портов не наблюдаю. У коробченки есть набор из 16 светодиодов на корпусе, которые моргают, когда идет чтение/запись в COM порты. Замыкаю пины 2 и 3 на одном из портов, кидаю на него сообщение и ожидаемо принимаю на том же порту. В общем, на Windows, всё работает нормально.
Ставлю на неё же линукс (пробовал ubuntu и astra), вижу в ls 8 uart портов типа /dev/ttyS0..7 и... Собственно и всё - никакие огоньки не мигают, данные не передаются и не принимаются. Причем сами порты открываются вполне себе нормально.
Мало того, если я разворачиваю под этой виндой виртуалку с ubuntu, "пробрасываю" пару COM портов на гостевую ОС - всё тоже нормально без всяких танцев с бубном - огоньки мигают, данные передаются/принимаются. Куда копать-то дальше?

А как это автоматизировать? IDE-то откуда узнать должна в каком из инклудов находится используемый класс?
P.S. В Делфи был один из плагинов, который позволял по шорткату перейти к строке implementation где обычно пишутся аналоги сишных #include, там дописать нужный модуль и по Esc вернуться к тому месту, в котором был нажат шоркат. Вот такой функционал было бы реализовать просто.

Про creator не скажу (хотя наличие, например, плагина для todo говорит об обратном), но VS-то чем в этом смысле не угодил? Visual Assist как мне кажется умеет делать с кодом всё, что только можно. Так что с "дружелюбием" к плагинами у VS всё в порядке.

Найти отладочную версию любой so из состава Qt, посмотреть на её "внутренности", найти в ней строку вида "work/build/qt5_workdir/w/s" (или как там в MacOS оно выглядит) и сопоставить ей путь к папке с реальными исходниками, т.е. к папке, родительской по отношению к qtbase. Если в QtCreator for MacOS нет стандартного способа это сделать, то может симлинки соответствующие создать на уровне файловой системы?

Из совсем свежего: http://www.prog.org.ru/index.php?topic=29541
Там всё уже написано.

Я же написал, что это моё личное мнение (ИМХО). Никто не заставляет Вас с ним соглашаться. Основано оно на личном опыте использования своего собственного программного окружения, как дома, так и "в быту". С горечью (потому как не место им там!) наблюдаю переход нормальных и совсем "не web" приложений в онлайн (начиная с офиса, заканчивая IDE). Можете попробовать ещё сравнить количество публикаций о десктоп/фронтенд/бекенд разработке, на, например, хабре. Да и вот банально недавно супруге на ноуте windows переустанавливал - обычно это был мучительный процесс с последующей установкой самого разного ПО. Теперь она говорит, браузер поставь нормальный и хватит.

Кстати, понадобилось вот снова подебажить бету Qt 5.6.0. И выяснилось, что стандартная фича QtCreatora по маппингу исходников Qt уже не работает. Но некоторые "изыскания" по этому поводу проблему всё-же решили. Теперь правильный путь родных исходников выглядит как "c:/users/qt/work/qt"/ а не "C:/work/build/qt5_workdir/w/s" как раньше.
То есть сейчас моё окно с настройками дебагера выглядит так (вложение). И всё нормально дебажится.
Может и в линуксе нужно просто правильный путь отмапить. Я просто посмотрел на содержимое Qt5Cored.dll и поискал в нём строку вида "C:\"...

Тут-то ИМХО ответ очевиден. Гаснет не интерес к Qt, а интерес к desktop разработкам в целом. Для мобильных приложений, похоже (сам для мобил не программировал), Qt избыточен. Для бекенда тренд  - всякие nodejs, go, rust и подобное. Вот и остаётся ниша - корпоративные приложения (а там для десктопа Java да .Net рулят, не вспоминая уже про 1C, SAP да прочий RichGUI  в браузере), да ПО для для всяких симуляторов и промышленного оборудования. Да и сам Qt для desktop в части widget составляющей практически не развивается уже несколько лет. QGraphicScene фактически забыт, MVC так и остался в ужасном зачаточном виде, рынок пользовательских виджетов так и не раскрылся...
Ну а QML для классических десктоп приложений тоже так толком и не допилился. Раньше могли козырять кроссплатформенностью, теперь же когда "браузер-наше всё", необходимости в обычных клиентских приложениях всё меньше, так что и этот плюс становится всё менее весомым.