Board.KolibriOS.org

Я переделал дизайн отображения списка режимов. Вы можете скачать последную мою сборку ядра с моего сайта lrz.land.ru . Можно загрузиться, сохранять настройки в синем экране загрузки.
Не работают режимы:
320x200, EGA/CGA 256 цветов
640x480, VGA 16 цветов
и остальные которые имеют битность на цвет менее 24 бит
Из ядра не совсем корректно работает выход на синий экранчик.
+ Мелкие баги. Предложения и высказывания прошу оставлять тут или в личных сообщениях, можно на мыло.
Спасибо!

Настройки сохраняет в голубом экране.
Работает, я не все режимы проверял. Но на некоторых точно работает.
И это в QEMU с видеокартой Вуду 4Мб, т.к. моя навороченная накрылась. Никакие больше оси не запускаються в QEMU, включая Менует. Только Колибри.

<Lrz>
Как насчёт того, чтобы спрятать разрешения выше 1280х1024? А то у меня в выборе разрешений на х1600про появляются разрешения, которых нет в винде(максимум 1280х1024). Монитор LCD.

Прикрепил ещё один дамп.

Maxis
Думаю не стоит убирать их из за того что тебе так хочется, а винда покажет тебе и их если убрать галочку "показывать только поддерживаемые". О поддерживаемых монитором режимах винда узнает или из драйвера монитора (который фактически только это и умеет говорить и устанавливать цветовой профиль, впрочем его рдко кто ставит) или через драйвер видеокарты котороый читает режимы через DDC которого в обозримом будущем в Колибри не будет (шина DDC рабтотает поверх i2c и сильно зависит от производителя и модели видеокарты).

P.S. Возможно если сильно попросить Serge он сделает это для карт ATi/AMD которыми он сейчас вроде занимается.

Ghost

Да, для драйверов будет I2C и DDC. Но на загрузочном экране это никак не отобразится.
В том что написал Maxis есть смысл. Хорошо показывать все режимы на этапе отладки кода, но сейчас их ИМХО слишком много. Лучше спрятать режимы которые не поддерживаются. Есть ещё одно замечание. Видимо сохраняется номер видеорежима. В Bochs и Qemu номера не совпадают. Если попеременно загружать один образ приходится всё время править режимы. Это конечно не проблема, но неудобство. И дефолтный видеорежим в дистрибе теперь будет привязан к видеокарте разработчика.
А в остальном новый загрузочный экран стал намного удобнее.

мм.. а может вместо убирания неподдерживаемых видеорежимов сделать поддержку этих видеорежимов?) я про режимы с разрешением свыше 1280*1024.. в каких именно компонентех системы загрузка с бОльшим разрешением вызывает ошибку?

Gluk
Ошибки никакой нет, речь идет от том что большинство современных домашних LCD мониторов поддерживают максимум 1280*1024 в то время как видюхи умеют выдавать и бОльшие (например моя древняя FX5200 и та умеет 2048*1536) и обсуждается - имеет ли смысл выводить эти бОльшие разрешения.

Serge
Мдя, как то я поторопился с DDC в RM. НО! Есть такие мысли, недавно я разговаривал с diamond`ом по поводу реализованнво им V86 и возможности переключать через него видеорежимы, он сказал что во время тестирования он успешно переключался в текстовый режим и обратно в PM. Так вот, если напрячься то можно сделать загрузку например в режиме 800*600 а потом уже в PM (с загруженными дровами) выбирать режим, вот такие мысли )).

P.S. Если будет I2C то как минимум можно будет достучатся до hardware monitor`а а в программе максимум и до PLL что возможно добавит к пользовательской аудитории и оверклокеров...

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

Ghost

Я тоже думал о таком применении V86. Нужен стандартный интерфейс для SetMode(). Жаль что через Биос нельзя установить частоту.

PLL можно программировать и без I2C. Номера регистров есть, вероятно там и для чипа/памяти, но описаний нет, а для xorg разгон на последнем месте в списке приоритетов.

Serge
Для карт nVidia про PLL пожно почерпнуть здесь, для них действительно через i2c работют только дитчики и DDC. Но для Ati помойму в качестве PLL используются микрухи от ICS а они уже на двух проводной шине... хотя могу и ошибатся. В общем завязываем эту тему.

Думаю дужно придумать этот стандартный интерфейс, а частоту по хорошему дрова видюх должны выставлять. (жаль что пока работы только над ATI ведутся, хотя я смотрел x11-nv дрова, там не сложнее чем для ATi, но нету сейчас у меня времени)))

Ghost

У меня такая идея
struct Mode
{
short width;
short height;
short bpp;
short freq;
}
SetMode(width,height,bpp,freq); Для Vesa последний параметр будет игнорироватся.
или SetMode(struct Mode*)

Еще понадобится int EnumModes(struct Mode*,size_t size)
первый параметр - указатель на буфер со списком режимов, второй размер буфера. Возвращаемое значение - количество режимов.

Тогда список можно получить за два вызова - первый раз size=0, получаем количество режимов, выделяем память и уже читаем список полностью.

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

P.S. Если переключать режимы в PM то сразу нужно делать и поддержку отрицательных координат, и выход окон за размер экрана.

Ghost

Большой список только на CRT и с родным драйвером. В VESA и на многих LCD только 60 Гц. Если частоты давать отдельно то будет путаница. Например CRT с развёрткой 100КГц держит максимум 800*600-120Гц. 1024*768-90Гц. 1280*1024-85 Гц 1920*1440-60Гц.
А ещё есть чересстрочные режимы с частотой ниже 60 Гц. Всё равно для каждого разрешения придётся давать свой набор частот.
Так вся информация помещается в два регистра. В одном (height<<16)|width во втором (freq<<16)|bpp.

По дефолту грузиться разрешение 1024х768@32 бита. Если этого нет проверяется доступность режимов по нисходящей. Если вы сохранили настройки видеорежима, то записывается указатель на карту режимов, специфичную индивидуально для вашей видеокарты. Соответственно, если вы перенесли образ на другую машину или даже используете другую видеокарту, то карта режимов будет уже другая, а смещение то для старой видеокарты. Если смещение выходит за предел доспупных диапазонов новой видеокарты, то устанавливается дефолтное значение 1024х768@32 и ниже под подступности режимов. Так что это не недостаток, а фитча. Я могу прикрутить проверку типа видеокарты, и при не совпадении сбрасывать значения на дефолт. Но это будет при реализации secondary boot. Так же решится проблема с загрузкой различных носителей. Загрузка не будет привязана только к определенному носителю или к образу.

А если монитор не поддерживает 1024x768? Например у меня есть старый монитор который максимум что умеет 800x600@60... Хотя такие сейчас рееедко встретиш.

Serge
Может параметры передавать через stdcall? Хоть это и странно для ассемблерной системы, но намного практичнее и удобочитабельно.