Дискретная видеокарта

70mka

New member
Сообщения
1
#1
Здравствуйте, имеется дискретная видеокарта xgi volari z7-z9, драйвера установились, но не корректно работает разрешение 800х600 default, более менее адекватное разрешение сам прописывал. Подскажите пожалуйста, в чем проблема, дров как таковых нету на линукс. Smolensk astra 1.6.
 

Olej

New member
Сообщения
979
#2
Подскажите пожалуйста, в чем проблема, дров как таковых нету на линукс.
Это неправда. :rolleyes:
Если вы хоть что-то видите на экране - значит драйвера есть - "... просто вы не умеете их готовить" :cry:
P.S. Гибридная графика была большой гадостью (почти не решаемой) в Linux лет 5 назад ... но сейчас, в большинстве случаев, всё решается.
Подскажите пожалуйста, в чем проблема,
Проблема в том, что, если она есть - нужно брать и подробно разбираться ... на это может уйти немало времени:
- вы пишете торговое название видеокарты xgi volari z7-z9 (да ещё и китайское название, скорее всего :p), а нужно знать тип чипа - команда 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
 

oko

New member
Сообщения
95
#3
*в сторону*
Сколько текста, мать моя женщина...

Первая ссылка по XGI Volari Z7 + linux Там и про выхлоп lspci (который, внезапно, не отличается от приведенного названия - неожиданно, не правда ли?), и про давнюю проблему этой специфичной 2D-граф.карты (ни разу не гибрид, ага) для серверов и тонких клиентов в nix-системах. И про решение, которое, увы, заключается в ручном редактировании xorg.conf. Драйверы, если что, есть под RHEL. Но тут косяк - Astra как бы deb-дистрибутив, так что кейсы "Красной шапочки" в данном случае не уместны...
Короче, это классическая проблема узкоспециализированного железа...
 

Olej

New member
Сообщения
979
#4
имеется дискретная видеокарта xgi volari z7-z9,
Да, как сказали, нет там никакой дискретной, гибридной видеокарты... у вас видеокарта производства 2004г. (15 лет, музейный раритет) от фирмы-производителя, которая перестала существовать в 2006г. - в те времена ещё даже такие термины для видеокарт как дискретная или гибридная просто не придумали.
дров как таковых нету на линукс.
Одно другому не противоречит? Так установились или нету как таковых? Вы уж как-то определитесь...
Драйвер (модуль ядра) вашей карты (с которой сейчас работает) sys или vesa ...
Посмотрите что там у вас сейчас (именно с опцией -v):
Код:
$ lspci -v
...
Драйверы, если что, есть под RHEL. Но тут косяк - Astra как бы deb-дистрибутив, так что кейсы "Красной шапочки" в данном случае не уместны...
В Linux драйвера - модули ядра (термин драйвер для Linux, по существу, негодный) - могут предоставляться только и исключительно в виде исходных программных кодов на языке C, которые подлежат компиляции только в конкретной версии ядра (с конкретными config параметрами ядра) ... и никак иначе - в Linux не может быть бинарных (готовых) драйверов, это - архитектурная особенность ядра Linux. Поэтому не может быть никаких драйверов для RPM дистрибутивов, DEB дистрибутивов, или для любого самого экзотического дистрибутива Linux - они все и всегда едины (они могут быть завёрнуты в пакет RPM или DEB, но это только внешний антураж). Более того, 99.99% всех модулей ядра состоят в составе дерева исходных кодов Linux (на kernel.org).
 
Последнее редактирование:

Olej

New member
Сообщения
979
#5
Первая ссылка по XGI Volari Z7 + linux
ТС, я надеюсь, что вы ещё не успели воспользоваться изложенной там "рекомендацией" по ручной правке xorg.conf?
Потому что механическое применение такой правки (перенесенной из чужого дистрибутива), не разобравшись что сейчас у вас происходит, приведёт в наибольшей вероятностью к обвалу графической подсистемы 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
Строку modeline (Coordinated Video Timing), которую нужно задать для определения новой моды, не выдумываете вручную, у вас есть 2 утилиты, определяющие эту строку:
Код:
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]
...
P.S. Подробнее, с примерами, можете глянуть здесь:
Разрешение монитора
Rapsberry Pi в проекте
РАЗРЕШЕНИЕ ЭКРАНА В LINUX
 
Последнее редактирование:

oko

New member
Сообщения
95
#6
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 копеек, не разобравшись в сути происходящего, ага...
 

Olej

New member
Сообщения
979
#7
Secundo, вы всерьез считаете, что проприетарные драйверы Nvidia, Amd и проч. компаний поставляются в виде сорцов в формате *.c/*.cpp? Вот эту хохму надо срочно залить на LOR...
С теоретиками из лоходрома я не стану обсуждать проблематику модулей ядра Linux. :ROFLMAO:
Вкус устриц хотелось бы обсуждать с теми, кто их пробовал.
© М.Жванецкий
P.S. А ваш любимый DKMS - это только один из способов компиляции и сборки модулей из исходников.
 

oko

New member
Сообщения
95
#8
to Olej
По вашей логике следует, что nouveau, поддерживаемый сообществом, не нужен - зачем? ведь NVIDIA поставляет свои драйверы не в бинарном виде, а в сорцах, которые может изучить и скомпилировать любой желающий...
Внимание! Рубрика "занимательная математика". Складываем "имеем устаревший драйвер под RHEL бородатого года" + "имеем Astra с конкретной и куда более современной версией ядра" и думаем, к чему я упоминул DKMS...
 

Olej

New member
Сообщения
979
#9
и думаем, к чему я упоминул DKMS...
Дружище!
Мы могли бы с вами поговорить о модулях ядра Linux...
- если бы вы понимали в технике написания модулей ядра хотя бы на уровне кружка "Умелые Руки" Дворца Пионеров...
- если бы вы за свою никчемную жизнь написали хотя бы один примитивный модуль ядра ... ну пусть бы это был хоть самый примитивный Hello World ...
- если бы вы понимали каким механизмом модули ядра связываются с именами API (точками входа) из /proc/kallsyms (или /boot/System.map-*) ... (подсказка для самых тупых: по абсолютным виртуальным адресам функций вызова - это всё объясняет ... но вам это всё равно ничем не поможет).

А поскольку ни 1). ни 2). ни 3). не имеют места быть - то как же мы с вами можем говорить о модулях ядра Linux, о драйверах, и с чем их там в Linux едят?
Смешно-с ... :eek:
 
Последнее редактирование:

Olej

New member
Сообщения
979
#10
Короче, это классическая проблема узкоспециализированного железа...
Со всей ответственностью предупреждаю ТС не слушать советы этого дегенерата, который свои "познания" черпает из Google - это для вас закончится полной переустановкой системы "с нуля".
 
Последнее редактирование:

Olej

New member
Сообщения
979
#11
следует, что nouveau, поддерживаемый сообществом, не нужен - зачем? ведь NVIDIA поставляет свои драйверы не в бинарном виде, а в сорцах, которые может изучить и скомпилировать любой желающий...
А если бы вы в своём убожестве хоть раз за многие годы заглянули внутрь в "драйвера" NVIDIA вида NVIDIA-Linux-x86_64-#.run, то заметили бы, что это shell-скрипт, в котором примерно от смещения ~0xB130 (+/-) лежит бинарная часть, из которой shell-скрипт именно и компилирует и собирает модуль ядра. Точно так же, как свои модули устанавливает и VirtualBox от Oracle (вида VirtualBox-6.0.10-#-Linux_amd64.run). Это просто такой искусственный трюк, предназначенный для скрытия программного кода, из которого собирается модуль (или модули).
А если бы вы дали себе труд наблюдать в консоли инсталляцию драйверов NVIDIA, то увидели бы, что это и есть самая натуральная компиляция-сборка теми же mske, gcc и т.д.

P.S. Неужели этого не мог бы понять любой, кто хоть раз бы это делал сам ... а не начитался предисловий в Google.
 
Последнее редактирование:

oko

New member
Сообщения
95
#12
to Olej
Еще раз:
  • читайте ограничения Astra Linux Special Edition в части установки стороннего софта (про особенности компиляции, про средства разработчика, про использование неизвестных бинарей, про запуск сторонних модулей);
  • читайте свою же фразу про "бинарную часть" драйвера от той же NVIDIA;
  • почитайте про драйвер видеоадаптера тов. 70mka и его ограничения;
  • включите наконец голову и язык совместно, а не раздельно.
Еще лучше найдите этот закрытый драйвер в старой RHEL, соберите его под Astra, подпишите, пробейте его добавление в дистрибутив с очередным обновлением - тем самым и людям поможете, и свою квалификацию подтвердите. Всяко лучше, чем просто ***деть на форуме, не правда ли?

ЗЫ Переход от "дружище" к "дегенерату" попахивает синдромом Туретта. Сочувствую вашим друзьям...
 

Olej

New member
Сообщения
979
#13
Переход от "дружище" к "дегенерату" попахивает синдромом Туретта.
Так это такой дружественный дегенерат ... из меленьких таких, меленьких начальничков ... плюгавеньких - там оно так, зачастую, и бывает...
Это - от снисходительности. ;)
 

Olej

New member
Сообщения
979
#14
читайте свою же фразу про "бинарную часть" драйвера от той же NVIDIA;
Давайте я для совсем тупых повторю целых 3 раза ... как для милиционера ;):
- в 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 параметрами - как загрузка или выполнение кода любого модуля может завершиться мгновенным крахом системы: глухо-немым и безнадёжным.
А поэтому, все модули ядра могут собираться только под совершенно определённое ядро (по версии, по подверсии, по сборке, по CONFIG, ...) + при любом изменении ядра все модули должны замещаться соответствующими версиями.
Для модулей из состава дерева исходных кодов ядра (kernel.org) это замещение за вас делает майнтейнер дистрибутива, комплектуя модули в комплекте с ядром.
А для любых сторонних модулей вы должны делать сборку. А DKMS (Dynamic Kernel Module Support) - это всего лишь фреймворк, который запускает сборку динамически при обновлениях ядра ... и ничего более - всё ту же сборку.
А поэтому, модули ядра (драйверы) в Linux могут присутствовать только в виде исходных кодов на языке C, для пересборки при любых обновлениях... и никак иначе!

Законспектировали? :p

P.S. Надеюсь что я не напрасно потерял время на "так много букаф", и кому-то поразумнее из изучающих Linux это тоже пригодится. :unsure:
 
Последнее редактирование:

oko

New member
Сообщения
95
#15
to Olej
"Ах ты идолище поганое, не ухвативши белого лебедя, а кушаешь" (с)
За новую простыню текста спасибо, конечно, но:
  • вы располагаете исходниками драйвера для xgi volari z7-z9, чтобы можно было собрать нужный модуль в Astra Linux Special Edition с применением dkms?
  • вы готовы протестировать собранный модуль на оборудовании тов. 70mka?
  • вы готовы собрать более-менее универсальный deb-пакет и опубликовать его для Astra Linux Special Edition, договорившись с разработчиками?
  • вы готовы после пройти с ним все круги сертификации при очередном апдейте?
Если вышеописанный результат > /dev/null, то совет с правкой xorg.conf куда полезнее рассуждений о милиционерах, дегенератах и "примитивном устройстве Linux"...

ЗЫ Бесплатный совет: перестаньте лезть с gentoo'шными приемами в ветку бинарного дистрибутива, в котором многие модификации в принципе запрещены политикой сертификации и требованиями инфобеза. Теоретический ликбез прекрасен, но не в том месте и не в то время, поймите наконец...
 

Olej

New member
Сообщения
979
#16
Конспектируй ... конспектируй... :LOL:
вы располагаете исходниками драйвера
Элементарно, Ватсон!
Там не нужно ничего "располагать" :unsure:
Там у "тов. 70mka" модуль ядра либо sys, либо vesa (в зависимости что там ему Astra Linux подсунула по идентификатору VID : PID), которые замечательно присутствую оба в стандартных исходниках ядра ... и "тов. 70mka" нужно всего лишь выяснить какой из 2-х модулей у него сейчас используется (прежде всего, чтобы не нагадить в своей графической системе).
Только "тов. 70mka", похоже, вопрос этот глубоко "до фени". (n)
 

Olej

New member
Сообщения
979
#17
то совет с правкой xorg.conf куда полезнее
А совет с правкой xorg.conf безусловно полезен (хотя это не единственный способ), но только последним шагом - когда всё уже выяснено + проверено + оттестировано в требуемом разрешении ... и только потом может быть правка xorg.conf, и только для того, чтобы найденные параметры сохранялись после перезагрузки.
 

oko

New member
Сообщения
95
#18
to Olej
За сим, любезный эникейщик, отправляю вас в багтрэк Debian. Для изучения проблематики vesa/sis при использовании xgi volari z7-z9. Когда вернетесь с пустыми руками, не забудьте указать, что это - классическая проблема узкоспециализированного железа...

Нет, у вас, конечно, еще есть шанс реабилитироваться. В частности:
  • найти в Сети старые исходники (в частности, энтузиасты нечто подобное на github выложили года 3 назад);
  • исправить поддержку Xorg;
  • скомпилить драйвер и потестировать его на Astra Linux Special Edition с соответствующим железом;
  • собрать инсталлятор с поддержкой dkms;
  • пробить его включение в состав дистрибутива.
Но вы же этого не сделаете, не так ли? К чему это, если можно просто по***деть на форуме, считая окружающих дегенератами?
 

Olej

New member
Сообщения
979
#19
считая окружающих дегенератами?
Всё. Хватит. Достал своим гундосеньем...
Не тянешь даже в основах самых ядра и модулей, от слова "ни бельмеса" - так лучше бы помолчал. Смешным не будешь на публике... как обоссаный
 
Последнее редактирование: