Уважаемый siy из ipc2u, я, видимо, невольно ввёл в кого-то в заблуждение, указав в качестве ссылки на коробочку сайт вашей компании. Исправляюсь - покупали не у вас, в этом смысле никаких претензий к ipc2u у нас нет.
По существу вопроса - проблему так и не решили. Колдовством с ядром удалось запустить 2 из 8 портов в ограниченном режиме RS-232. RS-485 не запустился вообще. В итоге сочли, что дешевле купить USB репликатор MOXA на 8 портов и забыть этот страшный сон. В будущем таких специфических железок без реального тестирования покупать не будем.

This variable is deprecated in Qt 5.6.

Судя по http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/ в iOS все решается автоматически при наличии ресурсов с суффиксом @2x. Налиличие подобного хака в винде из коробки тоже облегчило бы жизнь.

Qt 5.6.0, MSVC 2013 x64, Windows 10

Безусловно и неоднократно

С этими переменными ещё, конечно поиграюсь, но первые попытки игр с ними удручают. То шрифты не масштабируются вообще, то они масштабируются дважды - сначала ОС, а потом ещё и Qt. И даже простого режима "увеличения" приложения в 2 раза у меня нормально добиться не получилось. Типа кнопки выросли в 2 раза, а шрифты остались. В общем пока статистики мало.

Ну так собственно я-то вообще ничего не делаю - "оно всё само" косячит. Абсолютно аналогичное поведение наблюдается и на стандартных примерах.

Потенциально это не проблема. Например, делаю setPixmap(QIcon("file.svg").pixmap(QSIze(16 * ratio, 16 * ratio)). Осталось правильно ratio посчитать. Но это уже другая ожидаемая проблема - к ней ещё вернусь по результатам текущих исследований.

Ну файрфокс не "течет", Qt Creator почти не течет, MSVS и офис совсем не текут, да и у меня проблемы вполне решаемые.

Это уже совсем клиника будет. Разные версии для 32 и 64 бита, разных ОС, а теперь ещё и разных DPI. Смерти моей хотите?

Стал счастливым обладателем монитора с UHD (3840х2160) разрешением. Наконец, мои глаза довольны .
Дошли руки до своего Qt GUI софта - получил где-то вполне ожидаемые, а где-то не очень проблемы.
Начнем с неожиданных:
1. Если я в приложении делаю setStyleSheet даже в варианте setStyleSheet(QString()) получаю другие размеры шрифтов, А именно вложение 1 - с примененным стилем, вложение 2 - без него. Как видно размеры шрифтов в QStatusBar разные. Хотелось бы иметь одинаковой поведение независимо от текущего DPI.
2. Высота QToolBar в дизайнере (вложение 3) не такая, как в runtime. Тут тоже хотелось бы однозначного соответствия.
Ну и проблема ожидаемая:
3. Проверенные годами иконки 16х16 нечитаемы на Hi DPI. Понятно, что простое решение - использование векторной графики, но тут пока проблема с адекватными сетами. Есть ли вариант как-нибудь в рантайм подменять файлы ресурсов с иконками разного размера в зависимости от текущего DPI?

Вот долго я пытался эту бессмысленную тему игнорировать. Но после такого...
Я работаю в ИБ организации несколько бОльшей, чем упомянутый банк. У нас везде виндовс с "особой корпоративной лицензией". Так вот от "не особой" она не отличается... Правильно ничем. И если тот самый банк строит свои корпоративные системы основываясь просто на "вере" МС на слово, я настоятельно рекомендую свои деньги оттуда увести. Хотя, конечно, уверен, что их служба ИБ не настолько наивна, как автор этой цитаты.

Ubuntu 14.04, Qt 5.5.0
После установки QtCreator 4.0b при попытке загрузить любой qbs проект с Qt получаю ошибку:
qbs "Product dependency 'Qt.core' not found"
Причем теперь аналогичная ошибка и в штатном QtCreator 3.6.1.
Без Qt qbs собирается нормально. Куда копать?

С чего это всем другим потокам ждать? Ждать будут только те потоки, которые будут пытать сделать lock, всем остальным потокам глубоко всё равно на этот мьютекс. Так что currentThread() в контексте CMutex::lock() в общем случае может не иметь ничего общего с тем потоком, из которого, собственно, и был вызван lock().

Подозреваю, между mMutex.lock() и mOwner = QThread::currentThread() текущий поток вполне может стать уже другим.

Нашёл. linux-4.4.1\drivers\hwmon\nct6775.c

C++ (Qt)
* Supports the following chips:
 *
 * Chip        #vin    #fan    #pwm    #temp  chip IDs       man ID
 * nct6106d     9      3       3       6+3    0xc450 0xc1    0x5ca3

Смущает, что в разделе hwmon - видимо тут только мониторинговая часть этих контроллеров используется, а не коммуникационная. А вот в linux-4.4.1\drivers\tty ничего подобного не находится.

Пока разобрал конструкцию. Завтра вечером снова соберу - тогда выложу.
Тут, кстати, более подробно по это https://www.linux.org.ru/forum/linux-hardware/12336599

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

Из коробки было Linux 4.4.1-2-ARCH
Как это узнать?

Удалось-таки поставить arch (этот процесс заслуживает отдельного обсуждения, но не в рамках этой темы  ). В результате имею всего 4 ttyS порта вместо 8, и полное отсутствие признаков их жизни. Дополнительно, в BIOS увидел, что эти порты управляются контролерами nuvoton nct6106d (2 шт, по 4 порта на каждом) - это мне чем-нибудь сможет помочь?

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