On Wed, 27 Jun 2001, Andreas Beck wrote:
> > Could someone verify, if this is realted to XF86 Version, or to the graphics
> > driver, as all machines I have access to use Matrox G200/G400 ?
>
> Ha - I found one with an ATI chip. The ATI driver does _not_ exhibit said
> strange behaviour. I suppos
On Thu, 18 Oct 2001, Rodolphe Ortalo wrote:
> Well, sorry for bothering everyone on this but... it seems setting a
> linear LUT for the ramdac palette helps a lot... It was not 3D problem
> (16bpp is palettized in fact - I had forgotten that.)
Eh ? 16 bit palettized !?! Would this also solve my
On Sat, 13 Oct 2001, Brian S. Julin wrote:
> Heya,
>
> Just throwing this to the gallery for comments.
>
> We have three new lowlevel libraries which (along with LibGGIMISC)
> will be forming the core of the intermediate API for the GGI Project,
> LibBuf, LibBlt, and LibOvl.
Great... Congratulat
On Tue, 26 Nov 2002, Martin Albert wrote:
> Hi, Folks!
> Sorry, i sent mail yesterday with broken header, should be fixed.
Acknowledged, thanks...
Jos
On Tue, 17 Dec 2002, Christoph Egger wrote:
> What we need is something other do NOT have.
> libggigl and XGGI are a good examples. See Brian's mail and my
> next one for more details.
What you need is what you got __finished__. The focus should not be on
creating new things, but on finishing wha
On Sun, 5 Jan 2003, Andreas Beck wrote:
> Well I have a general idea, though nothing specific: You were using 32 bit
> modes, right? In that case, you might have BGRX vs. XRGB in the color
> schemes.
>
> This leads to sending B=ff G=ff R=ff X=00 for white, which gets interpreted
> as X=ff R=ff G=f
Hi,
KGI used to set a task to sleep when it was mapped away from a display.
This didn't work always, and with some help from #kernelnewbies, I came to
the conclusion that it isn't even what you want.
A task doesn't need to sleep, it only has to stop drawing. I came to a
very simple, but (imho) in
On Sun, 19 Jan 2003, Christoph Egger wrote:
> On Sun, 19 Jan 2003, Jos Hulzink wrote:
>
> > Hi,
> >
> > KGI used to set a task to sleep when it was mapped away from a display.
> > This didn't work always, and with some help from #kernelnewbies, I came to
> &g
On Mon, 20 Jan 2003, Fabio Alemagna wrote:
> On Mon, 20 Jan 2003, Brian S. Julin wrote:
>
> Stupid question from an outsider: couldn't it be possible to make the
> application still run by making it use an offscreen buffer while not
> "visible" because of VT switching? It would be really annoying
Gee... if this text is only worth 2 cents, why are books so expensive ?
Anyway, let's give it a try:
On Mon, 20 Jan 2003, Brian S. Julin wrote:
>
> This has to be considered in the context of both threaded and non-threaded
> applications, because we don't want to *require* the use of threads wit
On Mon, 20 Jan 2003, Fabio Alemagna wrote:
> On Mon, 20 Jan 2003, Jos Hulzink wrote:
>
> Why should you backup the whole gfx board's memory? Isn't there any way to
> back up only the area actually used by the application?
>
> You know, Amigas deal with full screen gr
On Tue, 21 Jan 2003, Christoph Egger wrote:
> How about using the memory target within libggi's kgi-target, when the
> application runs in background?
>
> This "background mode" can be done by copying first waiting until the accel
> is idle, then copying the framebuffer content into the userspace
On Tue, 21 Jan 2003, Christoph Egger wrote:
> Ok, I'll try to make a (short) summary.
> Andreas wanna deal with this whole issue by informing the userspace via a
> ping-pong mechanism based on sending signals between kernel space (KGI) and
> userspace (GGI application and/or GGI's kgi-target).
>
On Wed, 22 Jan 2003, Fabio Alemagna wrote:
> Not at all! AROS does it, AmigaOS does it, exactly that way! Screens have
> buttons on the top right that let them be put to back/front, and
> applications NEVER notice it: they continue to run seamlessy and when
> their screen is put to front again its
On Wed, 22 Jan 2003, Christoph Egger wrote:
> uhmm... I guess you mean: The user doesn't _need_ to switch... :-)
>
Amen.
English and early mornings don't go together...
Jos
On Wed, 22 Jan 2003, Fabio Alemagna wrote:
> On Wed, 22 Jan 2003, Jos Hulzink wrote:
> > Yeah, but if you think well about this, you would see that it doesn't work
> > in the general case.
>
> Sorry, you're just wrong there: it has worked in the general case for
On Wed, 22 Jan 2003, Rodolphe Ortalo wrote:
> I just start now in this heated discussion.
>
> Apparently, there are several subjects:
> 1) Whether generic backbuffering is desirable or not in general;
> 2) Whether it is possible to implement such a backbuffering mechanisms in
> a safe way on cur
On Wed, 22 Jan 2003, Rodolphe Ortalo wrote:
> On Tue, 21 Jan 2003, Jos Hulzink wrote:
>
> > And, let's face it: For which programs would a background framebuffer be
> > useful and worth the trouble ? For programs that can't refresh within
> > #include GGI_SMALL_
On Wed, 29 Sep 1999, [iso-8859-1] Rubén wrote:
> I have found at last a way of using the KGIcon hardware
> acceleration, I used the ACCEL IOCTL's that appear at
> include/kgi/kgi_commands.h
>
> But I found two problems, the first, is that when I call an ioctl
> command which isn't su
>
> strange. Could you try to track that ? strace, printk and friends ?
>
> Though the correct value to return would be: return -E(ACCEL, NOSUP_ALWAYS_MMAP);
>
Fixed
Jos
On Wed, 29 Sep 1999, [iso-8859-1] Rubén wrote:
> - lines: 20%
> - boxes: 74%
> - hlines: 64%
> - vlines: 13%
Hmmm...
On my P II 233 with GGI compiled gcc -O7 -march=pentiumpro the rate
accel : nonaccel == 2.9 : 1
for boxes
Jos
On Thu, 30 Sep 1999, James Simmons wrote:
>
> > I doublt it does so in an SMP-safe way, but actually who uses a Virge on
> > an SMP machine ? :-).
>
> Me!!
And me...
Jos
Okay, it is sandwitched between a Matrox Millennium and a Viper 550, (3
cards , 1 system !) but writing the driver, my sy
On Fri, 1 Oct 1999, [iso-8859-1] Rubén wrote:
> Ah, ok, well, it does what I want, its enough for me. Anyway, I will
> continue reading docs and learning how to include vertical retrace support
> into KGIcon, it's best (I have readed the GGI tech. docs, and it seems to be
> a bit difficult)
On Fri, 1 Oct 1999, James Simmons wrote:
> By the way the semaphore idea isn't a bad idea. The big things is we have
> to make sure only one process at a time is using the framebuffer or accel
> engine. Basically one process hogs the whole card.
You are right, but what if this process dies while
Hi
Working on my ViRGE driver, I noticed something:
Handling the KGI commands, most drivers use a switch () {case ...}
structure. This looks nice, but results in very slow code (each case
results in at least one conditional jump, which can slow down the CPU
badly)
I was wondering: Using a proce
On Mon, 4 Oct 1999, Steffen Seeger wrote:
> AFAIK GNU C does that if it becomes faster. So, it depends on the compiler
> you use :-)
Hmm, I'll take a look at the GCC output tonight, but I don't think GCC
makes a neat table out of the 32 bit values that the KGI commands
actually are at the moment
On Mon, 4 Oct 1999, Rodolphe Ortalo wrote:
> Jos Hulzink wrote:
> > The original loop GCC creates was about 9 instructions long, increasing
> > addresses made a mess of the code, so I had to decrease them. The only way
> > that produced neat code was treating the Z-buffer li
On Mon, 4 Oct 1999, Andreas Beck wrote:
> BTW: When designing new 3D ioctls, could you check with Jon and me ?
> We probably have manuals for other designs at hand and it might be helpful
> for finding a really generic interface.
I sure can. But this means that we're gonna try to create a chipse
Hi
Wondering:
When a certain mode CAN do hardware 3D, it is not always needed. For
example, if someone only runs normal X, or a 2D game like starcraft, he
doesn't need a Z Buffer, and the Z Buffer space could better be used for
other things.
It seems to me that the accelleration driver should d
On Tue, 5 Oct 1999, Andreas Beck wrote:
>
> > > struct kgi_3dtriangle {int x0,y0,z0,x1,y1,z1,x2,y2,z2};
> > > Comments please !
>
> > I don't like this kind of 3dtriangle at all, it needs 9 copies of
> > data to draw a triangle, maybe it's insignificant when you must call later
> > ioctl, w
On Tue, 5 Oct 1999, Jon M. Taylor wrote:
> On Tue, 5 Oct 1999, Jos Hulzink wrote:
>
> > Problem I got with these is that 3dline uses width heigth depth (relative
> > endpoint) while 3dtriangle uses absolute coordinates. Question: Is it OK
> > that the Z value is an
On Thu, 7 Oct 1999, Marcus Sundberg wrote:
> Ok, stop right here!
>
> We don't need more ioctl() callable accel commands, and if it isn't
> immediately obvious how to generalize an interface it should not be
> generalized at the KGI level.
>
> Once you got the mode-setting working and implement
On Sat, 9 Oct 1999, Christoph Egger wrote:
>
>
> Hi folks!
>
>
> The 3DtoolKit alpha-3.1 release is out!
Shouldn't part of this library be LibGGI 3D ?
Jos
On Sun, 24 Oct 1999, Marcus Sundberg wrote:
> Martin Lexa wrote:
>
> > 2) libggi: Why is in display/fbdev/fbdev.conf.in that line with
> >virge? I think it couldn't be there.
>
> It doesn't do anything at all, so...
Well... It used to do something, but now it's obsolete. I'll remove it.
On Wed, 20 Oct 1999, Steffen Seeger wrote:
> When the drivers are operational again. The Permedia2 driver works
> quite reasonably, at least setting modes and exporting the
> framebuffers. However, there is still some work to be done so that
> it can take over a running board safely.
>
ViRGE dri
On Tue, 26 Oct 1999 [EMAIL PROTECTED] wrote:
> For information, I also working on re-porting my attempts at a Gx00 driver
> to the new KGIbut am still trying to learn more of the interface. I noticed
> two excelent summaries on Segeer's webpage that exmplain most of the theory,
> but I'm currentl
On Mon, 25 Oct 1999, Martin Lexa wrote:
> O.K I'l look at textures. Could you explain me how should I load
> textures into memory and then get it to triangle func. And how are these
> persepective correction parameters computed?
Allright,
The next text is based on my own ideas and not based o
On 2 Nov 1999, Marcus Sundberg wrote:
> Basicly you never want to cache anything that sits on the other side
> of the PCI-bus. MTRR write combining should always be turned on for
> memory, but never for registers. That's about it.
> AGP is ofcourse another story...
>
Eh.. Enabling MTRR write com
On Mon, 8 Nov 1999, [iso-8859-1] Niklas Höglund wrote:
> The CVS snapshot of libggi doesn't build default/fbdev/s3/virge.so,
> neither are the sources for it included. Could someone who has the
> sources for it please send me a copy, or include it into CVS.
Should be removed, but I lost CVS acces
On Tue, 9 Nov 1999, [iso-8859-1] Niklas Höglund wrote:
> How do I get libggi to use the accelerated functions in the virge
> kgicon driver?
It does already.
Jos
On Tue, 9 Nov 1999, [iso-8859-1] Niklas Höglund wrote:
> OK, that explains it. How do I get libggi:s configure script to enable
> genkgi? (I always get an errormessage when running libggi-using
> applications that genkgi.so can't be found.)
>
> (And I'm pretty sure CopyBox isn't accelerated.)
D
On Thu, 11 Nov 1999, Jon M. Taylor wrote:
> On Thu, 11 Nov 1999, Andreas Beck wrote:
>
> > > To get acceleration to work, I had to disable ping pong
> > > buffers. Before I did, I got this message from GGI_DEBUG=255 ./demo:
> > >GGI_genkgi_drawbox() called
> > >Terminating on signal 11.
On Fri, 12 Nov 1999, Andrew Apted wrote:
> Jos Hulzink writes:
>
> In my understanding of the GC, you only need to reprogram the hardware
> state (e.g. do a ViRGE_set_colors) when the GC has _changed_, and
> there's a number in the GC that tells you when it has changed.
&g
On Thu, 11 Nov 1999, Jon M. Taylor wrote:
> On Fri, 12 Nov 1999, Jos Hulzink wrote:
>
> > When will PP really work on the GenKGI system ?
>
> When someone other than myself is willing to continue development
> on it. The current preliminary implementation _shou
On Fri, 12 Nov 1999, [iso-8859-1] Niklas Höglund wrote:
> En easy solution for the virge would of course be to override
> ggiSetGCForeground etc. to send an acceleration command. (But as the
> virge currently does synchrouous accels this should not be a problem.)
>
That has nothing to do with th
Good work,
Abuse is a nice game. Please make sure this version appears on the GGI web
page so everyone can download it !
Jos
On Mon, 22 Nov 1999, Peter Amstutz wrote:
> Just read the bug reports :) It's actually a bug in the debian packaging
> system. It doesn't install the appropriate libggi targets by default
> along with the core libggi, so a program starts up, tries to get SOMETHING
> to display to and dies becau
On Mon, 22 Nov 1999, Brian S. Julin wrote:
>
> This I really doubt. The very concept of Debian trying to sue
> an author of freeware for non-functionality is absurd on many levels,
> especially considering the software is distributed "without warranty [...]
> of suitabilty for a particular purpo
On Tue, 23 Nov 1999, Johannes Hirche wrote:
>
> Hi...
>
> is there any hope for the GForce?
> I have access to one, and the only thing that runs on it is console :(
Please wait...
Jos
On Tue, 14 Dec 1999, Rodolphe Ortalo wrote:
> OK. I cannot be in such a configuration for the moment - but
> soon it should be easy to work even without this (I have two
> computers now, and it's much easier...)
That's the reason why my S3 ViRGE driver takes so long: As soon as I try
to let my d
Hi
Jon's code contains a little bug, the splash screen doesn't compile. It
will work after applying this patch on top of Jon's. (attachment 1)
Besides, don't enable the kernel debugger in the 2.2.13 kernel, for
compiling will fail. As far as I can see, this has to do with the fact
that the debug
On Sun, 2 Jan 2000, Jon M. Taylor wrote:
>
> B. S3 ViRGE
>
> a. Detects and maps card and regions
> b. Sets/mmap()s VGA textmodes
> c. All registers #defined and struct{}'ed
> d. VGA registers read from card
> e. A
Hi,
Please find attached the source that makes the KGI ViRGE driver
compile. Don't expect anything, but to prevent many people doing the same,
I release it anyway.
Jos
On Sun, 9 Jan 2000, Stefan Mars wrote:
> On Sun, 9 Jan 2000, Andreas Beck wrote:
>
> > > Please find attached the source that makes the KGI ViRGE driver
> > > compile. Don't expect anything, but to prevent many people doing the same,
> > > I release it anyway.
> >
> > Forgot to attach ?
>
> He
>
> Rodolphe
>
>
> PS: I realize I owe many beers to many people on this
>list. A KGI/GGI workshop is starting to be really
>necessary...
Where, when ...
I propose Eindhoven, the Netherlands, long Easter-weekend (around April
23th, 1900). (Why Eindhoven ? for I live there, and it is c
On Thu, 13 Jan 2000, Julien Tayon wrote:
> Hello,
> bye the way, will some one go to the linux expo in Paris on februar?
> @++
> Julien Tayon
Where, when , how , why ?
Jos
Okay, now something serious.
I want to know if there are enough people seriously interested in a
meeting (i.e. are thinking about coming) for me to organise something.
Please let me know if you are interested to come, (maybe with some
comments on time, date, place, etc..) so I can consider what
On Fri, 14 Jan 2000, Steffen Seeger wrote:
> Mhmm... one day after my birthday, so why not...
The 23 th is mine... So I'm afraid sunday afternoon I'll not be available,
but I still have to figure this out. Don't worry :)
> I will try to keep this a spare weekend.
>
> Steffen
On Sun, 16 Jan 2000, Christoph Egger wrote:
> I agree. I'm subscribed to both lists too, and I don't like it, when I get
> the same post twice times...
A procmail filter prevents that, but the point is clear now. Only wonder
why I didn't get complaints when sending KGICON patches...
Jos
Hi,
DView is abailable on:
ftp://kwik.ele.tue.nl/pub/ggi
Jos
On Mon, 12 Mar 2001, Stefan Seefeld wrote:
> yes, indeed. I did work on some GGI code, and Andreas (and others) did
> know about it. Andreas did mention a couple of times that I should get
> write permission to commit my work. I did not get any write permission
> (beside the sourceforge cvs, wher
On Sun, 11 Mar 2001, Brian S. Julin wrote:
> What's in this release:
>
> 1) Docs, lots of them, and you can even read them in HTML at:
> http://mojo.calyx.net/~bri/projects/GGI/galloc/
Cool.. here goes my rest tonight :)
> 2) An API we felt was stable enough to write docs for. Really.
> We're
I have not been able to look at the Galloc code yet (unable to reach
site). But, my two dollarcents:
On Sun, 11 Mar 2001, Christoph Egger wrote:
> 1. Does X support hardware-buffers like z-, alpha-, stencil- or
> texture-buffer? Or does X just support raw-buffers, which are either
> emulated by
On Mon, 12 Mar 2001, Christoph Egger wrote:
> Let us know, when you want to contribute... :)
Just started :)
> Reading the API and the man-pages doesn't answer the questions I
> have. For example, there is nowhere mentioned, if ...
>
> 1. ... X supports hw-sprites
> 2. ... X supports hw-buffers
On Mon, 12 Mar 2001, Christoph Egger wrote:
> On Mon, 12 Mar 2001, Jos Hulzink wrote:
>
> > I have not been able to look at the Galloc code yet (unable to reach
> > site). But, my two dollarcents:
>
> I can send you a tarball in private, if you want.
Got it now, but
Hi,
Can you add me to the maintainers list on sourceforge ? My username there
is "Foske". Maybe we can discuss soon which way to go and how to set up
the CVS tree.
Jos
On Tue, 13 Mar 2001, Andreas Beck wrote:
> Umm - I get Error creating user object when trying - could you check your
> Account ?
I logged in normally this morning. Don't see what goes wrong... (donnow if
sourceforge is case sensitive, I now see my user name is foske instead of
Foske. I can log
Hi..
FYI:
I managed to download the latest snapshot of GGI. In X, all demos and
check utils crash. They do work on console, though I didn't find out yet
which target runs there (framebuffer nor kgi is compiled). On console all
demos crash somewhere in the exit-code. Nice to see the slimy demo ru
More detailed info:
My X (4.0.2) runs in 16 bpp mode. I used the "demo" demo to test what goes
wrong.
in degas/lib/libggi/display/X/mode.c: GGI_X_flush, line 160 in the
latest snapshot
For some reason, the colourmapping code is executed. (I guess this is
wrong for 16 bpp modes ?) . It crashes o
69 matches
Mail list logo
