Протестите код

Great

Пиши в сообщения (wasm.ru), там обменяемся e-mail. ICQ нет.

 

PROFi

вывод графики с помощью (притом документированных) функций для работы с графикой -- секретная технология? В грубом приближении, всё тот же пример с lock'ом, только используются не функции directdraw, а win32k!Eng* и иже с ними. Разве что только необычное получение адресов функций, в частности всё то, что вокруг DrvCreateDeviceBitmap. Но это на секрет не тянет. Настоящий секрет в драйверах и видеобиосе карты.

на что ссылку, на описание DDI/GDI в DDK?

вообще-то под загрузкой и подразумевалась загрузка проги/драйвера, а не ОС.

 

_BC_

Тогда выведи чего нибудь на экран с помощью EngCopyBits .... и все станет на свои места.

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

_BC_ К сожалению с вашей стороны только слова, а с моей работающий пример, и как вы думаете в какую сторону сместится чаша весов.

Настоящий секрет в драйверах и видеобиосе карты. - Я тоже так думал, но универсальность такого подхода заслуживает критики. Раньше я тоже пологал, что зная железо (а уж его то я знаю хорошо) можно чего-либо добиться, но на дворе 2007 год...

А вот выжержки из форума:

PROFi
картинка появилась и система (6600 GT, ForceWare 94.24, XP SP2)

Картинка есть. Ati Radeon x300, w2k sp4.

6600 GT != Ati Radeon x300

 

надо внести ясность полную.

Изначально имелись определенные, так сказать, низкоуровневые методики вывода на экран в ring0, для которых ОС требовалась только для получения инфы на этапе инициализации, после чего можно было рисовать без участия ОС/драйверов. Ну разве что для r0-отладчиков еще возможно актуален перехват некоторых функций, для отслеживания изменений в видеорежиме.

И этот способ был относительно универсален, пусть и с некоторыми недостатками -- на примере SI, cудя по жалобам на форумах (хотя лично я за 8 лет пользования и установки winice/ntice на множество компов ни разу не сталкивался с какими-либо проблемами несовместимости, ни с видео, ни с чем-либо).

И вот тут появляется geforce 8xxx, на которой не работают (судя по твоим словам) SoftICE и Syser, якобы из-за "карт с защитой контента от копирования" (smells like bullshit).

Но если рисовать "по-правильному", c lock'ом surface'a в директдрав, то всё вроде как работает. Также как и нормально работает весовский LFB.

Логичным было бы в первую очередь узнать, что надо сделать, чтобы всё работало как раньше, либо узнать в чем дело, и постараться адаптироваться к новым условиям, сохранив совместимость со старым методом. Эта сторона, как я понял, тебя совсем не прельщала. ;( Вместо этого ты перешел на уровень выше -- функции типа DrvCopyBits и EngLockSurface.

Истинная же причина судя по всему так и осталась неизвестной. "Видеопамять стала нелинейной" -- совсем не звучит.

вся эта секретность с удалением ссылок и умалчиванием принципа работы несколько страннА.

Ну что ж, тебе придется подождать, пока мне в руки не попадет эта пресловутая gf 8800. Весна покажет, кто где гадил. Но априори могу сказать, что в моем методе не будет Eng*, Drv*-функций и фоток твоей жены.

 

_BC_

Если у меня был бы только этот файлик, то этого уже было достаточно, для того чтобы понять почему и как и дезассемблировав его (а ты видимо это уже сделал) я приблизился к поставленной задаче месяца на 1,5 - 2.

Теперь более подробно. Я уже сказал, что это лишь часть технологии (универсальную я не выложил, в ней действительно нет Eng* функций, вот только без Drv*-функций не обойтись) в принципе все сложно и просто DirectDraw + Lock (1998 год еще мною реализовано, и как я заметил делает видеопамять линейной на GeForce 8), так вот Aero при пользовании этого метода сразу идет в аут.

Истинная же причина судя по всему так и осталась неизвестной Если она для тебя осталась неизвестной, то по-видимому обязательная аппаратная поддержка DirectX 10 (в часности 2D операций) недостаточно изучена Вывод в окно может быть тоже аппаратным, вплоть до аппаратной поддержки регионов. Дальше окно памяти данное видеопамяти (могу говорить пока только про XP) равно 256 Мб, даже если у тебя на карточке 1Гб, и следовательно вся видеопамять не может быть отображена одновременно (см PCIe конфигурационную область).

Ну что ж, тебе придется подождать, пока мне в руки не попадет эта пресловутая gf 8800. Весна покажет, кто где гадил. Быть первым, быть вовремя, а время говорит не в твою пользу...

Поскольку Вот что получилось - это конечно не готовый проект, но возможностей сулит много. Выкладывать на публичных форумах данную технологию нехочу. Основное предназначение - современные видеокарточки с защитой от копирования контента. (кстати это основное препятствие для Syser и SoftICE) Если интересно могу выслать исходники. связаться со мной знаешь как. Но вышеприведенная цитата приведенная здесь мне не понравилась.

PS: а жена то в чем виновата.

 

PROFi

да, я разобрал его целиком, как только скачал -- любопытство. Но сразу не особо вдавался в подробности работы, и сейчас понял, что слегка поспешил в оценках -- основная workhorse в твоем драйвере не EngLockSurface, а DrvCopyBits, которая блитит в primary surface из вспомогательной bitmap-поверхности, в которую собственно и осуществляется вывод картинки. Я при беглом первом просмотре сперва подумал на получение primary surface-->lock-->вывод сразу в нее. Проблема очевидно заключалась в потребности в HSURF, когда на руках имеется только SURFOBJ?

там в принципе что Eng, что Drv -- всё едино. Если ты смотрел nv_disp, то д.б. видеть, что он в своих табличных DDI-функциях очень сильно опирается на Eng*-функции. Те же DrvCopyBits/DrvBitBlt могут вызывать EngBitBlt. Сама по себе DrvBitBlt довольно высокоуровневая функция, для применения в отладчике может оказаться непригодной.

Я больше склоняюсь в сторону хардварного варианта. В идеале вообще не трогающий ОС (ну разве что mmmapiospace для видеопамяти). Сейчас к счастью нет вавилонского столпотворения с видюхами от разных производителей, можно ориентироваться только на ati и nvidia. Что еще хорошо, так это то, что 2D-часть особо не развивалась, и между картами в пределах вендора по идее должна быть хорошая совместимость для 2D.

Пока с нвидией есть определенные наработки, почерпнутые от разбора VBE-части videobios'ов с geforce'ов. Судя по тем, что ковырял, между моделями есть некоторая совместимость -- для тех регистров, которые собственно и пригодятся для вывода графики. Самый новый из видеобиосов, что смотрел -- от 7900GS (моя текущая карта). Ща попробую эти наработки опробовать в деле. Абсолютно все параметры, адреса и смещения берутся от железа, никакой нужды в какой-либо инфе от ОС. От ОС только маппинг для видеопамяти. Сейчас весьма интересуют эти самые geforce 8, поэтому есть вопрос -- ты можешь сдампить и приаттачить сюда videobios со своей gf 8xxx? За неимением самой карты может весьма пригодиться. Или кто-нть, у кого тоже есть geforce 8xxx (чем новее, тем лучше).

 

_BC_

Я пользовал лет 5-6 твой подход, но он не универсален, думаю через пару месяцев поймешь (кстати на Matrox твой подход будет в ауте).

Далее EngBitBlt - абсолютно бесполезна, если ты не видишь разницы между функциями Eng и Drv на СОВРЕМЕННЫХ карточках, то месяцы исследований впереди не миновать.

ты можешь сдампить и приаттачить сюда videobios со своей gf 8xxx? - сюда или на другой e-mail Кстати как насчет жаббера

Могу конечно, простой дамп diskedit.exe тебя устроит? Если нет - то выложи ссылку на nvflash (у меня затерялась) и сдамплю полный код. (Блин Вот только от Inet отключаться нужно)

 

как-то не так понял мое сообщение. Изначальный смысл был в том, что Eng* и Drv* не разделены пространством и временем, а тесно переплетаются. Когда ты вызываешь Drv-функции из nv_disp, то неявно вызываешь и целую кучу Eng*-функций из win32k.sys. DrvCopyBits является урезанной версией DrvBitBlt и в обеих вызовов Eng* -- просто навалом. Это относилось к твоему

мне нужен сегмент C000. Сдампить можно debug.exe --
в ком.строке
debug < dmp_C000.txt

файл dmp_C000.txt:

Код (Text):

1. rcs
2. BFF0
3. rcx
4. FFFF
5. n VGA_BIOS.dmp
6. w
7. q

 

_BC_

http://ffdown.ifolder.ru/3800780

Да удали по ненадобности

http://ffdown.ifolder.ru/control/?file_id=3800780&code=aa8a21a368295d1b04ac15266a9c50d0

 

мда, многое кардинально поменялось. До geforce 8xxx всё было более-менее совместимо, по крайней мере та часть, что отвечает за работу с фреймбуфером, не менялась начиная с самых ранних карт. Получается, что на нвидиях теперь как бы 2 типа (поколения) карт с точки зрения прямого вывода 2D-графики -- всё что до 8xxx, и соответственно всё что после -- на 8ххх набор регистров сильно поменялся. Также есть и ряд других minor changes.

Теперь в частности адрес primary surface складывается из 3х составляющих:
- база видеопамяти
- начало фреймбуфера в видеопамяти
- смещение primary surface от начала фреймбуфера

На предыдущем поколении второго слагаемого не было, фреймбуфер начинался прямо с начала видеопамяти, положение primary surface определялось только смещением начала и базой видеопамяти.

В смене регистров на 8ххх вообщем-то нет ничего особенного, странно что это не сделали гораздо раньше. То, что было вплоть до 7900* -- продержалось х.. знает сколько лет, начиная с допотопных моделей карт. И там были некоторые ограничения, например, судя по реализации VBE, смещение начала primary surface задавалось в виде 24-битного числа, что ограничивало диапазон. Конечно, теоретически, это может быть чисто программное ограничение нвидиавской VBE, и что где-то в регистрах есть и старший байт -- но факт, что на 8ххх это смещение -- уже полноценный DWORD. И получается он гораздо проще, чем на предыдущем поколении карт -- по байтам. На прошлом оно собиралось по битам, как и многие другие значения, разбросанные по куче регистров. Поэтому нет ничего странного, что нвидия решила наконец-то навести порядок в регистрах. Этот DWORD кстати снимает ограничение на кол-во back buffer'ов -- теперь их теоретически может быть сколько угодно.

Различать же эти 2 поколения можно по методу разлочки расширенных регистров CRT -- он тоже сменился на 8ххх. Судя по видеобиосам, на нвидии BAR в pci conf для базы видеопамяти находится в +14h -- для всех карт до gf8xxx, и в +1Ch -- для 8xxx. Он там на твоей карте?

Ща попробую адаптировать для 8ххх и посмотрю что из всего этого получится... Надеюсь, что попрет и на 8ххх.

ок, удалил. В принципе ничего приватного там нет, можно было и оставить. По дампу можно только узнать, что у тебя 8800GTS от ASUS, Jmicron IDE/SATA Controller (с поддержкой RAID) который часто ставят на MB с ICH8/9, на которых сам ICH не поддерживает IDE. Я бы поставил на то, что у тебя мать с чипсетом P965. Также у тебя возможно 20Гб винт от Seagate -- ST320011A и привод NEC DVD-RW ND-3540A -- судя по оставшемуся в JMicron'овском option rom'е мусору, возможно после детекта.

 

Итак, тестовая прога №1. Целевая аудитория -- все карты нвидиа (ну разве что м.б. кроме самых древних).

Для работы с видеокартой использует только маппинг для видеопамяти, ни Eng*, ни Drv*-функций не используется.

Получает всю инфу для работы от железа. Рисует напрямую в фреймбуфере (2 красные линии крестом, перекрещивающиеся в центре экрана). Пока сделал поддержку для TrueColor (32bpp) и HiColor (16bpp). 8 бит тоже можно легко добавить, просто лень с поллитрой возиться. Поддержка планарных режимов в принципе нах никому не нужна, такой геморрой из-за 16 цветов и врагу не пожелаешь.

В первую очередь при тесте внимание надо обратить на корректность получения инфы с железа. Берется следующая инфа:

- VID/DID видеокарты и ее координаты в pci configuration space
- по ним определяется производитель и модель карты (пока, повторюсь, всё для нвидии)
- разрешение экрана по горизонтали
- разрешение экрана по вертикали
- число бит на пиксел
- база фреймбуфера
- смещение primary surface
- pitch

Если инфа на вид правильная, то можно попробовать вывод в видеопамять. Должны появиться 2 красные линии, если всё ок. Если появилось что-то непохожее на красный крест -- просьба заслать скриншот всего экрана, вместе с окошком тестовой проги. Тестить надо по-хорошему во всех режимах, в 16 и 32 битах. Особенно в "нестандартных" типа 1152 x 864 -- в этих режимах pitch отличается от width*bytes_per_pixel, поэтому должны обламываться методы, которые не используют pitch для перехода между строками.

На 8ххх не отлаживал и не тестил, с некоторой вероятностью на них может не сработать именно из-за человеческого фактора, т.е. меня. Нету к сожалению ни у кого поблизости 8х geforce'ов, не на чем попробовать. ;(

Из внутренних ограничений -- для 8ххх пока макс. поддерживаемая ширина экрана -- 2048 пикселов, но этого думаю вполне достаточно.

Если это дело нормально пойдет, то можно добавить поддержку ATi и прочих (хотя на данный момент внимание уже стоит обращать только на нвидию и ати, остальные уже раритет, разве что для ноутов что-нть еще найдется распространенное). С учетом того, что в пределах вендора различия между картами (с точки зрения вывода 2D-графики без ускорения) редки, есть хорошие перспективы. Извлечение нужной инфы из videobios'а карты делается довольно быстро, если знать где и что искать. Как плюс, нет зависимости от ОС. Один и тот же метод будет работать как на 9х, так и на NT/2K/XP/2K3 и Висте.

Сорцы выложу после сбора некоторой статистики по работоспособности метода, а то мало ли, вдруг она только у меня идет. Хотя по идее должно работать как минимум на картах до 8ххх.

А, еще одно -- на вмваре, как выше упоминалось, такие вещи нельзя тестить. Вмваре после установки своих SVGA-драйверов мухлюет при эмуляции видео, для ускорения работы. Целиком эмулировать фреймбуфер и тп -- слишком накладно с точки зрения производительности.
[see newer version below]

 

GeForce 3 Ti200 - ok
GeForce 7900 GTX - просто тупо не запускается. думаю дело не в видеокарте.

А ты не учитываешь тот момент, что немалый процент занимает встроенное видео?

 

возможно что она уже близка к 8ххх по регистрам, и баг в неотлаженной 8ххх-части. Надо дождаться PROFi, я 8ххх-метод по videobios'у с его карты делал, можно будет точно сказать.

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

да, их тоже учитываю. Пока всё относится к картам нвидиа.

added: а какой режим экрана на системе с 7900GTX?

 

+1 - тупо не запускается.... на древнюююющей GF4MX440@128mb

WinXP.SP2.Pro.En.Nov.2006



upd:
На 8800 GTS выдала “An Error occured while drawing”

 

_BC_
на старушке gf2/mx400 под хр2 ОК
в нестандартных режимах тоже ОК

 

посмотрел, вроде на всё более-менее критичное есть вывод ошибок, разве что на сам вызов DialogBoxParamA еще добавить можно. Возможно какая-то несовместимость, что просто тупо не запускается.

во, вот это уже хороший знак. Не прошла разлочка расширенных регистров, ожидаемый баг. Пока на 8ххх можно не тестить, ща буду разбираться с ними. Тока на карте PROFi можно для верности опробовать.

Выкинул манифест и добавил еще одну проверку. Если всё равно молча не запускается, значит похоже винда ее тупо не грузит на определенных компах. ;(

[see newer version below]

 

ОK, manifest done the tricк

На GF4 - всё ОК, 800x600 / 1024x768, True и HighColor.

Биос от 8800 GTS нужен?




оффтоп:
Кстати, с кривым манифестом вообще надо быть осторожнее... Моя прога, например, запускалась, создавала окно и контролы… Но элементарный MessageBox просто не появлялся на экране. Возвращает 0, а появляться - не появляется, будто и не вызывали.

 

G13

Отлично, значит одно из двух, либо у меня манифест действительно корявый, либо на некоторых компах всё-таки нужен вызов InitCommonControls. Я его закомментил, т.к. работало и без него. Ща вернул манифест обратно и добавил вызов InitCommonControls.

Переделал разлочку, теперь практически 1:1 с видеобиоса, можно пробовать на 8ххх. Самое важное на них сейчас -- прочитать правильную инфу с железа, даже если вывод линий загов..тся, то это не страшно -- значит действительно есть определенный механизм, который необходимо задействовать, чтобы получить доступ со стороны проца к фреймбуферу. Останется только этот механизм найти.

Попробуй эту версию, если инфа от железа изменится -- также желательно скриншот окошка проги сделать.

Видеобиос от 8800GTS не нужен -- у меня он как раз от нее.

[see newer version below]

 

На 8800 всё то же самое - см. первый скриншот.

С манифестом и появившимся в импорте InitCommonControls всё заработало. =)

 

G13
мда, без карты под рукой будет тяжко.

вот тест специально для 8ххх -- выводит обнаруженный метод и hard-coded на работу в методе 2 (8ххх).

Если выведет метод 1 -- значит баг в определении метода работы с картой.

Видеобиос на всякий случай можешь приаттачить, гляну.

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

[attach deleted]