Дискретная видеокарта
- Автор темы 70mka
- Дата начала
Это неправда. 
Если вы хоть что-то видите на экране - значит драйвера есть - "... просто вы не умеете их готовить"
P.S. Гибридная графика была большой гадостью (почти не решаемой) в Linux лет 5 назад ... но сейчас, в большинстве случаев, всё решается.
Проблема в том, что, если она есть - нужно брать и подробно разбираться ... на это может уйти немало времени:
- вы пишете торговое название видеокарты xgi volari z7-z9 (да ещё и китайское название, скорее всего), а нужно знать тип чипа - команда lspci ...
- дальше выясняете название модуля ядра (драйвера) поддерживающего вашу видеокарту- команда lspci -vvv
- дальше разбираетесь с этим модулем: может там параметры есть, может в Google поискать, может в коды ядра заглянуть (в комментарии), вот здесь: https://elixir.bootlin.com/linux/v5.1.11/source/kernel ...
- если эта видеокарта - Radeon-приблуда от AMD, то там были какие-то серьёзные проблемы на время ядра Linux между 4.15 и 4.19 ... выясняйте и запоминайте что за версия ядра у вас стоит:
Если вы хоть что-то видите на экране - значит драйвера есть - "... просто вы не умеете их готовить"
P.S. Гибридная графика была большой гадостью (почти не решаемой) в Linux лет 5 назад ... но сейчас, в большинстве случаев, всё решается.
Проблема в том, что, если она есть - нужно брать и подробно разбираться ... на это может уйти немало времени:
- вы пишете торговое название видеокарты xgi volari z7-z9 (да ещё и китайское название, скорее всего
), а нужно знать тип чипа - команда lspci ...- дальше выясняете название модуля ядра (драйвера) поддерживающего вашу видеокарту- команда lspci -vvv
- дальше разбираетесь с этим модулем: может там параметры есть, может в Google поискать, может в коды ядра заглянуть (в комментарии), вот здесь: https://elixir.bootlin.com/linux/v5.1.11/source/kernel ...
- если эта видеокарта - Radeon-приблуда от AMD, то там были какие-то серьёзные проблемы на время ядра Linux между 4.15 и 4.19 ... выясняйте и запоминайте что за версия ядра у вас стоит:
Код:
olej@astra:~/HISTORY/08.30$ uname -r
4.19.0-1-generic
*в сторону*
Сколько текста, мать моя женщина...
Первая ссылка по XGI Volari Z7 + linux Там и про выхлоп lspci (который, внезапно, не отличается от приведенного названия - неожиданно, не правда ли?), и про давнюю проблему этой специфичной 2D-граф.карты (ни разу не гибрид, ага) для серверов и тонких клиентов в nix-системах. И про решение, которое, увы, заключается в ручном редактировании xorg.conf. Драйверы, если что, есть под RHEL. Но тут косяк - Astra как бы deb-дистрибутив, так что кейсы "Красной шапочки" в данном случае не уместны...
Короче, это классическая проблема узкоспециализированного железа...
Сколько текста, мать моя женщина...
Первая ссылка по XGI Volari Z7 + linux Там и про выхлоп lspci (который, внезапно, не отличается от приведенного названия - неожиданно, не правда ли?), и про давнюю проблему этой специфичной 2D-граф.карты (ни разу не гибрид, ага) для серверов и тонких клиентов в nix-системах. И про решение, которое, увы, заключается в ручном редактировании xorg.conf. Драйверы, если что, есть под RHEL. Но тут косяк - Astra как бы deb-дистрибутив, так что кейсы "Красной шапочки" в данном случае не уместны...
Короче, это классическая проблема узкоспециализированного железа...
Да, как сказали, нет там никакой дискретной, гибридной видеокарты... у вас видеокарта производства 2004г. (15 лет, музейный раритет) от фирмы-производителя, которая перестала существовать в 2006г. - в те времена ещё даже такие термины для видеокарт как дискретная или гибридная просто не придумали.
Одно другому не противоречит? Так установились или нету как таковых? Вы уж как-то определитесь...
Драйвер (модуль ядра) вашей карты (с которой сейчас работает) sys или vesa ...
Посмотрите что там у вас сейчас (именно с опцией -v):
В Linux драйвера - модули ядра (термин драйвер для Linux, по существу, негодный) - могут предоставляться только и исключительно в виде исходных программных кодов на языке C, которые подлежат компиляции только в конкретной версии ядра (с конкретными config параметрами ядра) ... и никак иначе - в Linux не может быть бинарных (готовых) драйверов, это - архитектурная особенность ядра Linux. Поэтому не может быть никаких драйверов для RPM дистрибутивов, DEB дистрибутивов, или для любого самого экзотического дистрибутива Linux - они все и всегда едины (они могут быть завёрнуты в пакет RPM или DEB, но это только внешний антураж). Более того, 99.99% всех модулей ядра состоят в составе дерева исходных кодов Linux (на kernel.org).
Одно другому не противоречит? Так установились или нету как таковых? Вы уж как-то определитесь...
Драйвер (модуль ядра) вашей карты (с которой сейчас работает) sys или vesa ...
Посмотрите что там у вас сейчас (именно с опцией -v):
Код:
$ lspci -v
...
Последнее редактирование:
ТС, я надеюсь, что вы ещё не успели воспользоваться изложенной там "рекомендацией" по ручной правке xorg.conf?
Потому что механическое применение такой правки (перенесенной из чужого дистрибутива), не разобравшись что сейчас у вас происходит, приведёт в наибольшей вероятностью к обвалу графической подсистемы Linux, загрузки в восстановительном текстовом режиме, необходимости восстановления в текстовых консолях ... для тех, у кого нет практики работы в текстовой консоли, это обычно заканчивается полной переустановкой системы...
Вы можете воспользоваться xrandr для временной проверки графических режимов, которая не разобьёт вам графику, и только при успешном решении сделать эти изменения постоянными. Примерно так:
- контролируете какие у вас есть доступные графические моды (которое с * - то и ваше):
- определить (описать) новый режим (если вам существующих не хватает):
- добавить новый режим:
- переключиться в новый режим (посмотреть как оно выглядит):
Строку modeline (Coordinated Video Timing), которую нужно задать для определения новой моды, не выдумываете вручную, у вас есть 2 утилиты, определяющие эту строку:
P.S. Подробнее, с примерами, можете глянуть здесь:
Разрешение монитора
Rapsberry Pi в проекте
РАЗРЕШЕНИЕ ЭКРАНА В LINUX
Потому что механическое применение такой правки (перенесенной из чужого дистрибутива), не разобравшись что сейчас у вас происходит, приведёт в наибольшей вероятностью к обвалу графической подсистемы Linux, загрузки в восстановительном текстовом режиме, необходимости восстановления в текстовых консолях ... для тех, у кого нет практики работы в текстовой консоли, это обычно заканчивается полной переустановкой системы...
Вы можете воспользоваться xrandr для временной проверки графических режимов, которая не разобьёт вам графику, и только при успешном решении сделать эти изменения постоянными. Примерно так:
- контролируете какие у вас есть доступные графические моды (которое с * - то и ваше):
Код:
olej@ACER:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 287mm
1920x1080 60.00*+
1280x1024 75.02 60.02
1280x960 60.00
1280x800 59.91
1152x864 75.00
1280x720 60.00
1024x768 75.03 70.07 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
640x480 75.00 72.81 66.67 59.94
720x400 70.08
Код:
$ xrandr --newmode "1600x1200_60.00" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync
Код:
$ xrandr --addmode VGA1 1600x1200_60.00
Код:
$ xrandr --output VGA1 --mode 1600x1200_60.00
Код:
olej@ACER:~$ cvt
usage: cvt [-v|--verbose] [-r|--reduced] X Y [refresh]
...
Calculates VESA CVT (Coordinated Video Timing) modelines for use with X.
Код:
olej@ACER:~$ gtf
usage: gtf x y refresh [-v|--verbose] [-f|--fbmode] [-x|--xorgmode]
...Разрешение монитора
Rapsberry Pi в проекте
РАЗРЕШЕНИЕ ЭКРАНА В LINUX
Последнее редактирование:
to Olej
Primo, безграмотное редактирование конфигов xorg.conf (читай, копипаста всяческих сетевых туториалов) в любом случае приведет к краху видеоподсистемы. Вне зависимости от дистрибутива, потому что проблема в кривых руках. А вот методы редактирования - они универсальны и, внезапно, тоже не зависят от дистрибутива. Потому что Xorg идентичен в любом дистрибутиве nix, какой ни возьми (отчасти, с этим связан негатив сообщества по отношению к его застарелым багам и косякам)! Сколько вы там лет "профессионально работаете в Linux"? Пора бы уже знать такие базовые вещи, ага...
Secundo, вы всерьез считаете, что проприетарные драйверы Nvidia, Amd и проч. компаний поставляются в виде сорцов в формате *.c/*.cpp? Вот эту хохму надо срочно залить на LOR...
Tertio, озвученная проблема RHEL/Astra не в том, что ядра могут совпадать, а драйвер - это модуль ядра. А в том, что для Astra Linux SE запрещены необдуманные модификации (уж тем более ядра) для случая эксплуатации - это нарушает выданный сертификат соответствия, а в некоторых случаях может являться основанием и для более интересных нарушений. Поэтому заикаться об исходных кодах ядра, давать ссылки на kernel.org и проч. в контексте конкретного вопроса по Astra Linux SE как минимум глупо (зачастую, еще и опасно)...
Базировалась бы Astra на RHEL + был бы драйвер для RHEL с поддержкой dkms + попал бы этот драйвер в итоговый дистрибутив Astra Linux SE 1.6 как у тов. 70mka, тогда... Тогда можно было бы решить проблему, не нарушая политику сертификации...
Короче, читайте описание по продукту, на форуме которого что-то пишите. А то это выглядит пустым очковтирательством от nix-админа эникейщика, пытающегося всюду вставить свои 5 копеек, не разобравшись в сути происходящего, ага...
Primo, безграмотное редактирование конфигов xorg.conf (читай, копипаста всяческих сетевых туториалов) в любом случае приведет к краху видеоподсистемы. Вне зависимости от дистрибутива, потому что проблема в кривых руках. А вот методы редактирования - они универсальны и, внезапно, тоже не зависят от дистрибутива. Потому что Xorg идентичен в любом дистрибутиве nix, какой ни возьми (отчасти, с этим связан негатив сообщества по отношению к его застарелым багам и косякам)! Сколько вы там лет "профессионально работаете в Linux"? Пора бы уже знать такие базовые вещи, ага...
Secundo, вы всерьез считаете, что проприетарные драйверы Nvidia, Amd и проч. компаний поставляются в виде сорцов в формате *.c/*.cpp? Вот эту хохму надо срочно залить на LOR...
Tertio, озвученная проблема RHEL/Astra не в том, что ядра могут совпадать, а драйвер - это модуль ядра. А в том, что для Astra Linux SE запрещены необдуманные модификации (уж тем более ядра) для случая эксплуатации - это нарушает выданный сертификат соответствия, а в некоторых случаях может являться основанием и для более интересных нарушений. Поэтому заикаться об исходных кодах ядра, давать ссылки на kernel.org и проч. в контексте конкретного вопроса по Astra Linux SE как минимум глупо (зачастую, еще и опасно)...
Базировалась бы Astra на RHEL + был бы драйвер для RHEL с поддержкой dkms + попал бы этот драйвер в итоговый дистрибутив Astra Linux SE 1.6 как у тов. 70mka, тогда... Тогда можно было бы решить проблему, не нарушая политику сертификации...
Короче, читайте описание по продукту, на форуме которого что-то пишите. А то это выглядит пустым очковтирательством от nix-админа эникейщика, пытающегося всюду вставить свои 5 копеек, не разобравшись в сути происходящего, ага...
to Olej
По вашей логике следует, что nouveau, поддерживаемый сообществом, не нужен - зачем? ведь NVIDIA поставляет свои драйверы не в бинарном виде, а в сорцах, которые может изучить и скомпилировать любой желающий...
Внимание! Рубрика "занимательная математика". Складываем "имеем устаревший драйвер под RHEL бородатого года" + "имеем Astra с конкретной и куда более современной версией ядра" и думаем, к чему я упоминул DKMS...
По вашей логике следует, что nouveau, поддерживаемый сообществом, не нужен - зачем? ведь NVIDIA поставляет свои драйверы не в бинарном виде, а в сорцах, которые может изучить и скомпилировать любой желающий...
Внимание! Рубрика "занимательная математика". Складываем "имеем устаревший драйвер под RHEL бородатого года" + "имеем Astra с конкретной и куда более современной версией ядра" и думаем, к чему я упоминул DKMS...
Дружище!
Мы могли бы с вами поговорить о модулях ядра Linux...
- если бы вы понимали в технике написания модулей ядра хотя бы на уровне кружка "Умелые Руки" Дворца Пионеров...
- если бы вы за свою никчемную жизнь написали хотя бы один примитивный модуль ядра ... ну пусть бы это был хоть самый примитивный Hello World ...
- если бы вы понимали каким механизмом модули ядра связываются с именами API (точками входа) из /proc/kallsyms (или /boot/System.map-*) ... (подсказка для самых тупых: по абсолютным виртуальным адресам функций вызова - это всё объясняет ... но вам это всё равно ничем не поможет).
А поскольку ни 1). ни 2). ни 3). не имеют места быть - то как же мы с вами можем говорить о модулях ядра Linux, о драйверах, и с чем их там в Linux едят?
Смешно-с ...
Мы могли бы с вами поговорить о модулях ядра Linux...
- если бы вы понимали в технике написания модулей ядра хотя бы на уровне кружка "Умелые Руки" Дворца Пионеров...
- если бы вы за свою никчемную жизнь написали хотя бы один примитивный модуль ядра ... ну пусть бы это был хоть самый примитивный Hello World ...
- если бы вы понимали каким механизмом модули ядра связываются с именами API (точками входа) из /proc/kallsyms (или /boot/System.map-*) ... (подсказка для самых тупых: по абсолютным виртуальным адресам функций вызова - это всё объясняет ... но вам это всё равно ничем не поможет).
А поскольку ни 1). ни 2). ни 3). не имеют места быть - то как же мы с вами можем говорить о модулях ядра Linux, о драйверах, и с чем их там в Linux едят?
Смешно-с ...
Последнее редактирование:
А если бы вы в своём убожестве хоть раз за многие годы заглянули внутрь в "драйвера" NVIDIA вида NVIDIA-Linux-x86_64-#.run, то заметили бы, что это shell-скрипт, в котором примерно от смещения ~0xB130 (+/-) лежит бинарная часть, из которой shell-скрипт именно и компилирует и собирает модуль ядра. Точно так же, как свои модули устанавливает и VirtualBox от Oracle (вида VirtualBox-6.0.10-#-Linux_amd64.run). Это просто такой искусственный трюк, предназначенный для скрытия программного кода, из которого собирается модуль (или модули).
А если бы вы дали себе труд наблюдать в консоли инсталляцию драйверов NVIDIA, то увидели бы, что это и есть самая натуральная компиляция-сборка теми же mske, gcc и т.д.
P.S. Неужели этого не мог бы понять любой, кто хоть раз бы это делал сам ... а не начитался предисловий в Google.
А если бы вы дали себе труд наблюдать в консоли инсталляцию драйверов NVIDIA, то увидели бы, что это и есть самая натуральная компиляция-сборка теми же mske, gcc и т.д.
P.S. Неужели этого не мог бы понять любой, кто хоть раз бы это делал сам ... а не начитался предисловий в Google.
Последнее редактирование:
to Olej
Еще раз:
ЗЫ Переход от "дружище" к "дегенерату" попахивает синдромом Туретта. Сочувствую вашим друзьям...
Еще раз:
- читайте ограничения Astra Linux Special Edition в части установки стороннего софта (про особенности компиляции, про средства разработчика, про использование неизвестных бинарей, про запуск сторонних модулей);
- читайте свою же фразу про "бинарную часть" драйвера от той же NVIDIA;
- почитайте про драйвер видеоадаптера тов. 70mka и его ограничения;
- включите наконец голову и язык совместно, а не раздельно.
ЗЫ Переход от "дружище" к "дегенерату" попахивает синдромом Туретта. Сочувствую вашим друзьям...
Давайте я для совсем тупых повторю целых 3 раза ... как для милиционера :
- в shell-скрипте можно зашифровать (в хвосте) любую информацию и любым способом...
- с которой этот shell-скрипт знает как и может работать...
- в частности, он извлекает программный код (исходный!) и запускает его сборку;
- но от того, что зашифрованные байты выглядят как бинарная бессмыслица, эта бессмыслица не становится исполнимым бинарным кодом.
Ещё раз, как для милиционера (по разделениям: "делай раз - делай два" - конспектируйте, пока я жив): Linux устроен так (довольно примитивно), что код модулей ядра обращается к функциям API ядра тупо по их абсолютным адресам, см. например:
А поэтому, стоит внести любые изменения в ядро, например пересобрать его с другими CONFIG параметрами - как загрузка или выполнение кода любого модуля может завершиться мгновенным крахом системы: глухо-немым и безнадёжным.
А поэтому, все модули ядра могут собираться только под совершенно определённое ядро (по версии, по подверсии, по сборке, по CONFIG, ...) + при любом изменении ядра все модули должны замещаться соответствующими версиями.
Для модулей из состава дерева исходных кодов ядра (kernel.org) это замещение за вас делает майнтейнер дистрибутива, комплектуя модули в комплекте с ядром.
А для любых сторонних модулей вы должны делать сборку. А DKMS (Dynamic Kernel Module Support) - это всего лишь фреймворк, который запускает сборку динамически при обновлениях ядра ... и ничего более - всё ту же сборку.
А поэтому, модули ядра (драйверы) в Linux могут присутствовать только в виде исходных кодов на языке C, для пересборки при любых обновлениях... и никак иначе!
Законспектировали?
P.S. Надеюсь что я не напрасно потерял время на "так много букаф", и кому-то поразумнее из изучающих Linux это тоже пригодится.
:- в shell-скрипте можно зашифровать (в хвосте) любую информацию и любым способом...
- с которой этот shell-скрипт знает как и может работать...
- в частности, он извлекает программный код (исходный!) и запускает его сборку;
- но от того, что зашифрованные байты выглядят как бинарная бессмыслица, эта бессмыслица не становится исполнимым бинарным кодом.
Ещё раз, как для милиционера (по разделениям: "делай раз - делай два" - конспектируйте, пока я жив
): Linux устроен так (довольно примитивно), что код модулей ядра обращается к функциям API ядра тупо по их абсолютным адресам, см. например:
Код:
olej@ACER:~$ sudo cat /proc/kallsyms | grep ' T ' | grep kmalloc
ffffffffb7dc3510 T mempool_kmalloc
ffffffffb7deefe0 T kmalloc_order
ffffffffb7def010 T kmalloc_order_trace
ffffffffb7df0ac0 T kmalloc_slab
ffffffffb7e362d0 T __kmalloc
ffffffffb7e36500 T __kmalloc_node
ffffffffb7e39510 T __kmalloc_track_caller
ffffffffb7e39720 T __kmalloc_node_track_caller
ffffffffb812c9b0 T devm_kmalloc
ffffffffb81bd6e0 T sock_kmalloc
ffffffffb9088933 T create_kmalloc_cache
ffffffffb9088a18 T setup_kmalloc_cache_index_table
ffffffffb9088a1e T create_kmalloc_caches
ffffffffb9178e40 T kmalloc_infoА поэтому, все модули ядра могут собираться только под совершенно определённое ядро (по версии, по подверсии, по сборке, по CONFIG, ...) + при любом изменении ядра все модули должны замещаться соответствующими версиями.
Для модулей из состава дерева исходных кодов ядра (kernel.org) это замещение за вас делает майнтейнер дистрибутива, комплектуя модули в комплекте с ядром.
А для любых сторонних модулей вы должны делать сборку. А DKMS (Dynamic Kernel Module Support) - это всего лишь фреймворк, который запускает сборку динамически при обновлениях ядра ... и ничего более - всё ту же сборку.
А поэтому, модули ядра (драйверы) в Linux могут присутствовать только в виде исходных кодов на языке C, для пересборки при любых обновлениях... и никак иначе!
Законспектировали?
P.S. Надеюсь что я не напрасно потерял время на "так много букаф", и кому-то поразумнее из изучающих Linux это тоже пригодится.
Последнее редактирование:
to Olej
"Ах ты идолище поганое, не ухвативши белого лебедя, а кушаешь" (с)
За новую простыню текста спасибо, конечно, но:
ЗЫ Бесплатный совет: перестаньте лезть с gentoo'шными приемами в ветку бинарного дистрибутива, в котором многие модификации в принципе запрещены политикой сертификации и требованиями инфобеза. Теоретический ликбез прекрасен, но не в том месте и не в то время, поймите наконец...
"Ах ты идолище поганое, не ухвативши белого лебедя, а кушаешь" (с)
За новую простыню текста спасибо, конечно, но:
- вы располагаете исходниками драйвера для xgi volari z7-z9, чтобы можно было собрать нужный модуль в Astra Linux Special Edition с применением dkms?
- вы готовы протестировать собранный модуль на оборудовании тов. 70mka?
- вы готовы собрать более-менее универсальный deb-пакет и опубликовать его для Astra Linux Special Edition, договорившись с разработчиками?
- вы готовы после пройти с ним все круги сертификации при очередном апдейте?
ЗЫ Бесплатный совет: перестаньте лезть с gentoo'шными приемами в ветку бинарного дистрибутива, в котором многие модификации в принципе запрещены политикой сертификации и требованиями инфобеза. Теоретический ликбез прекрасен, но не в том месте и не в то время, поймите наконец...
Конспектируй ... конспектируй...
Элементарно, Ватсон!
Там не нужно ничего "располагать"
Там у "тов. 70mka" модуль ядра либо sys, либо vesa (в зависимости что там ему Astra Linux подсунула по идентификатору VID : PID), которые замечательно присутствую оба в стандартных исходниках ядра ... и "тов. 70mka" нужно всего лишь выяснить какой из 2-х модулей у него сейчас используется (прежде всего, чтобы не нагадить в своей графической системе).
Только "тов. 70mka", похоже, вопрос этот глубоко "до фени".
Элементарно, Ватсон!
Там не нужно ничего "располагать"
Там у "тов. 70mka" модуль ядра либо sys, либо vesa (в зависимости что там ему Astra Linux подсунула по идентификатору VID : PID), которые замечательно присутствую оба в стандартных исходниках ядра ... и "тов. 70mka" нужно всего лишь выяснить какой из 2-х модулей у него сейчас используется (прежде всего, чтобы не нагадить в своей графической системе).
Только "тов. 70mka", похоже, вопрос этот глубоко "до фени".
А совет с правкой xorg.conf безусловно полезен (хотя это не единственный способ), но только последним шагом - когда всё уже выяснено + проверено + оттестировано в требуемом разрешении ... и только потом может быть правка xorg.conf, и только для того, чтобы найденные параметры сохранялись после перезагрузки.
to Olej
За сим, любезный эникейщик, отправляю вас в багтрэк Debian. Для изучения проблематики vesa/sis при использовании xgi volari z7-z9. Когда вернетесь с пустыми руками, не забудьте указать, что это - классическая проблема узкоспециализированного железа...
Нет, у вас, конечно, еще есть шанс реабилитироваться. В частности:
За сим, любезный эникейщик, отправляю вас в багтрэк Debian. Для изучения проблематики vesa/sis при использовании xgi volari z7-z9. Когда вернетесь с пустыми руками, не забудьте указать, что это - классическая проблема узкоспециализированного железа...
Нет, у вас, конечно, еще есть шанс реабилитироваться. В частности:
- найти в Сети старые исходники (в частности, энтузиасты нечто подобное на github выложили года 3 назад);
- исправить поддержку Xorg;
- скомпилить драйвер и потестировать его на Astra Linux Special Edition с соответствующим железом;
- собрать инсталлятор с поддержкой dkms;
- пробить его включение в состав дистрибутива.