MPlayerXP-0.6.0 has been released

> Так никто и не сказал, как именно mplayerXP работает с VESA, кстати.
ОК, сам нашёл, разве от ЛОРовских спецов дождёшься... :)
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-June/019359.html

Я, кстати, знаю даже, в чём у lrmi траблы с linuxthreads и почему
глючит со старыми ядрами. Странно, что разрабы не знают до сих пор...

vesatng работает через VBE3 , а там есть protected mode interface.

> vesatng работает через VBE3 , а там есть protected mode interface.
Нда... Как я и говорил, всегда приходится гуглить самому, от ЛОРовских
спецов мало чего дождёшься. :)

---
Vesafb-tng is available only on 32-bit x86 due to the
technology it uses (vm86).
---
http://dev.gentoo.org/~spock/projects/vesafb-tng/archive/vesafb-tng-1.0-rc2-g...

Starting with VBE/Core 3.0, all the VBE functions are optionally accessible from 16-bit and 32- bit protected mode applications and operating systems via a new ‘Protected Mode Entry Point’. The protected mode entry point defines a special location that can be used to directly call the VBE functions as 16-bit protected mode code.

--- VBE3 specs.

>Vesafb-tng is available only on 32-bit x86

Верно ибо вызываемый код 16-битный, но protected mode.

>due to the technology it uses (vm86).

сцылку кинь на их патч. Ща посмотрю

> --- VBE3 specs.
Даже если вы и назовёте функцию VBE3, которая позволяет менять режим,
не используя int10h (можете назвать? не охота снова гуглить), то всё
равно речь шла именно про vesafb-tng, а не о чём-то ещё.

> Верно ибо вызываемый код 16-битный, но protected mode.
И по этому юзается vm86? Почти смешно...

> сцылку кинь на их патч. Ща посмотрю
А в прошлом постинге я что сделал? Не на патч ли ссылку кинул,
откуда и цитата была?

>Даже если вы и назовёте функцию VBE3, которая позволяет менять режим, не используя int10h

прочитайте _внимательно_:

all the VBE functions are optionally accessible from 16-bit and 32- bit protected mode applications

_ALL_ !!

>И по этому юзается vm86? Почти смешно...

А он не должен юзаться. Зачем это делают разработчики vbe3 - хз.

> all the VBE functions are optionally accessible from 16-bit and 32-
> bit protected mode applications
> _ALL_ !!
Слабо верится. Ладно, погуглю снова, может чего нарою.

>> И по этому юзается vm86? Почти смешно...
> А он не должен юзаться. Зачем это делают разработчики vbe3 - хз.
При чём тут разработчики VBE3??? Это разработчики vesafb-tng.

>Слабо верится. Ладно, погуглю снова, может чего нарою.

вот спеки.

http://www.webfile.ru/1131548

>При чём тут разработчики VBE3??? Это разработчики vesafb-tng.

сорри s/vbe3/vesafb-tng/g

>> _ALL_ !! > Слабо верится. Ладно, погуглю снова, может чего нарою. А, не зачем. И так ясно, что чтобы получить PM точку входа, всё равно надо вызвать int10h скорее всего, вот и vm86.

>> _ALL_ !!
> Слабо верится. Ладно, погуглю снова, может чего нарою.
А, не зачем. И так ясно, что чтобы получить PM точку входа, всё
равно надо вызвать int10h скорее всего, вот и vm86.

Это можно сделать до загрузки ядра. vm86 не нужен.

> gcc: /usr/local/lib/mplayerxp/codecs/: No such file or directory make[2]: *** [libavutil.so] Ошибка 1

Блин, они ещё и симлинки предлагают плодить на кодеки для нормального mplayer? Предлагаю лучше собрать mplayer из svn:

$ svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer $ ./configure --enable-gui $ make # make install

почти каждый день что-то да исправляют ;)

> Это можно сделать до загрузки ядра. vm86 не нужен.
Не важно - она его юзает. Считаю этот факт доказаным и очевидным.

Посмотрел код.

какого х..

+ * Framebuffer driver for VBE 2.0+ compliant graphic boards.
+ * Kernel thread and vm86 routines.


> доказаным 

ну да //где-то читал что vesa-tng полностью vbe3//


>очевидным

только после просмотра исходников.

> Делаем раз: программа обработки двух массивов работает последовательно с каждым из них. Вопрос - будет ли приращение производительности при переходе с однопроцессорной системы на двухпроцессорную ?

> Делаем два: программа обработки двух массивов запускает два потока, которые выполняются параллельно и каждый из них обрабатывает свой массив. Вопрос тот же - будет ли приращение производительности при переходе с однопроцессорной системы на двухпроцессорную ?

Буду краток: под вендой как ни крути - по любому все повиснет нахер.

> ну да //где-то читал что vesa-tng полностью vbe3//
Не передёргивайте.

---
With VBE 3.0 compatible BIOSes and vesafb-tng it is possible to change
the refresh rate either at boot time (by specifying the @<rr> part of
the mode name) or later, using the fbset utility.
...
* If you're running a non-vm86 and VBE 3.0 compatible system, you can
use a kernel patch (vesafb-rrc) to hard-code some mode timings in
the kernel and use these while setting the video mode at boot time.
---

Т.е. вполне очевидно, что даже для VBE3 требуется vm86 во всю.

>VBE3 требуется vm86 во всю.

из этого только следует,что автор патча не написал полную поддержку VBE3

> из этого только следует,что автор патча не написал полную поддержку
> VBE3
Крайне маловероятно, так как это лишает его патч портируемости.
Надо быть идиотом чтобы пойти на это добровольно.
И везде он пишет without vm86 it is impossible to do this and that,
а не I have not implemented this yet.

>так как это лишает его патч портируемости.

да он и так не портируемый, ибо код , вызываемый через protected mode interface 16-битный.

>И везде он пишет without vm86 it is impossible to do this and that

Это относится к VBE2

> да он и так не портируемый, ибо код , вызываемый через protected mode
> interface 16-битный.
Это мелочи - на x86_64 16битный код защ. режима вызывать можно,
проблема _только_ с vm86.

с 16 битным кодом защ. режима в x86_64 есть некоторые проблемы.

В спеках на VBE3 четко и ясно написано , что _все_ функции, доступные через int10 доступны и через protected mode interface.

Другое дело, все ли производители придерживаются этих спеков.

> с 16 битным кодом защ. режима в x86_64 есть некоторые проблемы.
А именно?

никогда не пробовал, но 100% уверен что есть.

смотрите drivers/video/vesafb.c, все что связано с pmi, только для i386

* к примеру,с vm86 есть проблемы на smp (x86).

> смотрите drivers/video/vesafb.c, все что связано с pmi, только для
> i386
Это не 16-битный код. Это 32-битный код. На i386 вызывается ближним
call, а на x86_64 потребует создания 32-битного сегмента и дальний
вызов, т.е. просто потребуется небольшая доработка. Будь он
16-битный, и на i386 ближним вызовом бы не обошлось.

> * к примеру,с vm86 есть проблемы на smp (x86).
А это откуда? И на каком ядре?

> > Также он вроде умел параллелить процесс декодирования на несколько нитей (для всяких smp).

> smp-ядро уже изжило себя, и ни капельке не быстрее обычного.

На скольки процессорах проверял ? :-)

>А это откуда?

некоторые биосы некорректно выполняют int_xx, если код запущен на AP cpu.

Не знаю как это решено в Linux, но такая проблема есть.

32-битный код , VBE 2.0 ?

O_o

брррр... а название-то какое: "MPlayerXP"... хорошо хоть что XP - это не икспириенс, а екстра перпорменс.....

> 32-битный код , VBE 2.0 ?
Да, именно. PM-расширения биосов вообще редко 16-битными делают.
Для 16-битного PM-кода нужны сегменты, а какие именно - известно
только авторам этого кода, и значит надо как-то передать эту
информацию ОС, чтобы она эти сегменты создала. По этому делают
32-разрядный код с flat-адресацией, тогда ОС вызывает его обычным
ближним call.