Re: (Logging in to bjulin@cvs.ggi-project.org)
Andreas Beck wrote: You mean for implementing "DirectSound" and friends ? Yeah, well they have that, but with the ALSA drivers I think the OSS emulation is forcing WINE to use a degraded mode; it complains about no direct access. So I was thinking maybe I'd see if GSI could be sandwiched in there, too, supposing it has hooks for direct access. Hmm - don't think that is possible. GSI is pretty highlevel. Kind of the contrary what you want. Most of the libraries aren't (the pcm lib e.g.). At least in the 0.9.x version. Haven't updated the code in a while due to other work btw. Is "direct access" DMA? There's code to set DMA etc., but not tested and it needs some work. Wouter
Re: Porting news
Andreas Beck wrote: I'll ask on the GGI mailing list. Anyone knows where to find a working Glide for FreeBSD ? I tried compiling it a while back (The version for a voodoo3). No go. I had to change lots of things (like disabling AMD opcode generation, makefile changes, some assembly file changes of which I'm not sure if they were ok, etc.) and got nowhere. Didn't get any response from the mails I sent to the 3dfx guys about the problems and my patches... [ I guess one should get on glide-source-forge the mailing list for feedback .. ] Oh, also needed to install some newer binutils, actually just one program (not sure which one it was). Coleman: What kind of graphics card do you have ? If it's supported by KGI, that would help when trying to port that part over as well ... I have a Matrox G200 and a Matrox Mystique 220. Dual-Head X. O.K. - AFAIK the Matrox cards are supported by the kgicon layer. That will help porting the native drivers over. So, there's a porting effort underway again? I got totally bored with finishing my attempt, but I'm willing to help if there's a need (Not sure if I still have the glide source + my changes lying around, I'll have a look). Regards, Wouter
Re: ggiplay
Rubén wrote: On 2000/Jan/13, W.H.Scholten wrote: Well, not precompiled. What I mean is that it uses an abstracted system of pcm/mixer/synth/cd in directly accessable libraries. Compile the libraries for a new audio system and the server would work on the other API. This is a problem to the distributions. Note that if I want to pack this software into a Debian package, I should make a different package for each driver to include with the distribution, and it isn't possible. You should think in other solution, I think. Good point. dlopen is needed then.. I didn't really consider binary packages as e.g. the API wasn't quite stable yet. What? Two people making sound stuff? GGL hasn't still sound support, and I think that it would be good to use somehing like GGI for the sound module, as GSI seems to be. We should (Teunis also) continue with this discussion in other part, I'm very interested, and the GGL people has some ideas on the sound support that could interest you. Ok. mail or another mailing list? Regards, Wouter
Re: ggiplay
[EMAIL PROTECTED] wrote: Hi Wouter ! Wie geht's ! [ mail ] Oops - assumed he already did ... Teunis mailed me after I posted ;) This is quite a bit different from your current needs which are pretty much streaming large amounts of PCM data in a synchronized way. Streams are handled by GSI 0.8.x. Synchronizing, well, in that case shared memory streams are probably the way to go (not completed in 0.8.x). Ah. ggiplay is a simple mov-player based on the quicktime4linux library I wrote to have a look at the lib. So synchronization is an important issue for that stuff as nothing looks worse, than a movie not in sync with the text. Yes, well, GSI's streaming is command/message based. The command to the server is a blocksize + block data. The message from the server is the amount of data the server has processed so if the server is too slow (held up by disk access etc), or too fast, you can insert silence or skip transferring a block depending on the case. That should keep the difference reasonable but a shm/semaphore approach would be better. Yes - a GGI-like Lib would be interesting, as there are at least: OSS, Kernel native drivers, ALSA, network audio servers, dumb /dev/audios, the Win stuff ... Check out the library oranization of 0.9.x: gsipcm, gsicd, gsisynth (abstraction in this case is a mistake I think, just do midi and new libs for other formats), gsimixer, and (lib)gsi is the network connection stuff. This sounds good. You mean, that LibGSI already has the ability to as transparently as possible run on about every underlying sounddriver ? Well, not precompiled. What I mean is that it uses an abstracted system of pcm/mixer/synth/cd in directly accessable libraries. Compile the libraries for a new audio system and the server would work on the other API. Contrary to graphics, there's not much point in having the sound system dynamically determine what is available as these system are all kernel based and very few people switch kernels or unload/reload modules just to use another system. It would be different for using audiosystems like NAS/esound etc. but this is a nuisance to program (a huge one! for me at least) and not as useful as for a graphics libs. Also, I'm a bit put off by the dlopen portability nightmare (haven't looked at libtool yet). On a related note, I sent a patch to Neal Tucker for his spin-2 demo (which uses dlopen and some other ld magic) for FreeBSD, but haven't been able to get it running on OpenBSD. Due to the abstraction used for all these libraries though, it would be easy to make it dynamic (the OSS/devaudio/ultra etc code all use the same api_* functions that can be set to refer to a dlopen'ed symbol). Great, then. I should update my copy to have a look (though it works for me as is :-). Not too fast ;) 0.9.x is a devel version. Various things are broken due to enormous changes. Also, I've been working on other things so development has been slow last few months. But as Teunis seemed to be thinking of writing a complete audio system I thought it would be a good idea to let it be known how 0.9.x is organized. Regards, Wouter
Re: ggiplay
Andreas Beck wrote: - What do I do for sound? I could use GSI (which does -not- work for me... the daemon -never- starts)... Maybe I should look at a GGI-style sound management library? Why doesn't whoever wrote this contact me? Help is just an email away and duplicating effort is a bad idea (the whole thing is BSD-2 licenced now btw). Hmm - last time I looked, GSI was geared towards action style games. I.e. free running midi/CD plus 3D positioned sound-effects. This is quite a bit different from your current needs which are pretty much streaming large amounts of PCM data in a synchronized way. Streams are handled by GSI 0.8.x. Synchronizing, well, in that case shared memory streams are probably the way to go (not completed in 0.8.x). Yes - a GGI-like Lib would be interesting, as there are at least: OSS, Kernel native drivers, ALSA, network audio servers, dumb /dev/audios, the Win stuff ... Check out the library oranization of 0.9.x: gsipcm, gsicd, gsisynth (abstraction in this case is a mistake I think, just do midi and new libs for other formats), gsimixer, and (lib)gsi is the network connection stuff. Unifying this would be great ... but it will need quite some effort and study of all possible targets to get it right. Hmm. Have a look at 0.9.x. Anyone want to help? Wouter
Re: Keyboard vs Joystick buttons
Rubén wrote:
I'm giving Joystick support to GGL, and it's almost done, but I
found a little problem. The joystick buttons are reported in a evKey event,
so, the GGL keyboard device gets its own events and also the joystick
ones...
I open the joystick by opening a gii_input_t of type "linux-joy",
and then calling ggiJoinInputs with the ggi_visual_t and the new
gii_input_t.
I know that I can access to event-any.origin to distingish between
keyboard and joystick events, but how can I know which value is the keyboard
one and which is the joystick one? In a few proofs that I've made the
keyboard events had the 0100 value and the joystick the 0200, but I don't
know if it is always this way.
Can anybody help me, please?
I mailed a test program for gii a while back to the list. This is a
little better than the gii test demo and shows two methods:
1. giiQueryDeviceInfo
2. giiQueryDeviceInfobyNumber
and then check the number of axes.
1 has the disadvantage that one already must have received/processed an
event!
A little bit from the program:
if (device_no -1) {
printf("giiQueryDeviceInfo returned: %d\n", giiQueryDeviceInfo(inp,
device_no, devinfo));
printf("%s (%s):\n can generate: %x\n num buttons: %x\n num axes:
%x\n",
devinfo.longname, devinfo.shortname,
devinfo.can_generate,
devinfo.num_buttons, devinfo.num_axes
);
}
Wouter
