"Jon M. Taylor" wrote:
Antonio Campos wrote:
1) Installing KGI is not an easy task. (It only supports a few cards).
_Running_ KGI is not an easy task, because it only supports a few
cards. Installing it is actually pretty easy, unless you don't already
know about kernel
Steffen Seeger wrote:
Antonio Campos wrote:
People want an OS for accesing the hardware in a clean, fast and reliable way.
That includes the graphics hardware. And I must say that this handling is one of
the most important tasks in modern operating systems (and one of the things that
On Tue, 21 Nov 2000, Antonio Campos wrote:
Steffen Seeger wrote:
Antonio Campos wrote:
People want an OS for accesing the hardware in a clean, fast and reliable way.
That includes the graphics hardware. And I must say that this handling is one of
the most important tasks in
Lee Brown wrote:
Antonio:
People want an OS for accesing the hardware in a clean, fast and reliable way.
That includes the graphics hardware. And I must say that this handling is one of
the most important tasks in modern operating systems (and one of the things that
the user sees more
Stefan Seefeld wrote:
Lee Brown wrote:
Perhaps you can clue me in. I still don't
understand the difficulty in accessing video memory. The fbdev already mmaps
all of video memory. There it is. Let people have at it.
may be you should play with DOS, pre protected mode. (remember ?)
Lee Brown wrote:
On Sat, 04 Nov 2000, Stefan Seefeld wrote:
Lee Brown wrote:
Why can't we just let the client (Stefan) draw to the offscreen part
of the framebuffer?
had you followed the recent discussion, you would know. As always, GGI's aim is
to insulate h/w specifics from the
Lee Brown wrote:
Perhaps you can clue me in. I still don't
understand the difficulty in accessing video memory. The fbdev already mmaps
all of video memory. There it is. Let people have at it.
may be you should play with DOS, pre protected mode. (remember ?)
Here is your memory, do what
"Jon M. Taylor" [EMAIL PROTECTED] writes:
On 3 Nov 2000, Marcus Sundberg wrote:
"Jon M. Taylor" [EMAIL PROTECTED] writes:
On Thu, 2 Nov 2000, [iso-8859-1] Niklas Höglund wrote:
At that time I found that using a main loop looking like this does sort of
proper double-buffering
what is the support for offscreen video memory allocation ?
I'm not sure I use the correct terminology, so here is what
I have in mind:
Why can't we just let the client (Stefan) draw to the offscreen part
of the framebuffer? I wrote a little demo (with minor changes to the fbdev
code) program
On Sat, 4 Nov 2000, Lee Brown wrote:
what is the support for offscreen video memory allocation ?
I'm not sure I use the correct terminology, so here is what
I have in mind:
Why can't we just let the client (Stefan) draw to the offscreen part
of the framebuffer?
There may not
"Jon M. Taylor" [EMAIL PROTECTED] writes:
On Thu, 2 Nov 2000, [iso-8859-1] Niklas Höglund wrote:
At that time I found that using a main loop looking like this does sort of
proper double-buffering using GGIMesa. Note that the SetMode call sets the
virtual width to twice the physical width.
On Fri, 3 Nov 2000, Stefan Seefeld wrote:
"Jon M. Taylor" wrote:
I might know when allocating visuals (drawing buffers) that some are
updated more frequently than others, i.e. they would profit much more
from being close to the graphic card. Is there (or could there be) any way
to
On Tue, Oct 31, 2000 at 01:59:37PM -0800, Jon M. Taylor wrote:
On Mon, 30 Oct 2000, beef wrote:
On Sat, 28 Oct 2000, Jon M. Taylor wrote:
It kindof works, but flickers horribly on the fbdev.
what/where _could_ this doublebuffer problem be?
So, I did a QuickHack(tm) to work
This brings up another interesting point:
what is the support for offscreen video memory allocation ?
I'm not sure I use the correct terminology, so here is what
I have in mind:
There is often a need to double buffer content in some form,
and map (blit) it into the screen at specific times. Of
Stefan Seefeld [EMAIL PROTECTED] writes:
This brings up another interesting point:
what is the support for offscreen video memory allocation ?
I'm not sure I use the correct terminology, so here is what
I have in mind:
There is often a need to double buffer content in some form,
and
It is *NOT* the way, and will never be!
The correct way is to use the not-yet-written blitting extension,
so you can get hw accelerated blits when supported.
Umm - good point ... Marcus: We should talk about the region management once
again ... and finally implement it. I have stubs for blit
On Thu, 02 Nov 2000, Marcus Sundberg wrote:
Stefan Seefeld [EMAIL PROTECTED] writes:
It is *NOT* the way, and will never be!
The correct way is to use the not-yet-written blitting extension,
so you can get hw accelerated blits when supported.
What would the extension API look like?
Thanks
Scratch that last question. I see the X documentation.
--
Lee Brown Jr.
[EMAIL PROTECTED]
On Thu, 2 Nov 2000, [iso-8859-1] Niklas Höglund wrote:
On Tue, Oct 31, 2000 at 01:59:37PM -0800, Jon M. Taylor wrote:
On Mon, 30 Oct 2000, beef wrote:
On Sat, 28 Oct 2000, Jon M. Taylor wrote:
It kindof works, but flickers horribly on the fbdev.
what/where _could_ this
On Thu, 2 Nov 2000, Stefan Seefeld wrote:
This brings up another interesting point:
what is the support for offscreen video memory allocation ?
I'm not sure I use the correct terminology, so here is what
I have in mind:
There is often a need to double buffer content in some form,
and
"Jon M. Taylor" wrote:
I might know when allocating visuals (drawing buffers) that some are
updated more frequently than others, i.e. they would profit much more
from being close to the graphic card. Is there (or could there be) any way
to expose some policy issues like these through an
Quoting "Jon M. Taylor" [EMAIL PROTECTED]:
Yep, that's what I'm seeing as well. I haven't been able to track
down the problem yet. For now, I am hacking around the problem by
manually editing Mesa/src/GGI/libMesaGGI.la and changing the line that
reads:
dependency_libs='
On Mon, 30 Oct 2000, beef wrote:
On Sat, 28 Oct 2000, Jon M. Taylor wrote:
I just committed a bunch of GGIMesa fixes to the Mesa CVS tree. It
_should_ all build just fine again, but I have weird libtool and autoconf
incompatibilities popping up which are preventing the final library
"Jon M. Taylor" wrote:
I just committed a bunch of GGIMesa fixes to the Mesa CVS tree. It
_should_ all build just fine again, but I have weird libtool and autoconf
incompatibilities popping up which are preventing the final library
install so I can't test it over here. If someone
I just committed a bunch of GGIMesa fixes to the Mesa CVS tree. It
_should_ all build just fine again, but I have weird libtool and autoconf
incompatibilities popping up which are preventing the final library
install so I can't test it over here. If someone else could test it for
me,
If any of you have been playing with the newest GGIMesa CVS
sources, you probably noticed that they don't build due to internal Mesa
changes. Well, I just fixed those problems and GGIMesa CVS now builds
(against the latest GGI CVS) and runs again. The only functional changes
are a
26 matches
Mail list logo
