kgi-0.9-20000418
Hello, a new snapshot of KGI-0.9 has been released and may be downloaded from http://kgi.sourceforge.net What's new? - Overall source tree cleanup - source tree now moved to SourceForge's CVS Repository - added driver development SDK (basically a few scripts that aid you in getting a driver framework started easily) - added TI TVP3026 ramdac driver (which was created using the SDK within a day). - it all compiles again except for the X server. Enjoy trying it, Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: MPEG in GGI?
Andrew Apted wrote:
Personally, the idea of getting input "independently" of the output
doesn't feel right. The traditional "window" is a good abstraction,
it is a place to draw stuff for the user, and a place to receive the
feedback from the user.
But you don't listen to a window for events. You listen to the server
connection ('XDisplay') for events which *refer* to windows. A window -
as it is seen by the application - is completely unaware of events.
Ok, let's assume that windows listen themselfs for events. Then there
are cases where you want to draw into some 'output only' medium, a
Pixmap in X. Since Pixmaps and Windows in X are the same for the purpose
of output (drawing), they are generalized to 'Drawables'. That's precisely
what I'm asking for.
To reiterate it once more: I can completely see your point of wanting to
glue input and output together. Yet I think The individual entities for
input and output should be accessible, even instantiable, through the
public API. You should not to be forced to by an input context just because
you need an output context.
Think of each ggi_visual as a window if it
helps (under the X target, it actually _is_ a window). Each "VT" on
the console is also like a window (but text mode).
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.
Stefan
___
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
___
...ich hab' noch einen Koffer in Berlin...
Re: SVGALIB4ggi
OK I am running a standard Apple PowerPC G400 with an ATI Rage card (AGP). Here is proc/pci and the systeminfo output from KGIcon: machine : PowerMac3,1 motherboard : PowerMac3,1 MacRISC Power Macintosh pmac-generation : NewWorld [PCI] PCI devices found: Bus 0, device 16, function 0: VGA compatible controller: ATI Unknown device (rev 0). Vendor id=1002. Device id=5046. Medium devsel. Fast back-to-back capable. IRQ 48. Master Capable. Late ncy=255. Min Gnt=8. Prefetchable 32 bit memory at 0x9400 [0x9408]. I/O at 0x400 [0x401]. Non-prefetchable 32 bit memory at 0x9000 [0x9000]. # Kernel Setup: [VERSION] Linux version 2.2.15pre17 (root@ppc) (gcc version egcs-2.91.66 19990314 (egcs-1. 1.2 release)) #18 Tue Apr 18 01:29:37 NZST 2000 KGIcon auto config also doesn't work Yes - it wouldn't help anyway. We do not have drivers for the ATI Rage. and vga/ncvga drivers don't compile. Oh - that's bad. Maybe we need to adjust for PowerPC. Could you send more details on this ? Am I better advised to try and get FBCon or KGIcon going under the circumstances? What you are trying is kgicon. Maybe you are hinting at Steffen's "real KGI" ? That isn't a good idea for that chipset right now. I don't know, if the kernel has native drivers for the Rage ... You might want to try: Open Firmware frame buffer device support - CONFIG_FB_OF but I'm not sure, if that would work. I don't think the VESAfb would work on anything but x86. I might also try a different graphics card under KGIcon, but I would appreciate any help you are able to give me to get GGI going on PPC under any framebuffer device. KGIcon is running fine here on a Permedia2 based board on x86. The driver is designed for running on PPC and similar, so that might work. However you'll have a hard time getting such an old card today ... CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: MPEG in GGI?
I have argued in the past for a more formal separation of LibGII from LibGGI. This would decouple the event queues from ggi_visual(s). Actually they are separated. LibGII provides all event functionality. All that LibGGI does is automatically locate and load the approriate "default" event sources for a given target. After that you are free to do anything to them. Close them down (o.k. - that's not strictly supported, but could be added easily, if required) join more inputs, ... Sure, the notion of a window (as in X) is a combination since you can draw into it and be sensitive to events *for* it. A window is just a particular set of rules for representing the contents of a particular graphics context. Each window is bound to a ggi_visual in LibGWT and they route events amongst themselves just fine. Yep. That is the idea, cube3d also shows how you can multiplex the event streams. The apps on the sides of the cube get all fed by the main event stream from the visual the cube is on. But this consideration should come *after* input and output logic has been defined, i.e. a 'window' should then be constructed as, say, a pair of a drawable and a 'hot region'. This can be done easily in application context. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: MPEG in GGI?
Andreas Beck wrote: On a different note: the Berlin project will present itself on LinuxTag in Stuttgart this year, both, with a booth as well as in a talk. Does anyone from GGI intend to show up in Stuttgart ? May be we could meet and discuss various aspects of the above... When is it ? The LinuxTag is from 29.06 to 02.07. in Stuttgart. See www.linuxtag.org for more details. Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: another ggi question
Does ggi depend on Xwindow system for anything? No. can it draw graphics right in the console like svgalib? Yes. Using SVGAlib or native drivers. LibGGI can be thought of as "Meta-Graphicslib" that will draw on about anything. i ask this cause my project is to port a light window system that uses opengl to linux but without depending on another window system =] That is doable, if you have a suitable driver for your hardware in either SVGAlib, the kernel framebuffer drivers or a kgicon driver. in other words if a system doesn't have X installed can ggi run? Yes. i'm not a big fan of svgalib and would rather use ggimesa... Note, that you will need a driver. If SVGAlib works, you have one. another thing.. when building ggi do i need to target it for ggimesa No. LibGGI does (should) not have dependencies on any application or extension. cause the ggimesa demos arent' compiling That must be a problem with ggimesa, then. What happens ? CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: MPEG in GGI?
According to me email software Stefan Seefeld wrote:
| Andrew Apted wrote:
| Personally, the idea of getting input "independently" of the output
| doesn't feel right. The traditional "window" is a good abstraction,
| it is a place to draw stuff for the user, and a place to receive the
| feedback from the user.
| But you don't listen to a window for events. You listen to the server
| connection ('XDisplay') for events which *refer* to windows. A window -
| as it is seen by the application - is completely unaware of events.
The ability to listen to the display as a whole not just your own
window is a source of security problems (snooping/eavesdropping/...).
Of course if you can manipulate the event queue for more than your
window, you have kissed security goodbye.
[ Which is why X tags 'fake' events, but simply looking is frequently
too much. (cf "peeping toms") ]
| Ok, let's assume that windows listen themselfs for events. Then there
| are cases where you want to draw into some 'output only' medium, a
| Pixmap in X. Since Pixmaps and Windows in X are the same for the purpose
| of output (drawing), they are generalized to 'Drawables'. That's
| precisely what I'm asking for.
| To reiterate it once more: I can completely see your point of wanting to
| glue input and output together. Yet I think The individual entities for
| input and output should be accessible, even instantiable, through the
| public API. You should not to be forced to by an input context just
| because you need an output context.
Perhaps output 'structures' need to be generalised to deal with offscreen
bitmaps, but input should only be allowed in association with its "window".
- JonT
---
Jon Tidswell
Advanced OS Technology Group / Sawmill Linux Project
IBM TJ Watson Research Center 30 Saw Mill River Road, Hawthorne, N.Y. 10532
Email: [EMAIL PROTECTED] Voice: +1 914 784 7550
Re: MPEG in GGI?
[EMAIL PROTECTED] wrote:
| But you don't listen to a window for events. You listen to the server
| connection ('XDisplay') for events which *refer* to windows. A window -
| as it is seen by the application - is completely unaware of events.
The ability to listen to the display as a whole not just your own
window is a source of security problems (snooping/eavesdropping/...).
Note that I'm not out to defend X' architecure. X' shortcomings are
one reason for berlin's existence.
[...]
Perhaps output 'structures' need to be generalised to deal with offscreen
bitmaps,
my point exactly.
but input should only be allowed in association with its "window".
what do you mean with 'its' ? Do you mean that each offscreen bitmap should
have a "window" it is associated with ? This would be what X refers to as
visual, i.e. a structure holding formatting info for pixels, colors etc.
Lots of windows can use the same visual. This makes my point since I'm arguing
that GGI's visual plays the role of all of them: drawawbles (which I might want
to have many), visuals (there might be a few) and event queues (generally
one, at least in a single threaded application).
Stefan
___
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
___
...ich hab' noch einen Koffer in Berlin...
on movies and GGI - how's this for a first look at a spec for drivers?
Here's the module header for a movie player object from the movie player
I've been mucking with..
How's this look?
Now a problem I see is how to handle colourmodels;
Oh and the void* is simply an override for a pointer to self.
This IS C I'm using :)
G'day, eh? :)
- Teunis
#define MOVIE_FLAG_CPU 1 /* int* == # of CPU's */
#define MOVIE_FLAG_PREBUFFER 2 /* long* == prebuffer size */
struct plugin_movieFile
{
struct plugin root;
void (*printInfo)(void*, FILE* stream);
void (*setFlags)(void*, int flag, void* data);
void* (*getFlags)(void*, int flag);
int (*openFile)(void*, char* path);
/* error codes as per setFile + std. errno */
int (*setFile)(void*, FILE* inf);
/* return values:
0 = success
0: errno code; follow as per fread/...
special codes:
ENXIO == can't open this way; must use a path.
(quicktime and mpeg currently)
ENOEXEC == bad file format; (should be available on most platforms)
Passing an open file descriptor means the caller has to handle a lot of
the potential problems;
ie: EEXIST:file not found, EACCES:access denied, ...
*/
int (*closeFile)(void*);
/* 0==success; 0==errno */
/* positioning functions: may not be available on streamed data */
/* all functions: 0 == success (except where otherwise stated) */
int (*has_video)(void*); /* 1 if yes, 0 if no */
long (*get_video_length)(void*);
long (*get_video_position)(void*);
int (*set_video_position)(void*, long pos);
int (*video_colormodel_avail)(void*, int colormodel);
int (*video_set_colormodel)(void*, int colormodel);
int (*video_width)(void*);
int (*video_height)(void*);
int (*video_read_frame)(void*,
unsigned char** rows, int w, int h);
int (*has_audio)(void*); /* 1 if yes, 0 if no */
long (*get_audio_length)(void*);
long (*get_audio_position)(void*);
int (*set_audio_position)(void*, long pos);
int (*audio_channels)(void* dt);
long (*audio_rate)(void* dt);
int (*audio_read_frame)(void*,unsigned short* dst, size_t samples,
int channel);
/* for now, audio data must be 16-bit signed. Convert it if needed! */
float (*frame_rate)(void*);
int (*read_completely)(void*);
/* read file completely */
/* needed for thread-coherency */
int (*lock_read)(void*);
int (*unlock_read)(void*);
};
CMUCL and GGI
Hey - someone mentioned CMUCL on this list a bit ago... unfortunately I've lost the mail. Any idea where I could get a copy that works? /aside I'd like to patch the interface to be loadable into a running system with, say, Berlin or GGI in it already :) Thank you in advance! G'day, eh? :) - Teunis PS: CMUCL always was ideal for my purposes. It's just I thought it hadn't been touched since 94-95-ish or so, so I left it alone...
gii bug + fix (?), (open close open close continued)
In lib/libgii/gii/gii.c, in the function
int giiClose(struct gii_input *inp);
there is this code at the end of the closing loop:
curr = curr-next;
_giiInputFree(curr-prev);
} while (curr!=inp);/* looped through once. */
The call to _giiInputFree() segfaults if curr==inp, so I changed it
into this:
curr = curr-next;
if (curr != inp)
_giiInputFree(curr-prev);
} while (curr!=inp);/* looped through once. */
This of course works, but it's both ugly and I get the idea that
an input is not closed now.
Unfortunately this didn't solve the segfault I get when the simple
test program exits. Again, here is a simple program that exits with a
segfault when run from the svgalib target:
#include ggi/ggi.h
int main()
{
ggi_visual_t v;
ggiInit();
v = ggiOpen(NULL);
ggiSetGraphMode(v,320,200,GGI_AUTO,GGI_AUTO,GT_8BIT);
ggiClose(v);
v = ggiOpen(NULL);
ggiSetGraphMode(v,320,200,GGI_AUTO,GGI_AUTO,GT_8BIT);
ggiClose(v);
return 0;
}
Any ideas/hints/help ?
--
Tijs van Bakel, [EMAIL PROTECTED]
Re: MPEG in GGI?
Once upon a time I wrote:
| But you don't listen to a window for events. You listen to the server
| connection ('XDisplay') for events which *refer* to windows. A window -
| as it is seen by the application - is completely unaware of events.
The ability to listen to the display as a whole not just your own
window is a source of security problems (snooping/eavesdropping/...).
...
Perhaps output 'structures' need to be generalised to deal with offscreen
bitmaps,
but input should only be allowed in association with its "window".
I believe Stefan Seefold responded:
| what do you mean with 'its' ? Do you mean that each offscreen bitmap
should
| have a "window" it is associated with ? This would be what X refers to as
| visual, i.e. a structure holding formatting info for pixels, colors etc.
An offscreen bitmap can't get input. :-)
[ Damn. I need to reread the GGI terminology. ]
When I say window, I mean something the user understands as a window, not
an internal data structure used for OO style GUI development.
I meant that input should _still_ be associated with a particular window,
even if output was generalised.
I see the problem in X/Win32/MacOS because the internal 'window'-list is
reused
as a user visible 'window'-list allowing applications to see 'windows' that
belong
to other applications.
And two different user-'windows' should not share event queues.
| Lots of windows can use the same visual. This makes my point since I'm
arguing
| that GGI's visual plays the role of all of them: drawawbles (which I
might want
| to have many), visuals (there might be a few) and event queues (generally
| one, at least in a single threaded application).
This has unfortunately wandered.
I was responding in the context of XDisplays, where X has multiple windows
from
multiple applications.
- JonT
Re: MPEG in GGI?
On Mon, Apr 17, 2000 at 11:39:35AM -0400, Stefan Seefeld wrote: On a different note: the Berlin project will present itself on LinuxTag in Stuttgart this year, both, with a booth as well as in a talk. Does anyone from GGI intend to show up in Stuttgart ? May be we could meet and discuss various aspects of the above... I'll be there. I would be pleased to meet someone from the list there at stuttgart. Regards, Stefan thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
Re: MPEG in GGI?
teunis [EMAIL PROTECTED] writes: On Tue, 18 Apr 2000, Andreas Beck wrote: I have argued in the past for a more formal separation of LibGII from LibGGI. This would decouple the event queues from ggi_visual(s). Actually they are separated. LibGII provides all event functionality. All that LibGGI does is automatically locate and load the approriate "default" event sources for a given target. After that you are free to do anything to them. Close them down (o.k. - that's not strictly supported, but could be added easily, if required) join more inputs, ... Hmm, one very interresting point Stefan has risen is that of how to know what visual an event is associated with in case you have joined events from several visual together. Sure you could check the origins of the event sources for each visual before joining them, but that would be really combersome. We really should have a "visual" element in the events. It would break binary compability, but as you just need a recompile I think it's worth it, unless someone has a better solution? Okay. Can someone -please- fold the event sources in fb/... out into GII? Seriously! or something? Huh? The input sources for the fbdev target are in LibGII. Or suggest a target with the same event sources so I could dynamically start FB/X/... if I needed graphics? What is the problem? Exactly what is it that you want to do? //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: gii bug + fix (?), (open close open close continued)
[EMAIL PROTECTED] (Tijs van Bakel) writes:
In lib/libgii/gii/gii.c, in the function
int giiClose(struct gii_input *inp);
there is this code at the end of the closing loop:
curr = curr-next;
_giiInputFree(curr-prev);
} while (curr!=inp); /* looped through once. */
The call to _giiInputFree() segfaults if curr==inp, so I changed it
into this:
Ah, thanks for finding that one! This should fix it properly:
diff -u -r1.22 gii.c
--- gii/gii.c 1999/09/05 22:18:35 1.22
+++ gii/gii.c 2000/04/18 23:07:09
@@ -692,6 +692,8 @@
_giiEvQueueDestroy(inp);/* This destroys _all_ queues ! */
do {
+ struct gii_input *prev;
+
curr-queue = NULL; /* For better error catching. */
if (curr-GIIclose) {
@@ -702,9 +704,10 @@
_giiCloseDL(curr-dlhand);
free(curr-dlhand);
}
+ prev = curr;
curr = curr-next;
- _giiInputFree(curr-prev);
- } while (curr!=inp);/* looped through once. */
+ _giiInputFree(prev);
+ } while (curr != inp); /* looped through once. */
return rc;
}
Unfortunately this didn't solve the segfault I get when the simple
test program exits. Again, here is a simple program that exits with a
segfault when run from the svgalib target:
#include ggi/ggi.h
int main()
{
ggi_visual_t v;
ggiInit();
v = ggiOpen(NULL);
ggiSetGraphMode(v,320,200,GGI_AUTO,GGI_AUTO,GT_8BIT);
ggiClose(v);
v = ggiOpen(NULL);
ggiSetGraphMode(v,320,200,GGI_AUTO,GGI_AUTO,GT_8BIT);
ggiClose(v);
return 0;
}
Any ideas/hints/help ?
This is not related to the GII bug above.
It is due to svgalib registering an atexit() handler. As atexit
handlers can't be unregistered and svgalib is not in memory when
the program terminates we get a segfault. For normal use we work
around this, but if you open the svgalib target several times it
won't work and you'll get a segfault. I'll have a look at making
the workaround a bit better when my local copy of LibGGI compiles
again.
//Marcus
--
---+
Marcus Sundberg| http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: MPEG in GGI?
The LinuxTag is from 29.06 to 02.07. in Stuttgart. Looks good. It's on a WE, so it might be well possible. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
