Andreas Beck wrote:
It just polls the accelIdle bit and waits for it to come up while the ioctl
is still running.
Alternatively, some cards can also send an interrupt when the accel
engine has finished, no ? (But you need to protect the critical
section whatsoever.)
On SMP machines, you will
[EMAIL PROTECTED] wrote:
The problem is, that on cards that lock up, we cannot rely on applications
acquiring this lock. An mmaping/unmapping the framebuffer is the only way to
ensure that an application can/cannot access the framebuffer.
Wait a minute. For me a 'kernel lock' is not acquired
[EMAIL PROTECTED] wrote:
It is handled by the MMU hardware. And that is the problem. Well - actually
it is the only way to have decent speed :-).
OK. So, you need to unmap (to trigger page faults at least). I agree with
you.
I thought finer kernel control was possible.
However, it seems to
DrEvil wrote:
Everytime I run the configure script for GGI, it doesn't find glide.h, or
glide/glide.h
I have the glidesdk installed, the include files are in /usr/include/glide/
Where do I put the fracking glide includes, so configure will find them?
the env. or shell variable CFLAGS can
"Jon M. Taylor" wrote:
* Window manager hooks are unimplemented. This should probably be
implemented using LibGWT/LibWMH...?
AFAIK libwmh is really for X11 Window managers hooks ? Is it
what it needed ?
Concerning libgwt, it is still a 'conventional' library (not
really an extension in the
Marcus Sundberg wrote:
If you need to write everything from scratch there may be problems,
but the right way to do windowing/widgets on top of LibGGI is really
to finish LibGWT and port libgdk (the wrapper that GTK+ uses around X)
to it. Then you would be able to use any GTK+ application
Hello,
In the README.install of kgi-991208.tgz, Steffen Seeger wrote:
...
NOTE: The board needs to be the second VGA board installed (not the boot-VGA).
...
Steffen, is this note specific to the Permedia driver, or is it a general
issue ? (One of these days, I'd like to have a look at porting
Thank you for all this work. Steffen, I guess you will
tell us when you have a KGI distrib. with these things?
Rodolphe
"Jon M. Taylor" wrote:
I am flying out to the LinuxWorld Expo at New York City at the
beginning of February with my boss. We will be speaking at Eric Raymond's
Julien Tayon wrote:
XGGI will be running on a video
wall, the name of the product is elixir and the vendor (our client) is
synelec.
For those interested, http://www.synelec.fr/ should provide
some info.
I would like personnaly to thank everybody for having been so nice.
Tu rigoles... (How
Andreas Beck wrote:
A few thoughts about multithreading LibGGi3d:
- better scaling on SMP-machines
And worse on non-SMP, or if the number of processes exceeds the number of
CPUs. Note, that you will often have to switch between modules very rapidly
to avoid having large queues that will
teunis wrote:
And if anyone has any ideas on how to profile a multithreaded app, let me
know :)
Well, take care to store your profiling information _inside_ memory,
and output them to disk or terminal all in a bunch (preferably at the
final end of the program). If you are on a uniprocessor,
teunis wrote:
mutex locking time is... *heh* around 26000 microseconds... Longer than
poll() Go figure.
So much ? Well, it must be implemented via a system call then...
Well, with threads managed by the kernel it is not so astonishing,
but you can surely do much better if you only want
Well, first of all, let me say that the ideas of Andreas
concernin libwmh, and a X-style window manager seems perfectly
acceptable to me.
Marcus Sundberg wrote:
To me it sounds like what you really want is a window system running
directly on top of LibGGI, which really would be nice to have.
On Sun, 5 Mar 2000, Andreas Beck wrote:
(as an answer to this question from myself)
Should libggi2d support arbitrary clipping - or would it be acceptable to
have a 'small' version with only rectangular clipping ? (But with decent
drawing functions.)
I don't think LibGGI2D should have
On Fri, 3 Mar 2000 [EMAIL PROTECTED] wrote:
Thomas wrote previously:
is it possible to use kgicon / fbdev together with the
Neomagic card on a Notebook?
AFAIK there is no KGI driver for the neomagic, but it is known to work with
the generic vesafb driver in the kernel.
One would
On Thu, 2 Mar 2000, Eric , Yu-En Lue wrote:
Should potential connections (to do, considered, already done) between
libxmi and libggi2d be explored further ?
it's algorithms , data structures are mostly done and rather
imcompatible with ggi , I don't know how clipping works ,
On 8 Mar 2000, Thomas Mittelstaedt wrote:
I have an instant need to be able to draw Arcs, RoundRects and
Polygons etc. So, if somebody of the GGI project can give me
guidance, I can jump right into integrating libxmi, since libggi2d
just does not work. I already installed libxmi. There
On Wed, 8 Mar 2000 [EMAIL PROTECTED] wrote:
(set-of-non-overlapping-rectangles) in LibGWT.
I have the feeling of initiating too much workload wrt to graphic context
switch. (Basically, the way it is done is a loop over all the rectangles
composing the region while calling set-GC ; draw
On Sat, 11 Mar 2000, Jon M. Taylor wrote:
Sure. I'll try to collect all the ideas from the mailing list
archives and come up with a proposal over the weekend. Is there still any
interest in the LibXMI idea, or should I assume that we are trying to
design the ideal 2D library from
On Sat, 11 Mar 2000, Jon M. Taylor wrote:
Any clipping shapes at all can be handled with a 1bpp stencil
mask.
I also wonder if this method wouldn't be the most convenient one to
provide (arbitrary) clipping in libggi2d. It may be.
Furthermore, as this clipping may be done in the last
On Mon, 20 Mar 2000, Andrew Apted wrote:
Jon M. Taylor writes:
Bugreports and patches are appreciated.
Okidoke: demos/demo gives me a short line of three dashes on the
screen, then it segfaults with the missing symbol as you said.
xmitest segfaults immediately with a missing symbol.
Hello,
I successfully run libxmi demo program (with exactly the behavior you
mentionned). I intend to use it RSN inside the OpenAmulet library
framework? However, for this, I'll need to write XMI wrapper functions
inside LibGWT first. But 2D drawing functions were the LAST missing part.
Now
On Tue, 18 Apr 2000, Stefan Seefeld wrote:
Well, from a practical point of view, how would I manage multiple input
queues ? Given a list of visuals (as you seem to suggest) acting as window,
I'd be forced into one thread per visual if I want to listen for events.
I had such a problem with
Is it possible to have several miPaintedSet per ggi_visual_t ?
If yes, why (ie: what can be done with this feature) ?
Why are there 2 declarations of miDrawArcs in xmi.h ? (POSSIBLE BUG: one
of them should be reentrant and tagged _r no?)
Are any special interactions to take care of between
On Mon, 24 Apr 2000, Jon M. Taylor wrote:
On Sat, 22 Apr 2000, Rodolphe Ortalo wrote:
Is it possible to have several miPaintedSet per ggi_visual_t ?
Sure, in fact miPaintedSets are not tied to any one ggi_visual at
present, although this may change in the future (see below).
Hmm
On Thu, 27 Apr 2000, Andreas Beck wrote:
BTW: I have a polygon in a window now :-)
WHAT ? Freedom for the polygons ! No more mutilation by clipping windows !
(SCNR ... :-).
Don't worry, I am not such a cruel minion: just gwtRaise() the window to
the top level... :-))
(Still a lot of
Hello,
well, I have a few questions I'd like to raise over the way I can use
the LibXMI framework within LibGWT.
First, I wonder if I should allow several paintedSet and several miGC per
window (option 1), or hide these XMI abstractions inside a GWT window
(option 2).
With option 1, the
On Thu, 25 May 2000, Jon M. Taylor wrote:
A new release of LibXMI is available, and this time I have decided
to commit it to the GGI CVS repository under the degas/lib tree. New
features include:
Hmmm... Are you sure that you did not forget to commit a few
subdirectories of libxmi
On Thu, 25 May 2000, Jon M. Taylor wrote:
Hmmm... Are you sure that you did not forget to commit a few
subdirectories of libxmi into the degas CVS rep ?
I did indeed forget a few directories. I just committed them, did
a fresh CVS checkout and rebuilt and reinstalled with no
In libxmi/xmi/xmi.h, there are 2 ___BEGIN_DECLS and only 1 ___END_DECLS
(#define-s of the preprocessor symbols themselves not included).
(___BEGIN_DECLS is defined as 'extern "C" {' and ___END_DECLS as '}'
conditionnally on __cplusplus.)
Unpaired ___BEGIN_DECLS and ___END_DECLS leads a C++
On Wed, 7 Jun 2000, Jon M. Taylor wrote:
... Suggestions on which blend ops I should tackle next in the pixel
stubs are welcome - I've got no preference now ...
I'd really like to play with the alpha channel for buttons, menus, etc
inside OpenAmulet (more precisely, add an alpha component to
On Sat, 10 Jun 2000, Christoph Egger wrote:
I've just tested the libgwt demos from the latest ggi-snapshot.
The testgeometry-demo aborts often and suddenly with an internal error:
LIBGWT:internal.c:111: INTERNAL ERROR: Error in sending invalidate event!
I get this error always, when the
On Wed, 5 Jul 2000, Bryan Patrick Coleman wrote:
Can libXMI just be used instead [of XMI-like functions in LibGWT]? Then
I can get ahead sooner since much of the fbdev port of gdk is on top of
XMI.
Not really. However, gwtmi* functions are just pure wrapper for mi*
functions. They have the
On Sun, 16 Jul 2000, Michael Shiloh wrote:
does this mean that Matrox, in contrast to nVidia, _will_ release
the driver source? or other detailed information?
Hmmm. I don't remember exactly the details, but Matrox simply required
some kind of simple "email adress register" for giving you
On Wed, 30 Aug 2000, Andreas Beck wrote:
Security. LibGGI is - due to its dynamic loading mechanism and its external
configurabilty via the environment - very unsuitable to be run suid.
While most people here will agree, that there isn't much use in making
LibGGI progs suid, SVGAlib
Hello,
I can remember a time when this projet attracted too much attention. (I'm
sure several people on this list also remember that disastrous email burst
originating from the linux-kernel folks in mid-1998.) Since then, I've
never regretted the fact that GGI hides back in shadows and that
On Thu, 31 Aug 2000, Christoph Egger wrote:
On Thu, 31 Aug 2000, Andreas Beck wrote:
How about LDDK (http://www.llp.fu-berlin.de/pool/software/dutil/) for a
beginning?
If the _L_ there means _L_inux, then please don't, except for maybe
borrowing ideas.
Yes. LDDK = Linux Driver
On Thu, 31 Aug 2000, Christoph Egger wrote:
The DDL-Compiler doesn't create any binary. No - the DDL-Compiler is
principally a translator from DDL to C.
A driver written in DDL, will be compiled in two steps:
DDL - C (done by the DDL-compiler)
C - binary module (done by
On Sun, 3 Sep 2000, Christoph Egger wrote:
To avoid mixing up DDL coming with LDDK and our DDL we are speaking about, we
should give it a new name.
I suggest DDL4KGI (Driver Development Language for KGI)
I'd rather say 'HDL4KGI' (Hardware Description Language) or maybe RDL
(Register
(Yes, I know I am a bit late on this answer but, well...)
On Fri, 29 Sep 2000, Stefan Seefeld wrote:
The next thing to do is to implement event routing. However, as the
client will have a single ggi visual, we still need a region management
library (client side) which figures out the
Hello,
today - as others - I have problems accessing most of the GGI related
sites: {cvs,ftp,www}.ggi-project.org.
All of them returns me a:
ortalo@tempest:~$ nslookup www.ggi-project.org
Server: laas.laas.fr
Address: 140.93.0.15
*** laas.laas.fr can't find www.ggi-project.org: Non-existent
We still have a cvs.ggi-project.org (at least the computer): use this Jon.
ortalo@tempest:~$ cat /etc/hosts
127.0.0.1 localhost
[...skipped...]
195.154.155.29 cvs.ggi-project.org
#152.19.254.81 ftp.ggi-project.org
I guess the domain will come up again sooner or later... At least when,
On Tue, 17 Apr 2001, Christoph Egger wrote:
[...]
- highlevel
This one is intended to contain higher level extensions like
libxmi, libggi3d, libgwt, etc.
[...]
libgwt - Rodolphe?
[...]
I don't think preserving the history of libgwt is very important. You can
do without it. Note that
On Fri, 27 Apr 2001, Christoph Egger wrote:
I just found a project at SourceForge, which might be
interesting for someone: LGShell.
[..]
http://sourceforge.net/projects/lgshell/
It seems that project is very alpha... (Even _more_ than libgwt if you see
what I mean... Maybe you should even
On Sat, 21 Apr 2001, Christoph Egger wrote:
[...]
Rodolphe: I haven't imported libgwt yet, because I think, it's
better
to make a major cleanup at it - particularly the directory structure.
Good remark! (The file layout dates from a time before the ext-lib
habits finally stabilized...)
On Tue, 14 Aug 2001, Brian S. Julin wrote:
Obstacle #4: Failure to deliver hardware acceleration. Other graphics
packages are currently providing much more hardware acceleration
support than LibGGI.
[...]
Obstacle #4 has a simple solution: encourage KGI development, and in
the
On Thu, 16 Aug 2001, Brian S. Julin wrote:
On Fri, 17 Aug 2001, Rodolphe Ortalo wrote:
I think I'll soon need a place within LibGGI (and possibly its
extensions) to plug kgi-matrox specific code. Note also that the
3Dlabs/PERMEDIA driver is even more ready. I don't know exactly what
On Mon, 27 Aug 2001, Andreas Beck wrote:
[...]
However there was something like this there somewhen as well. However I
don't quite remember how it was called.
libgwt ?
R.O.
Hello,
I've been playing for a few weeks with the WARP accelerator(s) engine of
the G400 (3D setup + 2D raster engine) on a KGI-enabled kernel. Up to now
I've postponed an actual drawing weirdness problem (because I had lower
level issues to tackle first ;-) but now I'm adressing it and...
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.)
Still, I'd be happy to have some standard 3D test programs and models.
Rodolphe
On Fri, 12 Oct 2001, Christoph Egger wrote:
[...]
I got more and more mails from users, who are crying for [...]
accelerated extension-targets
[...]
I am currently working on userspace code for sending accelerated commands
to the KGI Matrox driver, following pretty closely the LibGGI API. It
On Sat, 13 Oct 2001, Brian S. Julin wrote:
[...]
Once these are complete most hurdles will have been cleared and the
rest is just a flesh-out operation. Until then, I do not feel confident
opening the book on 3D.
I do agree with you. We may open the book for 3d right now [1], but it's
On Mon, 15 Oct 2001, Brian S. Julin wrote:
[...]
[2] E.g.: texture allocation deserves to be done cleanly
Here you hit the nail on the head.
Yep, allocation is a very annoying issue when you want to manage all the
details (pitch != width, and the like).
[...]
Hopefully we can finish
On Tue, 16 Oct 2001, Brian S. Julin wrote:
On Tue, 16 Oct 2001, Rodolphe Ortalo wrote:
That's pretty much sidestepping the problem as you say - but I'm still
wondering if a general algorithm has been published to address the problem
of bidimensional memory allocation in one shot.
Well
On Tue, 19 Mar 2002, Brian S. Julin wrote:
[...]
KGI directories other than libkgi should be moved to an attic, IMO,
Since they cannot drive the current KGI. libkgi is the playground.
From what I've read in ggi-core/libggi/display/libkgi/ and
ggi-core/libggi/include/ggi/display/libkgi.h ;
[ This mail is even longer than Brian's... You've been warned. ;-) ]
Hi Brian,
overall I really understand your point, and you are right on many aspects,
including the fact that no rush is needed, and that some more design
work (or discussion) would be useful to KGI as a project (as useful as
Hello,
When trying to compile libggi libgii (a CVS version from Wednesday IIRC)
--with-kii I have a few problems.
Up to now, I've been obliged to apply a few fixes to kii.h (see diff)
and I'm wondering if there are correct. And as kgi/system.h
should be included by kii.h, I now have the
On Sat, 30 Nov 2002, Christoph Egger wrote:
I just tried KGI, too.
[...]
Please update from CVS again.
Done. libgii built fine wrt kii/kgi now. Thanks.
libggi compiled *nearly* fine, however, libggi configure.in does a
AC_CHECK_HEADER(kgi/kgi.h, ... ) in addition of the AC_TRY_COMPILE(..).
Hi,
so, I made some new attempts, and here are my results with the Matrox
driver.
Indeed, the monitor error was simply a non-working mode (I used the SVGA
monitor). Doing:
export GGI_DEFMODE=1024x768x16
(for example, 800x600x16 works too) solved most problems with fb setup.
So, yes, I
On Sat, 30 Nov 2002, Rodolphe Ortalo wrote:
I'm going to commit my changes to the Matrox driver in kgi-wip today. I
think it's good enough for testing.
Commit done to kgi-wip now.
Rodolphe
PS: Note that flying_ggis on the G200 and simultaneously stars on the
Mystique via fbdev runs too
[GGI folks may be interested by 2) below.]
On Mon, 2 Dec 2002, Filip Spacek wrote:
[...]
Thanks for the details.
So to answer your question: it depends on the number of focuses you have
(which is equal to the number of keyboards)
I usually replace display 0 with my driver (since I have
On Wed, 4 Dec 2002, Christoph Egger wrote:
Please test them out and give us feedback on IRC [1] or here on this list.
I've just rebuilt with from a fresh CVS update.
Changes from libgii 0.8.2-rc3 to libgii 0.8.2-rc4:
- minor kii input update
I had to apply the one line patch at the end
Hello,
attached is a patch that solves - at least for me - some of the input
problems that I experienced with libgii on KII. I think the fix sounds
reasonable, and it is just a re-import of some of the other input targets
(I looked at linux_kbd for comparison for example).
Please commit if you
Hello,
I updated from CVS tonight and still have a problem building the kgi
target with the current configure.in.
The check for header kgi/kgi.h does not take into account the fact that
this header wants, for example, HOST_OS to be defined. If it is not, the
header fails to read (#error) and the
Hello,
is the plane_mask entry of the ggi_gc struct really used (see
ggi/internal/structs.h)?
There is not update mask associated with this field of the struct (on
the contrary of the foreground/background color or clip coordinates), so
I'm wondering if I should or should not overwrite the PLNWT
Hello,
once again, I think I hit the problem of synchronizing the accelerator
drawings and the drawings made directly in the framebuffer by
(unaccelerated) drawing operations.
It seems there is a provision for such synchro in ggi_visual (especially
with the fields needidleaccel and accelactive).
On Sun, 15 Dec 2002, Brian S. Julin wrote:
vis-opdisplay-idleaccel should be loaded with your target's
accelerator idling funtion.
When a mode is set, the target is supposed to set vis-needidleaccel
if it wants the stubs renderer to provide accelerator-friendly pixel
functions. When the
On Sun, 15 Dec 2002, Brian S. Julin wrote:
[...]
A sublib that has the need for idling the accelerator should provide
at least hline, vline, box; e.g. it should not leave solid-fill
primitives to the generic renderers, because the generic libs only
contain accelerator aware versions of the
On Wed, 18 Dec 2002, Andreas Beck wrote:
Which widget library? Some of your own or something more general?
One of my own. Basically something to do away with an ugly TCL/Tk
script that is used to control eccet. The idea is to have something that
can nicely live side by side with other
On Sun, 15 Dec 2002, Paul Redmond wrote:
[...]
http://www.student.math.uwaterloo.ca/~pmredmon/ggibench.c [on KGI?]
[...]
Here is the output up to now (K6-III 450MHz, G200 AGP):
identified to mapper graphic-0.9.0-0
1024x768 (1024x768)
1024x768 (1024x768)
ggiDrawPixel: 333598 pixels/second
On Thu, 19 Dec 2002, Brian S. Julin wrote:
On Tue, 17 Dec 2002, Rodolphe Ortalo wrote:
Is it also the case for putc, puts (and possibly copybox)? I have some
strange output with them.
If the put* functions are implemented in software, yes, and indeed
the generic renderers do call
On Thu, 19 Dec 2002, Andreas Beck wrote:
1- For precise interface layout, I do not want to program: I simply want
an UI builder. I do *not* care of the actual API involved below, I do not
want to be able to call it directly. I want these damns buttons to get
drawn, I do not want to
On Thu, 19 Dec 2002, Andreas Beck wrote:
Not bad. On (unaccelerated) XGGI on fbdev I get at 1024x768x24 (running
on 1600x1200 - i.e. high VideoOut Memory bandwidth demands) on a PIII/800
Oops, sorry. I was running at 1024x768x16 (not 24). Should have indicated
this. I cannot set 24 or 32
On Thu, 19 Dec 2002, Stefan Seefeld wrote:
I don't think an interactive GUI builder is an absolute must to get a
GUI,
[...]
I really think it is a very important point to get _applications_ using a
GUI. I'd even say that it should be a requirement.
But I understand that you may also have a
On Thu, 19 Dec 2002, Paul Redmond wrote:
Yeah, the KGI Radeon accelerator is PIO only. Once DMA'd ring buffers are
implemented it will fly!
It will not necessarily be so much faster, it may be your system CPU load
that drops. Anyway, that's free horsepower to do more beautiful or more
Hello,
what's the format of the 8x8 font available via ggi/internal/font/8x8 ?
I guess it probably is a standard font, but I'm trying to use it as a
pattern base for drawing with the G200 accel and... well, for the moment
it looks like some bizarre runic alphabet... :-) Could possibly explain me
Hello,
here is some corrected output for G200 hardware with:
- hw accel for Putc with the simple 8x8 fixed width font (and also
copybox, but it is not tested there...)
- some personal updates to the KGI target to have it load pixela
directbuffer functions (those that sync with an hw
Hello,
I've just committed a new default/kgi/Matrox/ directory with some *.c in
it. The kgi-Gx00 sublib now provides acceleration for some of libggi
drawing functions (drawbox, line, hline, vline, putc). It should also
accelerate copybox (but I am not totally sure that the implementation is
On Mon, 23 Dec 2002, Aurelien Reynaud wrote:
Hi, I am a longtime lurker on the GGI mailing list...
I'm not so good at programming and do not have much time either, but I'd be
glad to help. So I can answer yes to your question: I have an old Mystique
lying around. Maybe I can make some
On Mon, 23 Dec 2002, Brian S. Julin wrote:
On Mon, 23 Dec 2002, Rodolphe Ortalo wrote:
0) What should a KGI-accel-oriented developper do next? :-)
I'd like to see the get/put issues worked out personally, and of
course, whatever can be done to bring the accelerator command queues
up
On Thu, 26 Dec 2002, Christoph Egger wrote:
[...]
And OUR ANNOUNCEMENT IS ON THE FRONT PAGE
[...]
Congratulations to the author(s) then! (It was rather well written.)
Rodolphe
Meilleurs voeux et bonne annee a tous.
Rodolphe
Hello,
there is a problem with the G400 and the version of the Matrox Gx00 accel
sublib for KGI in the CVS tree right now. copybox is erroneous and
freezes the target display. The computer is still usable, but the
associated head is... problematic to use (unless you love to work in text
mode
On Tue, 21 Jan 2003, Fabio Alemagna wrote:
[...]
You miss, that in X, you never talk to the graphics HW directly. X will
send you an event when you iconify, and will nicely gobble up all
your funny drawing requests if you don't act on it.
Not completely true: if backing store is active
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 fuzzylogic.h GGI_SMALL_AMOUNT_OF_TIME.
I'd rather say the impatient user. :-) I really like the
On Wed, 22 Jan 2003, Fabio Alemagna wrote:
[...]
only platform), and also because there exist one free alternative to
AmigaOS, which is AROS, and another commercial alternative which is
MorphOS, and everyone of dem deals perfectly with the issue we're
discussing here. I'll explain in another
86 matches
Mail list logo
