ggi with gtk - quick question
hi there, i've seen a demo where an sdl screen is embedded in a gtk application. it stikes me as being a Very Good Idea, making SDL widget libraries obsolete. is it possible to embed a ggi screen (sorry, i don't know the right term here; i've never used ggi before) inside of a gtk application? if so, is there a code sample i can look at? thanks! pete
Re: GGIMesa and the new ExtensionLoadDL
This cvs command:
cvs -z5 -d:pserver:[EMAIL PROTECTED]:/cvs/mesa3d checkout Mesa"
says:
cvs checkout: cannot find password
cvs [checkout aborted]: use "cvs login" to log in first
on my system. Do I have an old version of cvs? "rpm -q cvs" says "cvs-1.10.7-7"
If not, what do I need to do?
(Sorry I haven't used cvs, just rcs)
"Jon M. Taylor" wrote:
On Sat, 27 May 2000, Andreas Beck wrote:
[Stefan, please excuse, if you get that twice - I hope it gets through to
the Mailinglist, but I'm not quite sure.]
as you know, berlin uses MesaGGI as a rendering backend.
With the lates change in the GGI internal API, however,
MesaGGI doesn't compile any more. What can be done about
that ?
I'll have a look. I just spent about an hour with downloading Mesa
("cvs -z5 -d:pserver:[EMAIL PROTECTED]:/cvs/mesa3d checkout Mesa"
does the trick, as someone asked where he'd get it) and I'll have a look at
it, when I'm awake again.
If you manage to get it to build, let me know. I haven't been
able to get Mesa to link for a few weeks now.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
Re: GGIMesa and the new ExtensionLoadDL
Where is the MesaGGI source? Stefan Seefeld wrote: Hi everybody, as you know, berlin uses MesaGGI as a rendering backend. With the lates change in the GGI internal API, however, MesaGGI doesn't compile any more. What can be done about that ? Luckily for us, we have a second rendering backend, based on libart. However, there are still some features missing (textures among others) so I would really like to be able to run with MesaGGI. It would be a shame if all the work (on MesaGGI as well as our GLDrawingKit) would go into oblivion ! Any help is as always highly appreciated, Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin... -- -Jay
Re: problems with libgii
Marcus Sundberg wrote:
Jay [EMAIL PROTECTED] writes:
I can't show everything just yet, but here is what I can. This is all of the gii
stuff:
Ok, should be enough.
/* This is where I have to do stuff wrong or my keyboard doesn't work
Keep in mind I am useing the SVGALIB target; it might be the problem */
giiInit();
inp=giiOpen("input-null", NULL);
if (inp==NULL) {
fprintf(stderr, "Error in input libgii, bailing out...");
S9xExit();
}
kbd=giiOpen("input-linux-kbd",NULL);
if (kbd==NULL) {
fprintf(stderr, "Error getting keyboard, bailing out...");
S9xExit();
}
mouse=giiOpen("input-linux-mouse",NULL);
/* I don't think the mouse has ever accually worked */
if (mouse==NULL) {
fprintf(stderr, "Error getting mouse, oh well...");
inp=giiJoinInputs(inp, kbd);
} else {
inp=giiJoinInputs(inp, kbd);
inp=giiJoinInputs(inp, mouse);
}
ggiInit();
vis=ggiOpen(NULL);
if (vis==NULL) {
fprintf(stderr, "Error getting visual");
S9xExit();
}
Ok, this code is utterly broken. You can't open inputs allready used
by LibGGI. Start by removing _all_ occurences of gii* functions. If
there's still a problem, run your program with GGI_DEBUG=255 and we
can start debugging things.
Yes, this code was utterly borken, but it is fixed now.
if (ggiSetGraphMode(vis, 640, 480, 640, 480, GT_32BIT)) {
fprintf(stderr, "Error getting visual");
S9xExit();
}
} else {
halfxres=320/2;
halfyres=240/2;
if (ggiSetGraphMode(vis, 320, 240, 320, 240, GT_32BIT)) {
fprintf(stderr, "Error getting visual");
S9xExit();
}
Also never hardcode values which you don't care about, like in this
case the virtual size.
GGI_AUTO is now put in their place
case GIIK_P4: byte4 = 1; break;
case GIIK_P6: byte4 = 2; break;
case GIIK_P2: byte4 = 4; break;
case GIIK_P8: byte4 = 8; break;
The sym filed of a key event can never contain any of these. The sym
field describes the meaning of the key, which would be plain '4', '6',
'2' and '8' respectively for the above keys.
case GIIK_PEnter: byte4 = 16; break; // Start
case GIIK_PPlus:byte4 = 32; break; // Select
Neither can it contain any of these. Sym field would be GIIK_Enter and
GIIK_Plus (which is equivalent to '+').
Then how can I get keys from the keypad?
case 27:S9xExit (); break;
Broken assumption, use GIIK_Escape.
I think you mean GIIUC_Escape. Done
You might want to consider using the label field as the sym field
will change for many keys when you have a modifier pressed. For
things like '+', '-' and other non-alphanumeric symbols it is however
wise to check the sym field as many keyboard maps don't have these
on an unshifted keys.
What does label accually do? I tried that, but none of the letter keys worked. So
your saying I need to check both sym and label? I beleve my only problem now is that
the GIIK_P* keys don't work. what do I need to check for that? label doesn't seem to
have any effect on that.
By the way, thanks for helping me clean up the code. I haven't had much of a need for
input in my GGI programs until now, so I knew absolutly nothing about gii events
other than the fact that they existed.
ALLRIGHT!!! ggisnes9x is now ready for release!
I don't know what my problem was, but I suspect it was this:
The way I fixed the problem was to simply "export GGI_DISPLAY=display-svgalib" on the
command line. Also, libggi segfaults in X unless I use "export GGI_DISPLAY=display-x"
or "export GGI_DISPLAY=display-xlib"
I don't really want to speculate, but this is all I can think of that could happen:
When ggiInit() is called, it goes through a list of targets in a certian order until
it finds a working target. The problem is for each target it attempts to open, it
calls libgii before it knows if the target works. That means everytime it fails to
get a display (such as fb-dev) libgii is called before libggi knows whats going on!
libgii cannot backout, and therefore, the running app segfaults. This might be due to
threads.
I don't accually beleave this is what was happening, but thats what I came up with.
Can you come up with something better?
Oh, and the ggisnes9x isn't released on the snes9x main page yet because the snes9x
guys take a really long time to check their e-mail (2 days maybe), but they have
asked me if I was done se
Re: problems with libgii
Thanks, I'll make sure to add your corrections as well. Oh, and ggiJoinInputs isn't
nessessary ggiInit takes care of it. My problem was a bug in eather libggi or libgii (I
don't know which, gdb won't tell me) that requires me to explisitly tell libggi through
the GGI_DISPLAY environment variable to whatever target I wish to use.
Christoph Egger wrote:
On 26 May 2000, Marcus Sundberg wrote:
Jay [EMAIL PROTECTED] writes:
I can't show everything just yet, but here is what I can. This is all of the gii
stuff:
Ok, should be enough.
/* This is where I have to do stuff wrong or my keyboard doesn't work
Keep in mind I am useing the SVGALIB target; it might be the problem */
giiInit();
inp=giiOpen("input-null", NULL);
if (inp==NULL) {
fprintf(stderr, "Error in input libgii, bailing out...");
S9xExit();
}
kbd=giiOpen("input-linux-kbd",NULL);
if (kbd==NULL) {
fprintf(stderr, "Error getting keyboard, bailing out...");
S9xExit();
}
mouse=giiOpen("input-linux-mouse",NULL);
/* I don't think the mouse has ever accually worked */
if (mouse==NULL) {
fprintf(stderr, "Error getting mouse, oh well...");
inp=giiJoinInputs(inp, kbd);
} else {
inp=giiJoinInputs(inp, kbd);
inp=giiJoinInputs(inp, mouse);
}
ggiInit();
vis=ggiOpen(NULL);
if (vis==NULL) {
fprintf(stderr, "Error getting visual");
S9xExit();
}
Ok, this code is utterly broken. You can't open inputs allready used
by LibGGI. Start by removing _all_ occurences of gii* functions. If
there's still a problem, run your program with GGI_DEBUG=255 and we
can start debugging things.
Yes, and use ggiJoinInputs instead of giiJoinInputs.
if (ggiSetGraphMode(vis, 640, 480, 640, 480, GT_32BIT)) {
fprintf(stderr, "Error getting visual");
S9xExit();
}
} else {
halfxres=320/2;
halfyres=240/2;
if (ggiSetGraphMode(vis, 320, 240, 320, 240, GT_32BIT)) {
fprintf(stderr, "Error getting visual");
S9xExit();
}
Also never hardcode values which you don't care about, like in this
case the virtual size.
Yes, GGI_AUTO should be used instead...
And it is recommended to check if the return-value of ggiSetGraphMode
is 0, because values 0 always indicates an error. Values 0 are
AFAIK still undefined and reserved for future developments.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
--
-Jay
Re: problems with libgii
Oh, I have to add, I have put the giiInit stuff before the ggiInit stuff in the file
I sent you. I have tried it both ways. Apparently, libggi does not open
input-linux-kbd as it should on my system. Again, I beleave this is because of the
SVGALIB target.
As soon as the Snes9x people get back with me, I'll post the full file.
Marcus Sundberg wrote:
Jay [EMAIL PROTECTED] writes:
Well, then what I'm doing is extreemly wrong. But if I do it any other way I get
a segfault. On the console I must do this to get anything to work:
giiInit();
kbd=giiOpen("input-linux-kbd",NULL);
if (kbd==NULL) {
fprintf(stderr, "Error getting keyboard, bailing out...");
exit(1);
}
I suspected something like this. You can't open input-linux-kbd
if you are using LibGGI. And I still can't help you unless I know
what your code looks like and what you are trying to achieve.
//Marcus
--
---+
Marcus Sundberg| http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: problems with libgii
"Brian S. Julin" wrote:
On Sun, 21 May 2000, Jay wrote:
Marcus Sundberg wrote:
If you are calling any gii* functions you are likely (but not
necessarily) doing something wrong. I need to look at the full
code to know for certain though.
Really? Then how am I supposed to get input?
With the ggi* functions. Unless you are not using a visual there's
rarely a reason to use gii* functions when the equivalent ggi* functions
are available.
(P.S. Stay tuned, I'm working on a libGII-only app that essentially adds
FN key macros, scripts, and pseudo command-history on a host-by-host basis for
people needing to telnet around to network gear and such, being as I
need one at work. Sort of like a com program, but without the full-screen
terminal emulator or rs232 baggage, and far more customizable.)
--
Brian
Well, then what I'm doing is extreemly wrong. But if I do it any other way I get
a segfault. On the console I must do this to get anything to work:
giiInit();
kbd=giiOpen("input-linux-kbd",NULL);
if (kbd==NULL) {
fprintf(stderr, "Error getting keyboard, bailing out...");
exit(1);
}
In X I must also do something simmilar, or segfault. I got my last package on the
7th of this month.
--
-Jay
Re: problems with libgii
Marcus Sundberg wrote: If you are calling any gii* functions you are likely (but not necessarily) doing something wrong. I need to look at the full code to know for certain though. Really? Then how am I supposed to get input? Do you have snes9x and at least one snes ROM?
Re: Hurd Help! -- FW: colortext translator
Ok, I know nothing about the Hurd... yet. I went to a few pages to learn more about what you were talking about and I liked it so much, that I am swiching to the Hurd soon :-) BUT, from what I saw (and I must say again, I have NO experence with the Hurd yet) all you would need to do is make a daemon that talks directly to the hardware (about like X) in user space and leave the micro- kernel alone. In other words, make a "KGI server"-like daemon. This might sound horrable to Linux (and other non-MACH micro-kernel) users, but it seems to be the Hurd's way. I mean look at what "Hurd" means: Hird of UNIX-replaceing daemons. (Sorry, I can't remember what "Hird" meant) Does anybody have a daemon like this? Again, Hurd dudes, feel free to shut me up if I am saying this wrong. GGI Folks: A few Hurd folks are making noises about porting KGI/GGI onto the Hurd. At one time a few of you were somewhat interested in this, but didn't make much progress. Can a kind, knowledgable soul join our "debian-hurd" mailing list and provide some technical support? The main questions we are trying to resolve are: 1. How to best break KGI/GGI into a kernel/user codebase. Most processes (such as the ext2 filesystem) live in "user" space. Only very specific things go in the microkernel -- those things that have to deal directly with the hardware. 2. How best to get FB support into the microkernel. We already have some glue code in place to make use of various Linux device drivers. It shouldn't be too terrible to get others working now. Unfortunately, most of the drivers are Linux 2.0.36 level, but we could probably update the glue code for more modern stuff. Attached is a recent debian-hurd message from one of the two independent console-coding efforts that started recently. Instead of this, we would really like to jump directly to the GGI console. -Brent -Original Message- From: Marcus Brinkmann [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 29, 1999 4:47 PM To: Kalle Olavi Niemitalo Subject: Re: colortext translator Hi Kalle, On Thu, Sep 30, 1999 at 01:32:44AM +0300, Kalle Olavi Niemitalo wrote: Thomas wrote those features wouldn't belong in /hurd/term, so I'm writing a separate translator. Mmmh. I see. Reading from it would translate scancodes from the keyboard, and writing to it would interpret escape sequences and poke characters in video memory. The output half now lacks only virtual consoles, scrollback and beeping. Sounds good. Had you told earlier that you make such a steady progress, I probably would not have spent the last days to get the linux console working. (Are you subscribed to bug-hurd? You must have noticed my screams for help :) What you mean should probably be handled by a device similar to framebuffer device in Linux. Are you implying that device wouldn't parse the escape sequences? Sorry, I hadn't all my senses together when writing this. E0 scancode line--- keymap --- translation --- inb() sh --- discipline --- esc seq -- framebuffer --- poke to parser for each vc vid mem The line discipline is handled by /hurd/term. I imagine everything at its right side would be in /hurd/console, except the inb() which would stay in the kernel. How would you split them up? Looks great! I have to admit I didn't know much about terminals at all until a few days ago, but I am learning fast. I think what you are doing is great (as it seems to give fast results, fits nice into the Hurd philosophy and the current code and gives you practice in writing translators). However, I still think it would be good to take a look at KGI, before you start to reinvent the wheel. But if you limit yourself to one EGA adapter and one input keyboard, there is no danger in doing so, and porting KGI would probably be a major undertaking. Have you looked at KGI yet? It is supposed to enable multihead/multiinput terminals. It virtualizes the mouse device. It has interfaces for libggi, enabling us to use the vgalib emulation and X server from the GGI project. It also has a terminal server. I don't know how much work it would be to form KGI into a proper Hurd translator. Can you take a look at it? A snapshot can be found in http://www.tu-chemnitz.de/~sse/ggi/. Also, how interacts your translator with the kernel logger? How does it interact with the keyboard driver (we need to make sure we can get X working with it in some way). Those are all questions I don't know an answer for (I face the same questions with the linux console driver in GNU Mach). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09
