Re: DirectX
On Mon, 13 Dec 1999, James Simmons wrote: I had a interesting discussion on the possiblility of having a Direct X on linux with John Carmack. Well it appears Mircosoft will sue anyone that tries that. So I talked to him about Mesa-GGI and how Direct X support was added to libGGI. So to the person that wrote the Direct X interface. Do you think you have a enough of a bridge between Direct X and GGI to allow Mesa-GGI programs to run on top of Direct X completely? If not what features do you feel libGGI lacks to have this happen? Also can libGGI handle DMA transfers, AGP? Does it have enough of a API to implement textures and other 3D functions? Hmm. Interesting situation. I wonder if Microsoft will get mad that wine has working directX? :) [even direct3D based on Mesa IIRC :] Anyways as far as I know (and I don't know much): - 3D accel within GGI is currently targetted at writing hw drivers for Mesa. [I'm going to look into this for 3Dfx Banshee driver actually now that it's gone open-source :] - wonder if a fbdev/glide Mesa driver could be done? Then run an X that runs under that - 2D accel is limited - non-video buffers within the videocard (ie Z-buffers) are afaik accounted for within the directbuffer api specs but also afaik nobody's bothered writing an implementation - AGP should be handled by some sort of libAGP extension. I haven't seen even a proposal for how this should be done. Incidentally, the 3Dfx driver seems to have AGP support... A big problem I've found with the GGI project is that noone really knows how acceleration -should- be handled between kernel and userspace. or even which methods are most appropriate. And many of the interfaces developed (ping/pong buffers as an example) are either currently unusable or not really tested all that much. I'd -love- to see some sort of formal FAQ/RFC on this issue... anyone? The DRI solution is a -bad- one (unsecure and -dangerous- if something goes wrong. Such as mixing a DRI driver with an fbdev driver *sigh*). Some issues I can think of: - Some cards have -very- good DMA support (I think the permedia, 3Dfx, and some others fall into this category but I'm not sure) : these should be easy to code potentially and most work will be done in userspace - Some cards are -dangerous- for DMA work but doable, some sort of translation IP-stack-style would probably be good (S3 ViRGE comes to mind here) - Some cards are strictly PIO-based. Mostly old pre-3D cards really ioctls work well here : this is the current working accel format as far as I know. Don't expect impressive performance, switching between kernel and userspace has a fare bit of delay... but for a complex accel this should work well. Also on that last one, some cards are incredibly dangerous to allow any kind of direct access; all commands should be controlled to prevent abuse. Extreme examples are that it -is- possible to blow up many cards by misprogramming graphics modes. Particularily older cards. I've heard of (Paradise VGA?) cards being lost this way. Approaches I can think about and have heard: DRI - Open a direct-tunnel to graphics card, kernel directs data AFAIK ping-pong - have a buffer of a group of accels, tell the kernel to read and execute from buffer; should be fast. Does this work currently? ioctl - Bad for small accels (eg. colour change) but should be good for large renders. the kernel FB drivers fall under the last when accelerated at all. Works well for me on my card :) The new network drivers (2.3 current) have an extra option for shared-memory access to network. I'd love to see how that works and see if it could be implemented (or something similar) for graphics cards. Maybe some of the problems with DRI could be solved by only allowing superuser access but this kind of duplicates the svgalib problems. Ideas? And anyone know if the DRI method solves the current security holes (denial of service/crashes) possible with userspace X? G'day, eh? :) - Teunis PS: Really take this message with a grain of salt. I'd -love- feedback. I'm probably out to lunch on a lot of this - I haven't read the source enough. (and last I played I was mucking about with ioctl accels under S3 ViRGE and I totally mucked my 3Dfx DRI driver up 'til I downloaded a working one :)
DirectX and here's my attempt at a FAQ :)
On Tue, 14 Dec 1999, Jon M. Taylor wrote: On Mon, 13 Dec 1999, teunis wrote: And many of the interfaces developed (ping/pong buffers as an example) are either currently unusable or not really tested all that much. I'd -love- to see some sort of formal FAQ/RFC on this issue... anyone? Lots of mailing list posts, plus I wrote up a detailed explanation of PP bufs for John Carmack once. I'll try to pull all of this togther into a comprehensive FAQ when I have some time. Looks like I'll give it a try :) Anyways, here goes: --- This is an attempt at a FAQ/RFC for GGI work towards a hardware-accelerated system. I've never written a FAQ before so please let me know. I'm available at [EMAIL PROTECTED] AFAIK which'll point to my real address... Q: Is this going to be directX? A: No. Never. But -someone- will eventually write a library that makes it look like it. After all we don't want to fall into many of the holes that Microsoft fell into or be trapped into Someone Else's Problem. It's best if we make a whole new set of holes of our own *grin*. Q: How does 2D acceleration look? A: Very little acceleration yet. See below for more information on how it's currently being done. Q: What's being looked at for 3D acceleration? A: Currently work is going into making sure Mesa has 3D accelerator support. Long-term goal is to get libGGI3D up and running to handle 3D-accels. Q: does glide work for display? A: yes. glide-2 and below. glide-3 is pretty much X-only and has some hoopy stuff about it. It's also only in beta yet. Q: I see a Mesa-GGI target in my beta cvs-download of Mesa. Does it support acceleration? A: no. (please someone let me know when it is :) Anyways I phrased it this way as the publically available Mesa/GGI target has never worked for me. The CVS usually does with only limited patching *grin* Q: How do I send textures to my videocard? A: Oh a complicated question. As far as I know one can request access to the memory on the videocard and just read/write to there. I don't think there's really anything written for this yet. directbuffer documentation does handle this but it's unimplemented: - Someone says one should open a large block of memory. Why not a 'texturepool' directbuffer request? - Any other issues? :) Q: How do I open a Z-buffer, alpha-buffer, ... to the card? (ie a buffer that'll be used to render the display but not directly for display) A: This is a driver issue. Ideally it should be setup by, say, Mesa through the standard OpenGL methods - then Mesa talks to the kernel driver or perhaps libGGI3d and then sets it up for you. Same on the texture memory above. But the technicalities on -how- this should work are... undecided. Q: Can KGI, FBdev, ... handle DMA transfers? A: Can't see why not. Anyone know of a driver setup for this? And anyone know how one can talk to DMA from userspace? :) Q: Can KGI, FBdev, ... handle AGP acceleration? A: 2.3.30 added generic AGP support. If anyone know how AGP is applicable to video-acceleration, let me know, eh? :) - TODO : libAGP? Prolly... Q: What's the difference between DMA and MMIO access? A: DMA uses a memory buffer that's shared between hardware and the computer that's =64K in size. MMIO just makes itself look like part of the computer's memory. Q: Why shouldn't video setup be handled in userspace such as X currently does? A: Because a partial or corrupted write to the videocard could nuke the card, monitor, ... See VGAdoc or the GGI mailing list for past examples. Also, it's really nice to be able to open multiple accesses to the videocard. Opening X multiple times is just too resource-intense and not particularily stable due to the previous note. /Aside: Please noone say -how- this can be done here. Let those who want to know learn the hard way (or ask on ggi-devel or something). That it -can- be done is bad enough. It's not like it's hidden knowledge or anything, just not appopriate here. /Aside end. This is one of the reasons why DRI is a Bad Thing. Security and stability should be the preferences of an OS. Even if it sacrifices some speed. Arguments? :) Q: How does one talk to an accelerator? A: Depends on the card. Possible routes: (/Aside: Anyone know how the SGI direct rendering system works? /Aside end) Directly talk to the videocard: Crash city. If your app crashes kiss your display goodbye. If it's got good keyboard support and you have a recovery app maybe it'll work. Examples: svgalib. Crashing's not always recoverable... Also you can't use interrupts or DMA. X works this way too currently but is farely well tested so doesn't tend to make your display unusable when it dies... (I do mean
Re: ggiplay
On Wed, 12 Jan 2000, Andreas Beck wrote: I've been playing a 'wee' bit with ggiplay (the quicktime movie player). Ah - good. Nice to see someone uses/enhances it. - smooth scaling (bad habit for me :) *grin* - how about finally writing a scale target ? I still say I don't know how to do it. Now it's for a simpler reason - I don't really know what method I want to use for it. Gotta admit the code is -fast-! :) [I get faster performance from the scaling code onto directbuffer than I do from a crossblit... or maybe the same. It's pretty close anyways :] Update: now multithreaded: Primary reader; secondary renderer. Renderer is designed to toss frames if it's falling behind too far (but still needs a little work to really handle RT-type stuff). Audio is next after that.. *grin*. Note that inter-thread messaging is -evil- and requires lots of lock-management prone to lockups. Debug this under X using printfs as anything else crashes. ***stupid gdb*** that's supposed to handle threads still complains of "unknown signals". Ummm... Should I just go directbuffer and build a renderer-target fallback that uses crossblit? Oh, I guess so... - 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? 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. 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 ... Unifying this would be great ... but it will need quite some effort and study of all possible targets to get it right. Got it. I will take a peek but more below. Anyone have any ideas? Current todo: - Allow PCM transmit/streamed with synchronization - Allow PCM receive/streamed also with synchronization - allow sharing with ViaVoice so voice-recognition can be mixed with music playing I picked the beta up of this package and it's -cool-! (IBM's dev section) - Allow multiple transmit streams | mixing - 3D streamed data, possibly more. Doesn't really make a lot of sense unless you have something like background music being mixed with, say, incoming voice transmissions *grin* Or with MIDI-emu or MOD/XM/S3M/... players... - Maybe a MIDI handler? Maybe later... Or could spawn TiMiDiTy into one (or two) of the data-streams to handle this. I realize this is a little off-topic for GGI but I thought I'd approach it here as there's gamer-types :) - Sound-management -requires- threads! (or at least processes ie: fork() + SYSV semaphores shared mem, though most sound can be done with just fork() and a pipe) I see. Yes - at least in the way OSS supports stuff now. With ALSA style access to DMA pointers and stuff, I can see single-threaded versions, but it would still be a bit clumsy. It's a -lot- easier to do it message-based/multithreaded. I've just finished testing/running a very primitive messaging system :) - Also threading and portability. Linux threads are not compatible with Windows threading. And not with any other Unix's AFAIK. Maybe another idea? I really don't know. Linux's threading model is -very- efficient. Do you know if there's a pthread-lib for Windows? Well - there is always one - forgot the name -, but IIRC it is not preemptive. preemptive only. Now it -can- be done cooperative but I haven't really designed this system for that. Generally cooperatively-threaded systems have to be pretty custom-designed. Now a GTK or X program can get away with it, but not something that's not message-based to begin with. Ummm.. Folks, let me know if I should post this anywhere... I've still got my geocities account (www.geocities.com/Tokyo/Spa/1076/index.html or for that matter http://www.geocities.com/winterlion/ :) There's my patch for abuse to run under GGI there. It's also got my original scaling-toys in that code IIRC... [I also have a scaling patch for d1x and snes9x if anyone wants... should I? :] That scaling target -could- be made smart and told "go to this resolution if [x..y] resolutions are selected and go to that resolution if [a..b] resolutions are selected"... Any ideas? :) I'm still not sure how to approach this... G'day, eh? :) - Teunis
Re: ggiplay
On Sun, 16 Jan 2000, W.H.Scholten wrote: 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. Q: Got a driver/protocol/divisioning chart? Some kinda explanation to why things are laid out the way they are and maybe what parts do what? I keep thinking of doing something akin to Windows Media system / modular with divisions of modules. (ie: use GGI/GII as a root for driver methods, and the Windows Media system as a starting point for what and how to set it up? :) Windows Media system has lotsa problems that Linux has solved I know. But it's a good way to look at it circa how HW driver people see things. Oh, and if it can have a GGI hookup, I can start writing video codecs and toys (or at least importing them :) 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? Haven't the foggiest. Sound is pretty important and can get pretty complex. To be entirely honest, the only reason I'm using GSI versus something like mikmod is a: I think the GSI approach is a little more elegant and scalable, and b: mikmod's audio drivers are fubar some of the time on my system. From a -design- flaw. PS: Permissions on my audio devices tend to change from time to time. *Growl*. I can't control it, it seems like X or something is overriding things... if permissions aren't -perfect- mikmod errors out. G'day, eh? :) - Teunis
on void pointers and invisibility
On Sun, 16 Jan 2000, Erik Thiele wrote:
[clip]
is everything in ggi a void* ?
This is a valid point. We do that void * stuff on pupose to make sure users
don't try to dereference stuff they shouldn't (bypassing the encapsulation
rule and the access layers). However in cases like yours, it's in the way ...
Ideas ?
i never contributed to ggi, and do not really know about it's structure.
but if you ask me this question, i just think it is bad style.
in my eyes it is a very bad idea to do something in a void* just to
ensure nobody dereferences it.
i think it is enough to say "you mustn't dereference it, it is internal"
you not need to force users to this via void*
i think better style to write things as they really are.
not casting void* to something else internally, but just always using
the correct type.
- improves debugging (you really see the structure, not a nonsensical void
pointer)
- the compiler won't compile stupid code anymore (type safety)
- eliminates casts from void* to something else in the internal
ggi library.
for me the idea with the void* is very bad design.
void* is officially in computer science a valid idea :)
It has to do with the publically accessed side having full informational
access to something which may vary behind the scenes.
Stylistically, from what I remember in CS, a void* is the ultimate example
of the minimum front-end required to talk to an object where the
behind-the-scenes code can vary. It's the old implementation/interface
barrier. It's "Good Practice" officially AFAIK.
A void* system solves these problems:
- Object-based system where the real structure is a superset of some basic
type, such as struct base {int type; };
- User data can be set to a void* container and not be touched by the
driver-side - just remembered. (callbacks)
- Driver data can be stored here, and it can be driver-specific stuff such
as the X contexts and Windows thread-ID's for example.
Plus prolly other things I can't think of right now.
G'day, eh? :)
- Teunis
that ggiplay proggie I'm working on and libGII...
Okay, I've found a problem with libGII...
It's adding delays to that quicktime-player (and soon mpeg too! :) that
I'm playing with... Resulting in blank spots in the audio and the
occasional dropped video frame.
Any ideas for how to solve this one? The thing's multithreaded enough...
I suppose I could add an I/O thread but I'm not sure how generic it should
be made.
Can GII eventstacks be made to communicate cross-thread? (without
crashing or locking up that is... :)
Is it worth it?
And how are other people handling this problem? I suspect it has to do
with the joystick-handler now that I have a USB Joystick plugged in.
(linux-2.3.39 has -great- USB code :)
I can disable the event-checking but it takes all the fun out of it
*pout*. And it's FUN to listen to REM's "Shiny Happy People" backwards!
(the original ggiplay could play videos backwards. So when I added sound
I made it so sound could be played backwards too :)
that and rendering on fbdev means without events I have to hit SAK to
quit. Boring!
Just curious...
G'day, eh? :)
- Teunis
Re: Eastern language keyboard events
On Sun, 23 Jan 2000, Steve Cheng wrote:
On Sat, Jan 22, 2000 at 04:05:06PM -0800, Jon M. Taylor wrote:
Nice, eh? The unfortunate truth is that this crazy input system
is pretty much required, due to the highly contextualized nature of the
Japanese language. The Kanji for 'Zen' (for example) can have over 20
completely different meanings when used in different grammatical contexts.
Unless you keep track of the running context, it is impossible to
accurately translate subsequently entered Kanji syllables into Kanji
words. This more or less requires a full Japanese grammar engine be
embedded into the input protocol itself |-/.
There are free programs which do this kana - kanji conversion (Wnn,
Canna, etc.).
As far a Chinese and Korean are concerned, I really don't know
that much. I think that the Chinese and Japanese kanji are mostly the
same, but China does not have a phonemeic written alphabet. And written
Vietnamese is all phonetic (Roman alphabet with a bunch of phonetic
modifications to the basic roman characters).
Chinese input methods are even more difficult. There is a phonetic
syllabary ("bopomofo"), but it is never used in normal writing, only
learning, and only for Mandarin dialect I think. (I speak Cantonese,
read Chinese, but still don't know the syllabary.)
Various Chinese input methods use the strokes/radical of the kanji... I
don't know how to use them myself and have not seen any documentation on
it, so I can't tell you much. Using a tablet and (CJK) writing
recognition software for input is quite popular here, but unfortunately
the products are all for Windows :(
Now I -have- seen how Chinese input methods are typically done... at
least as far as IBM is concerned with their North American distrib. (I
stopped by and visited a large IBM store and checked it out there a ways
back :)
Anyways, you have about 5 keys (IIRC) mapped to different strokes. A key
is used to bring up the entry window and you tap strokes, and the menu
gives choices of valid characters from that list. IMHO I like it better
than the various Japanese systems I've seen - although you need to know
how many strokes and what order they are in for the characters. (this is
how I learned to write the Chinese characters so... :)
Anyways, once you've selected the character (glyph) you want, it's
inserted where-ever you happen to be.
Now this -was- under OS/2 so Linux may handle it differently. IIRC there
were no extra keys either so I'm not sure how they triggered the character
entry. Though there could have been a key for it.
G'day, eh? :)
- Teunis
Re: that ggiplay proggie I'm working on and libGII...
On 24 Jan 2000, Marcus Sundberg wrote:
teunis [EMAIL PROTECTED] writes:
Okay, I've found a problem with libGII...
It's adding delays to that quicktime-player (and soon mpeg too! :) that
I'm playing with... Resulting in blank spots in the audio and the
occasional dropped video frame.
Huh?
Either you've found a severe bug in LibGII or you are not using
it properly. Exactly what are you doing that causes a "delay" ?
Same polling code as per public ggiplay.
while (ggiEventPoll(vis, emKeyboard|emPointer, start)0)
{
x = ggiEventsQueued(vis, emKeyboard | emPointer);
while (x)
{
gii_event event;
ggiEventRead(vis, event, emKeyboard | emPointer);
/* do stuff */
};
};
Anyways, behind the seens I have a bunch of other stuff going on too.
Several threads monitoring different queues for data. When I disabled the
event testing the gaps in my sound-playing dissappeared. I've now moved
the event-reading to a seperate thread and use a socketpair to pass
translated events along and this works beautifully without delays.
There's definitely a problem. I'm running under fbdev (I -do- have a USB
joystick attached+enabled if that affects anything) under linux-2.3.39 and
a 3dfx/Banshee card [+fbdev driver which only can handle 640x480 *sigh*]
I'm running with typically a 15fps motion-jpeg encoded quicktime - and
this is farely CPU-intensive to decode. The GII/input stuff pushes it
over the mark and I end up losing a lot of frames as it takes
approximately 15% longer than it should to decode and post frames into the
queues.
Any ideas for how to solve this one? The thing's multithreaded enough...
I suppose I could add an I/O thread but I'm not sure how generic it should
be made.
Can GII eventstacks be made to communicate cross-thread? (without
crashing or locking up that is... :)
Sure, just call giiMTInit() and you should be able to to retrieve
and enqueue events from multiple threads simultaneously.
Joining/opening/closing inputs from several threads simultaneously
will still not a good idea though, but that is hardly a problem.
I've decided to just handle I/O from one thread (and may eventually move
this into a seperate process so I can choose different I/O modules :)
G'day, eh? :)
- Teunis
PS: Anyone here know how to handle 'sleeping' for 1 second delays on a
multithreaded app? Currently I'm using pthread_cond_timedwait with a
condition that never gets signalled as nanosleep, usleep, and everything
else I've tried seems to put the entire program to sleep *sigh*
ggiplay if anyone cares. it's alpha. verrry alpha.
http://www.geocities.com/winterlion/index.html - they have a problem when I ftp the index.html in *sigh*. Anyways, test it out, try it out, mail me with comments. It doesn't work with MPEG-1 video. It's -very- CPU-intensive. It has loads of bugs I haven't found yet. It only works with 16,24, and 32bpp depths. On the flip side it should work on any platform with a relatively complete POSIX thread package I'll be posting new versions lots. Or maybe if I get any feedback anyways :) It's being uploaded as I send this... G'day, eh? :) - Teunis
Re: On fbdev [3dfx] and console-switching...
On Tue, 25 Jan 2000, Andreas Beck wrote: Hey, is there any way to catch console-switching? Mah evil program does run in the background... but I get all this funky graphics overwriting whatever console I'm on. Normally, this is done for you. However when you run a LibGGI application in the background, it cannot attach to the console correctly (linux-input will not work due to permission problems and the stdio method will be used as fallback - you should see the cursor still blinking on fbcon on such consoles). AFAIK the only way to solve this, is running the application as root. [clip] Actually I start in the foreground I suspect a bug in fb-3dfx actually. I'm not running it in the background... I just switch consoles while I'm running it :) G'day, eh? :) - Teunis
Re: ggiplay if anyone cares. it's alpha. verrry alpha.
On Tue, 25 Jan 2000 [EMAIL PROTECTED] wrote: On Tue, Jan 25, 2000 at 01:18:06AM -0700, teunis wrote: http://www.geocities.com/winterlion/index.html - they have a problem when I ftp the index.html in *sigh*. [~]$ tar zxvf ggiplay.tgz .. ggiplay/libmpeg2/video/reconstruct.c ggiplay/libmpeg2/video/motion.c ggiplay/libmpeg2/video/mmxidct.S tar: Skipping to next header Okay, I've re-uploaded. Anyways, folks - mpegs have a problem with colours on my machine. For some reason I can't compile the MMX capabilities either. (libmpeg2 is from xmovie-1.2; http://heroine.linuxbox.com - source for quicktime as well :) If anyone spots anything odd, let me know. I've got a few low-priority bugs (potential lost messages in video queue mostly) but it seems to work for me. I don't like Enlightenment Sound Daemon now. It's adding noise and occasionally crashing on startup. And if anyone has any ideas on how to profile a multithreaded app, let me know :) Sorry 'bout all that. I've got this slight tendency to write uploads so if at first you don't succeed, try try again. And for some reason I can't access my own web page? huh? I could yesterday. But I can still upload - I guess they'll figure this out. (http://www.geocities.com/winterlion/index.html) G'day, eh? :) - Teunis
Re: On fbdev [3dfx] and console-switching...
On 26 Jan 2000, Marcus Sundberg wrote: teunis [EMAIL PROTECTED] writes: Hey, is there any way to catch console-switching? See the end of ggi/types.h, and ask if there's something unclear about it. Mah evil program does run in the background... However this should not happen. Applications running on fbdev and svga targets are halted on switch-away unless they have requested GGICMD_NOHALT_ON_UNMAP. How do you do this? I'd really much rather handle this myself. There's no real reason to halt the program - only to halt the renderer. The program itself uses locking queues so when it runs out of space it'll wait for the renderer to wake up. Or just toss the frames it can't draw. (preferably: the latter :) Easy enough to do. Is this by any chance a threaded application? Then I suppose that it might be that only one thread is halted... It's a very threaded application. And halting it would be... unhealthy. To the program anyways. It won't quit if the main thread halts. At least not until you return to it - and if the condition state is not saved it may -never- quit. Right. Must fix. Must fix now. Thanks! :) G'day, eh? :) - Teunis PS: This does work on all appropriate targets, right? (eg: fbdev)
Re: On fbdev [3dfx] and console-switching...
On Wed, 26 Jan 2000, teunis wrote: On 26 Jan 2000, Marcus Sundberg wrote: teunis [EMAIL PROTECTED] writes: Hey, is there any way to catch console-switching? See the end of ggi/types.h, and ask if there's something unclear about it. Okay. It's not clear. [clip] Now how am I supposed to use this? G'day, eh? :) - Teunis
Re: on profiling, multithreading, and file I/O.
On Thu, 27 Jan 2000, Paul Duran wrote: On Wed, Jan 26, 2000 at 11:34:00PM -0700, teunis wrote: [snip] Using a socketpair takes ~17000 milliseconds just to poll(..) to see if there's data. Is there a better way? I -need- to shave this ~17000 milliseconds off! 17000 milliseconds = 17 seconds... are you sure you dont mean microseconds? same for above and below?? Right, sorry. Read microseconds... *sigh* Sorry 'bout that. It's still slow. G'day, eh? :) - Teunis
Hah! Avoid thread programming!
mutex locking time is... *heh* around 26000 microseconds... Longer than poll() Go figure. And you can't do interthread communication without -some- form of locking, be it kernel or userspace. (socket I/O locking is handled in the kernel) Anyways, for future reference : streams are faster than messages. Unless you have a -really- speedy lock-aquisition system... How does this apply to GGI? Easy. Don't do lock-aquisition in commands/etc unless you -have- to. Regardless of how thread-friendly you want it. Graphics programming isn't particularily multithread friendly anyways. You don't really want to have multiple command-streams to most videocards and even worse, mixing rendering with accels can be fatal on some. Now on the flip side, it'd be very handy to have a libGGIthreads library or something to give one a threaded interface to -all- of GGI. Sorry, just playing with massively threaded proggies finding delays :) G'day, eh? :) - Teunis incidentally, mandrake 6.0 + upgraded kernel + compiler
Re: Hah! Avoid thread programming!
On Fri, 28 Jan 2000, Rodolphe Ortalo wrote: 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 to lock in-memory data structures... Which library do you use for threads/mutexes, linuxthread ? POSIX ? linuxthreads - ie threading that comes with glibc-2.1 Oh. by the way, while I'm thinking, how did you do your benchmark ? An empty lock/unlock I guess ? Not by two threads on a uniprocessor I hope (this environment implies a scheduling so... here is your implicit system call) gettimeofday(). Yeah, I know, there's better ways. If anyone can tell me - please! I'm guessing at this at every step. All I know now is with -all- the I/O handling removed from the movie handler except for movie decoding the thing finally plays fluidly on my computer. Most of the time. I think my code's pretty poor actually for movie playing but I don't know how to do it better. Now on the flip side, it'd be very handy to have a libGGIthreads library or something to give one a threaded interface to -all- of GGI. Hmmm. With additional delays, I don't know if it would be worth the work (especially as everyone would try to use for hype and then go back complaining about the performance)... Nevertheless, your application is very interesting with respect to this issue of real-graphic-world MT programming ! Thanks :) [code at http://www.geocities.com/winterlion... its the 'ggiplay' proggy :] It plays linux quicktimes. And mp3's *giggle*. And mpeg-2 multimedia though the renderer's broken. Gonna write my own soon. G'day, eh? :) - Teunis
Re: Windowmanager protocols
On 30 Jan 2000, Peter Bortas wrote: Andreas Beck [EMAIL PROTECTED] writes: This is exactly what I don't want. A major reason why I want to use GGI for this win. manager is that X is a resource killer. Then this is the only way. All X applications talk to libX11, which in turn talks to the x server. The only place where you can intercept the communications before it gets transformed into X protocol requests (interpreting them would mean reinventing an X server), would be to replace LibX11. Doable, but very much work. Afraid not. Quite a few programs talk the raw X-protocol. All programs I wrote before GTK+ emerged did that. This is due to the fact that libX11 is actually not easier to use that the protocol directly and the fact that it (the lib) wasn't thread-safe at the time. Yah know, that explains why my very-multithreaded QT/[broken]mpeg2 player crashes with various faults under X. using GGI for display. Suggestions? :) G'day, eh? :) - Teunis PS: anyone who suggests SYSV stuff should tell me how I should wait for conditions with SYSV items. The shared-mem is not a problem, but the conditions are. Mind you I might just be clueless as it's been years since I last did SYSV stuff.
Re: file-target
On Thu, 3 Feb 2000, Andreas Beck wrote:
+struct file_type_op_t file_type[] =
+{
+{ "ppm", _ggi_file_detect_ppm, NULL, _ggi_file_ppm_write },
+{ "bmp", _ggi_file_detect_bmp, _ggi_file_bmp_read, NULL },
+{ NULL, NULL, NULL, NULL }
+};
Hmm - I'd like it better, if it would read only P?M and use ppmtools to
convert any other format as required.
I'd prefer PNG myself. Or JPEG. Or better, both.
At least with those I know my videodata's stored properly :)
[png up to 48bpp RGB, JPEG stores in YCbCr which I'd rather have for
pictures... :]
And I can't afford the 100Megs it takes to store the ppmtools.
(exageration - it's ~25-40MB depending on compile options). Or have to
hunt down one that will -compile- on my computer. *sigh*
Why don't you just use a file-stream and leave buffering to the libc ?
It's handy for overriding to read from sources -other- than files? :)
(ie: network connections [okay poor example], messaging systems *giggle*,
WWW connections preformatted files ie embedded WWW or gzipped... :)
Oh yeah, and you can support 64bit access too. For files 2GB in size :)
+/* FIXME: compiler fails on using this with: "sizeof applied to an incomplete
type" */
+#define NUM_FILE_TYPES (sizeof(file_type) / sizeof(struct file_type_op_t))
You need to have a complete prototype for file_type_op_t included before you
can use sizeof.
Unless it's a (void*) which is how I normally HANDLE it *giggle*
Anyways, G'day, eh? :)
- Teunis
PS: ignore me if ya want. i'm just a crank...
Re: file-target
On Fri, 4 Feb 2000, Andreas Beck wrote: Hmm - I'd like it better, if it would read only P?M and use ppmtools to convert any other format as required. I'd prefer PNG myself. [clip] -rwxr-xr-x 1 root root19408 Mar 21 1999 /usr/bin/djpeg And I can't afford the 100Megs it takes to store the ppmtools. You only need to install those you need ... Since when? You always have to compile everything. Maybe that should be something that gets attacked GGI-style. Make a nice config script and controllable install of ppmtools :) Be handy. Especially with people with -very- little HD space and need only of one or two tools. (this is why I'm annoyed with ppmtools... I rarely have space to play with them or at least not 'til now :) [clip] (ie: network connections [okay poor example], messaging systems *giggle*, WWW connections preformatted files ie embedded WWW or gzipped... :) These can all be trivially handled by simple filters using pipes, which is very very simple using popen. It's the power of unix to be able to pipe stuff around. I don't know the difference between using FILE* and file handles. I always use file handles myself as I'm frequently multitasking and passing things like sockets and the like around. Oh, and there should be a way to pass FILE* or file-handles (preferably file-handles) to file-target in GGI. That way, the program can send data to it invisibly :) Just because FILE* can't talk to databases or 64bit files or embedded WWW pages or doesn't mean it can't be used :) Also, NO TEMPORARY FILES UNLESS THE CALLING PROGRAM SETS THEM UP. YOU try playing with an uncompressed high-resolution scan 80 megabytes in size. Then watching subprograms create temporary copies. VERY pet peeve. (even worse when working with movies... when the results compressed are 2 gigabytes. *ow*) Anyways, that's all. This is the... uh... 10th or so time I've written this message and I'm getting a little tired of pine losing it on me. *sigh* G'day, eh? :) - Teunis
Re: file-target; Console-utils?
On Sat, 5 Feb 2000 [EMAIL PROTECTED] wrote: [clip] on libggiImg: Release it please :) I suspect SOMEONE will help ya finish it. Unless you're having problems with design I am sorry to have not yet made libggiImg available, I have been too busy with work, and research :( I also have a mostly working libggittf which renders true type fonts, and uses libdb for caching of glyphs, it uses freetype as its backend. ooohhh... toy! *cool*. I -could- use that right now :) -Adam Scislowicz([EMAIL PROTECTED]) P.S: we need something like console-utils for KGI/GII/GGI... Now this reference I don't get. Could you explain? G'day, eh? :) - Teunis PS: If it means getting a console-emu up with graphics support and/or fonts... uhmm, maybe? I've got operational job control now so it should be duable. Except that GGI doesn't really like child processes still tracking that one down 'xcept I have other bugs too so...
Re: targets and ?sources?
On 5 Feb 2000, Marcus Sundberg wrote: [EMAIL PROTECTED] writes: I just started thinking about my last post in a different way. Should we implement something like sources in ggi, wihch would allow frame grabbing, image loading, etc? Yes, it should be implemented in ggi, just not in LibGGI. Image loading should ideally be written as two libraries: One library that does not use LibGGI and does not know about visuals. It should dynamicly load readers/writers for different image formats, and read images into/write imaghes from it's own simple structure (basicly just width, height, format and a pointer to the data). It should also be able to convert images between different formats. The second library should be a simple glue-layer between the first library an LibGGI. The reason to make two libraries that a generic image loader/writer that is _not_ tied to any graphics/window system is badly needed, and the first library will be just that. On image grabbing: This is good, very good. Would work for stills, scanning, digital cameras, On -video- capture (ie stream of messages): No. Absolutely not. Frame grabbing has -terrible- problems with two things: 1. It goes very fast. Hard to capture 30fps at 640x480 straight into a raw buffer... 2. Drivers aren't very stable... *sigh* [for bttv] Anyways, you'd have to do a different interface for -video- capture than for image capture anyways. Mostly due to latency problems. I want that personally (mind you, I don't use GGI to -play- videos either other than to supply a frame to write to ... it doesn't fit the purpose) G'day, eh? :) - Teunis
Re: file-target; Console-utils?
On Sat, 5 Feb 2000 [EMAIL PROTECTED] wrote: on libggiImg: Release it please :) I suspect SOMEONE will help ya finish it. Unless you're having problems with design [clip libggittf] ooohhh... toy! *cool*. I -could- use that right now :) Yes, I keep redesigning it, although this time I promise Ill release both libggiImg and libggittf regardless of there design, I am sure others will be able to polish them off from there. Oh please please. But DO include a wishlist - it'll help others in redesigning same too. Now this reference I don't get. Could you explain? We need some nice command line programs for setmode, screendump, I guess we dont need the other utils in console-tools though, at least not in the same capacity. They are mostly setfont, setcmap, setleds, openvt, chvt... Okay. setmode -- fbset? screendump Ahh, this should be easy in practice but isn't... (what's this do anyways?) setfont - now this could open up a -whole- kettle of fish. Are FB-fonts limited in size? ... I actually don't recognise these functions - what kit are they in and where do I get it? G'day, eh? :) - Teunis
Re: file-target
On Sun, 6 Feb 2000, Andrew Apted wrote: Marcus Sundberg writes: Well, Andrew is wrong. The functionality does not belong there, and you gain nothing by putting it there. Imagine this: one process using display-file to output (via mmap) a constantly changing image to a file. Another process using display-file to read that image (again via mmap) and displaying it. There are no-doubt other ways of achieve the same thing, but could it get any simpler (and more intuitive) than that ? Now you're seeing what I was planning for that @#%@% movie player. The silly beast is becoming multitasking now... turns out multithreading works -beautifully- if you use wait states properly. Actually the beast is better at playing mp3's on my computer than mpg123 thanks to this :) But you need a fast enough CPU... Anyways, another part of such an exchange is some for of coordination between reader and writer on when the screen is safe for update... (isn't memory-target better for this? :) G'day, eh? :) - Teunis
OpenGL and GGI
Heya. Is it possible to do an accelerated 2D driver under OpenGL? Should be, I can't see why not. Any driver to look for ideas? It'd be cool to have an accelerated X that runs under OpenGL... ... As an answer to some of the X versus FB stuff G'day, eh? :) - Teunis
Re: GGI web browser
On Fri, 18 Feb 2000, Cesar Crusius wrote: This is just in case someone is really desperated for a GGI web browser: I just bumped into ZEN, a web browser that works in fbdev, but it does not use GGI. If someone has time to spare maybe a little hack on zen could result in a GGI browser. Right. WHERE IS IT :) I wanna hack a WWW browser... G'day, eh? :) - Teunis
Re: GGI web browser
On Fri, 18 Feb 2000, Cesar Crusius wrote: * teunis ([EMAIL PROTECTED]) [000218 13:55]: On Fri, 18 Feb 2000, Cesar Crusius wrote: This is just in case someone is really desperated for a GGI web browser: I just bumped into ZEN, a web browser that works in fbdev, but it does not use GGI. If someone has time to spare maybe a little hack on zen could result in a GGI browser. Right. WHERE IS IT :) I wanna hack a WWW browser... There you go: http://www.nocrew.org/software/zen I contacted the author, he will be happy to help anyone doing such a thing. Another idea, maybe better, would be to hack lynx... Starting to play... *giggle* Anyways, I like Lynx (and w3m for that matter) ... but graphics have more potential than text for many things. And I don't really like most of the -network- layer of lynx although it works.. (or the processing layer. w3m is superior for handling html although it has interface weaknesses :) More later... G'day, eh? :) - Teunis
that ggiplay I've been working on...
is on hold a wee bit. I've discovered a -lot- of problems in the threading. And haven't traced them yet. For some reason pthreads is losing condition signals. Anyone know anything about this? (If anyone's tried it and lost audio, that's why) So I'm moving to a multitasking model now, following The Unix Way :) Anyways, I've discovered that while Windows-style messaging is cute it doesn't really work on a secure system (anyone surprised?) On a whim I decided to attempt a Windows-style GUI under linux and it flopped. *giggle* (Thought I'd implement a Windows Media system under linux/GGI :) ...failed *sigh* Sooo Anyone know how to do memory locking/synchronization between processes? I'm still dithering... G'day, eh? :) - Teunis
Berlin folks! (I'm looking for a base GUI :)
I'm not signed onto any Berlin lists (and don't really know how to find them anyways - but some berlin folks follow this list) Okay so I need a few things in a GUI: Modularity!!! Embedibility!!! Oh - does Berlin run yet btw? (and can it handle a movie player? :) [and multimedia?] There may be 0+ displays (yes - as few as zero) also 0+ sound devices... 0+ input devices 0+ running programs 0+ other computers hooked up... All of these -should- be 'plug and play' *grin* - as in plug 'em in and they turn on.. and unplug 'em and the system doesn't crash. ... note that they'll probably be over a network (or network-like) connection at high speeds *grin* I'm hoping to dig up something that does 1G/s as a base :) [note that to update 1024x1024x32bpp at 60fps requires 240M/s... and current top fibre speeds are 1Tb/s. Though I don't know what latency's like these days] It's kinda fun. I was dithering about actually using some X but it's not up to handling the constantly changing devices... I -am- building this in hardware. If no software exists I'll build it myself. But I'd rather be nice (for a change) and help other folks out :) ... I -have- a working prototype of some of my ideas but some trouble with shared memory coherency.. gleah it's slow to write... G'day, eh? :) - Teunis
Re: file-target - just a quick comment on 64bit....
Just remembered this thread. This doesn't really apply to file-target really but it'd be good to remember for anyone reading/writing image libs. Of course a good solution for image libs is to support reading from stdin and writing to stdout :) [the calling proggy can deal with the probs.. :] On Fri, 4 Feb 2000, Christian Reiniger wrote: teunis wrote: Oh yeah, and you can support 64bit access too. For files 2GB in size :) If stdio the underlying FS don't support 64bit access, then it doesn't make much sense to use it anyway. After all, where do you want to store these 2GB? ;) Well, to take the linux/x86 example: ext2fs [afaik] does support 2GB files... stdio does -not- support 64bit access There's a suite of calls to talk to 2GB files with 64bit access. - 64bit file access is a special case on intel architecture; afaik Alpha/linux had it first as native for linux... - glibc 2.0+ has 64bit support... I haven't tested 'stdio' as I don't have 2GB set aside for running this... yet Actually I don't think the 64bit filesystem access is necessary for file-[target]; but for an image reader it would be appropriate... Just FWIW. G'day, eh? :) - Teunis
Re: screen hosings...
SAK (alt-sysrq-K) but it doesn't always work. YMMV and here's an explanation by comparison of my computer: under 3dfx/Banshee+DRI if you run X and fbdev simultaneously, switch out of X, load a graphical fbdev proggy then quit, the system halts. this is an improvement over just halting if ya switched out of X (afaik this happens though if you switch out while running a 3D app). On Tue, 22 Feb 2000, Firstname Lastname wrote: Sometimes when i'm running X and run fbset (using the fbdev matrox driver), my screen hoses... if i switch VC's my screen is still hosed. however, if i type, sometimes i will see letters flash on the screen for about a tenth of a second, then disapear. if i run quake all the colors are wrong. Is there a command to re-initialize/reset the fbdev driver?
Re: OpenGL and GGI
On Tue, 29 Feb 2000, Jon M. Taylor wrote: On Tue, 29 Feb 2000, teunis wrote: On Mon, 28 Feb 2000, James Simmons wrote: It'd be cool to have an accelerated X that runs under OpenGL... Thats GLX. Not exactly. I think he's asking for an "OpenGL target" for LibGGI, which would render everything in XGGI using GL primitives. Okay. I really like to see a OpenGL library that supports multihead and has the nice modular features of GGI. So you could have one OpenGL library where a app can run in X on one head and another app run on the console on another head. This would be cool. it's possible in the OpenGL specs... sorta... OpenGL isn't designed for multiheaded but it's designed for multiple display perspectives. Not the same... One thing I have always dreamed about is a GGIMesa extension of the "multi" target which would accept multiple eye coordinate sets and render each frame to a different sub-target using the different eye coordinates. That should do it, right? Yep, that's what OpenGL can handle exactly. There's also the case of multiple screens surrounding a person with different viewpoints or the CAD way of handling multiple simultaneous displays GLX only renders its GL contexts using GL, and does all of the rest of its (2D) accels its own way, correct? Right? 2D X server/ 3D OpenGL. Nope. OpenGL == 2D and 3D target is what I was looking for :) X isn't part of the equation here unless OpenGL is running under X. (not always true :) Cute possibility - Mesa/GGI as target for GGI (could it be done?) Sure. In fact, an OpenGL target could render to Mesa, or GGIMesa, or GLX, or Win32 GL, or I'm just remembering that GGI - svgalib emu - GGI isn't allowed... but XGGI - XGGI - ... - oh, fbdev works. Right, no prob. Will start looking when done current projects (ecommerce server + a whole lot of homework) G'day, eh? :) - Teunis
Re: Adding Triangle functions to GGI api
On Tue, 7 Mar 2000, James Simmons wrote: I have been looking at Mesa-GGI and libGGI. Do you think it would be possible to add a triangle function? Yes, but the triangle function is added in an extension library because the base LibGGI drawing functions are all basic 2D "essential" primitives only. Currently the "triangle drawing" extension library which most people use is of course GGIMesa, but LibGGI2D has triangle drawing functions as well, and of course there is always LibGGI3D. Time to put GGImesa in standard tree or make a GGI3D extension? *sigh* I don't know which one refers better to how hardware's handled. the nice thing about GGImesa is that just about all 3D-accels are heading for OpenGL as basic hardware accel :) I'm interested in also setting up Z and alpha buffers. How would I go about doing that ? Depends on whether you are trying to simply allocate some RAM and map it into a DirectBuffer, or whether you are trying to directly map a hardware Z/alpha buffer. If the first is true, just use malloc() and look at how e.g. the Glide target maps DirectBuffers, I think thats the best example code for that. If the second is true and you are mapping a hardware auxiliary buffer, you will either need to have a kernel driver which can let userspace mmap() the physical aperture, or do some suid-root /dev/mem mapping tricks like SVGAlib does. Neither. The SGI approach of not mmaping these buffers. I rather set a flag to tell the system to use a particular buffer. Sort of what you did in GGIMesa if I'm seeing it right. Ohhh - well, let's see. Z-buffer - the 3D drawing code uses this. It'd be nice to be readable from source-space for advanced drawing but not vital. And not available on all H/W (from experience :) Alpha buffer - same deal. Right. Stencil buffer - (2D clipping) - directbuffer (mmap) Textures - ... but prolly some global large buffer an application could allocate chunks of texture buffer. Or even better use ggi3D (or mesaGGI) to draw onto it. Letting the 3D lib handle whether HW or SW and which accel to use. (IIRC you'd use 3d triangle as basic primitive even when drawing lines or points with S3 ViRGE - but could be wrong) Feel free to disregard this whole message but please let me know if I'm barking up the wrong tree? G'day, eh? :) - Teunis
Re: gui stuff
On 11 Mar 2000, Marcus Sundberg wrote: Ian Molton [EMAIL PROTECTED] writes: Also, I think (if it doesnt already) libGGI2d should support all of its drawing types in antialiased variants as well. Antialiased drawing is farther away from normal 2D drawing than OpenGL is, and should definitely go into a separate library. hey - can ya -prove- this statement? :) Antialiasing is required by a lot of font software... ... now it'd be reasonable to just use the font software's own antialiasing (thinking freetype family here). I'm not actually sure that antialiasing is all that in use outside of fonts and some imaging apps. Comments? G'day, eh? :) - Teunis
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
On Sat, 11 Mar 2000, Jon M. Taylor wrote: On Fri, 10 Mar 2000, Andreas Beck wrote: int ggiStrechCrossBlit(ggi_visual *src, int sx, int sy, int sw, int sh, ggi_visual *dst, int dx, int dy, int dw, int dh); It should does the same as ggiCrossBlit, except it also performs streching. Hehe - that was in old LibGGIs. we took it out for its complexity. Well, it is an atomic drawing op on Savage4 hardware at least. But I agree that it is not necessary to have in LibGGI. Should be in either libGGI2d (imho this belongs there) or in a seperate lib devoted to BITBLT's [clip - there's lots on list] - ggi2D equivalents of all LibGGI drawing primitives that obey the extended markups above. Including text? dinna think that libGGI2D should include fonts/text. It's a complex topic and is better suited with external libs. Like freetype :) - triangles, All flat, no perspective stuff? Makes sense. Non-perspective triangles are acceled on many cards and could be used in some drawing ops. libGGI2D shouldn't have any 3D-specific stuff yet. Or maybe ever? (but sharing with libGGI3D or Mesa or ... is mandatory) polygons, Should this be different from triangles? We'll have to decompose the polygons into triangles or triangle fans in many cases anyway, in order to accelerate them efficiently with some hardware. DrawPolygon(vis, triangle, ...) is just a degenerate case of this. Agreed. I also don't look forward to examining the case of non-convex polys. Decomposing polys is a pain! arbitrarily positioned ellipses and arcs Yes. - rounded-edge rectangles ? Multisource ROP blit, superimposing a circle and a square. Also duable using a modified circle algorithm. IMHO that's actually more accurate. I've done it both ways and prefer this - spline/bezier shapes ? What hardware accelerates these? Does it matter? It's still duable :) - streched (Cross-)blitting. Stretching can be handled by allowing different source and destination geometries. ... Never thought of that :) Now go for it ! 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 the ground up? libXMI's still interesting... - but I prefer accels :) After all, just about all graphics cards these days can do accelerations. (yes I also have some ulterior motives... a 2D accelerated commandstream over a network as a target simplifies having to broadcast streaming video... long story, later :) G'day, eh? :) - Teunis
umm glide 2/3 (3dfx/banshee+)
Hey, looking at accelerating glide under 3dfx/banshee and 3+ Should I: a: get it to recognise and initialize from FB? b: get it to recognise and initialize from GGI Is there KGI for 3dfx? I haven't checked... I'm angling towards (a) at the moment as glide -requires- a 3dfx card of appropriate type and should only run under either X or console... I would -love- suggestions :) G'day, eh? :) - Teunis
Re: umm glide 2/3 (3dfx/banshee+)
On Sat, 8 Apr 2000, James Simmons wrote: On Sat, 8 Apr 2000, teunis wrote: Hey, looking at accelerating glide under 3dfx/banshee and 3+ Should I: a: get it to recognise and initialize from FB? b: get it to recognise and initialize from GGI Is there KGI for 3dfx? I haven't checked... Their was a KGIcon driver for it. It now has been ported to the 2.3.X kernels. Oh, that explains it then :) It does -not- share nice with tdfx/DRI... I'm angling towards (a) at the moment as glide -requires- a 3dfx card of appropriate type and should only run under either X or console... I would -love- suggestions :) Well you could run libGGI on top of fbdev with the 3Dfx driver. It maps the mmio region but I don't think libGGI takes advantage of this. The glide library doesn't use the fbdev layer. It does its own thing. That's the problem really... I want to initialize glide from fbdev then. Got it - thanks :) G'day, eh? :) - Teunis
Re: MPEG in GGI?
On Sun, 16 Apr 2000, Andreas Beck wrote:
I've downloaded libsmpeg, and after seeing the API, I have seen two
things that I dislike:
* it needs SDL
* it is in C++
Is somebody porting the code of this library to a pure C version
based only on GGI maybe into an extension or something?
I think there are many people here interested in having movie playing
supported by GGI. Maybe they could all speak up and form a team.
There are player libs out there for mpg2, mpg and qt at least. What should
be done is make a LibGGI-like wrapper for them that would give them a
unified API and make it easy to use them from any graphics lib, especially
LibGGI.
FINALLY there's interest :)
*giggle*
Okay, I'm going to rewrite that player I've been playing with anyways now
that I'm done classes.
MPEG2 - what should I use as a source? My current copy of xmovie does
-not- work for colours. Everything else though. I haven't looked into
it.
(aside: I currently have the code for this already implemented - it plays
mp3's beautifully :)
[actually, with the player structured the way I have, it's more
CPU-efficient with mp3's than mpg123 :]
I was planning on using SMPEG for the mpeg player. The only real prob I
have with this is I have mpegs that crash it :)
The problems with GGI:
I need events handling even when video is not enabled.
(either that or FB/target needs to default to current layout and
talk to the current "text" mode :)
[this is the only driver I'm aware of that has a problem]
- basically, if I try to watch the keyboard,mouse,...
without activating GGI, Bad Things Happen.
If I run GGI/fb with X running, my computer locks up.
I -like- my mp3 player but I don't like crashing.
And I don't always need video display. ideas?
Threading is mandatory. This hasn't been a problem in FB but X...
- solution: make the display a client
- problem: event handling has to be in the client too
- problem: sharing the rendered memory with the client
efficiently
Any ideas?
I -do- have working code on my page at www.geocities.com/winterlion.
But it's old and needs repair.
I got frustrated trying to stablise the memory system so I went back to
school a bit
Help, ideas, anything?
Does anyone else have a -better- way of writing this?
G'day, eh? :)
- Teunis
Re: MPEG in GGI?
On Mon, 17 Apr 2000, Stefan Seefeld wrote: Speaking about video and animation, may I come back to a suggestion I had a couple of weeks back ? I proposed to separate the 'Visual' structure into a 'Drawable' and a part concerned about event handling. The argument is quite in line with Andreas' request to refactor functionality in decompressing and drawing: Drawing and event handling have *nothing* to do with each other. My reason to ask this is that I'd like to see one day a 'drawable store' manager able to allocate any number of Drawables which I can draw into and then copy from one into another etc. However, there's always just one event listener. [clip as I don't want to get thwapped for excessive quoting :] The manager I'm talking about would then inspect the amount of accessible video memory and allocate either from that or, if it runs out of vram, from normal heap. [okay 'nuff clipping now] Completely agreed 100% The original reason I suspect for the event handling and drawing to be merged was X, where this is necessary. It certainly is -not- in FB/KGI/... however it makes a good default starting point for the drivers. I don't know what the rest o' y'all think about this though :) G'day, eh? :) - Teunis
Re: MPEG in GGI?
On 18 Apr 2000, Marcus Sundberg wrote: Stefan Seefeld [EMAIL PROTECTED] writes: Speaking about video and animation, may I come back to a suggestion I had a couple of weeks back ? I proposed to separate the 'Visual' structure into a 'Drawable' and a part concerned about event handling. The argument is quite in line with Andreas' request to refactor functionality in decompressing and drawing: Drawing and event handling have *nothing* to do with each other. Sure they do, how else would you know what happens to the visual? Expose events and such. Besides I'm not really sure what you mean by separating out the event handling from the visual structure. Of the whole ggi_visual_t there is one single pointer related to event handling, isn't that separated enough for you? I don't know what Stefan's reasons are, but mine are simple. If I want to use GGI's event mechanism (and I mean GGI not GII), I'd like to be able to select (no output, use stdout for now) and then switch to (have output) at some point. Basically, I'd like to be able to enable and disable output to fbdev. I don't have this problem with any other driver (if FB gets initialized when X is running my system halts. I need the event system initialized though before that point. What can I do?) So my problem's FB/specific whereas his is a little more general. Actually I'm kind of wondering what he means too? A manager for video memory will be implemented in LibGGI soon, Andy and I have just talked about that. This will make it simple to implement an extension for offscreen images. PLEASE! :) :) :) ps: glide has one in their source... it's necessary for handling texture,double buffer, and so forth... G'day, eh? :) - Teunis
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...
Re: MPEG in GGI?
On 19 Apr 2000, Marcus Sundberg wrote:
teunis [EMAIL PROTECTED] writes:
[clip]
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.
No - they're initialized in fb's target.
mouse, keyboard, and all.
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?
Be able to initialize GGI without setting a mode - leave it in default
state.
And to be able to go graphical if necessary.
Or better to be able to activate and deactivate GGI if necessary. Say, on
a playlist of mpegs some with video, some without. :)
Now currently I just go graphical regardless. (yah I know I should just
fold out the display/render part into another task and just select which
driver...)
But nonetheless it'd be very handy to be able to run the "linux console
GII init" without running GGI.
That automagically setup mouse, keyboard and all is -so- handy.
And I've been incompetent at writing GGI and GII drivers (though I -can-
fix them sometimes).
G'day, eh? :)
- Teunis
ggimesa
Heya! I've got glide/2d running under FB! :) [and yes ggi/glide target seems to work fine :] Anyways I'm just wondering if anyone here's working with ggimesa and could give a few pointers. (in private email :) Thanks :) - Teunis
Re: ggimesa
On Wed, 26 Apr 2000, Murphy Chen wrote: I've got glide/2d running under FB! :) [and yes ggi/glide target seems to work fine :] What is glide? 3D acceleration library for 3Dfx graphics cards. The glide version I'm running is specifically for the 3Dfx/Banshee and 3Dfx/3 I'm working on mesa/ggi, but after I make all in mesa. I cannot find any demo program built. mesa root/ggi/demos (requires ggi/ggiglut) make 'gears' should work. When I make demo programs manually, I got many error messages about using X related funtion without linking related library. However, I'm not intended to use X. The demos are made to require libglut. Which is designed to work with X. Now ggiglut is a replacement for some programs - but a poor one. Which version of ggi do you use? current CVS. I keep up a lot. Do you use kgi? No. KGI doesn't support 3Dfx/Banshee. And isn't even potentially 3d-accelerated for my hardware in any event so it's uninteresting to me at this time. (now if I could convince Mesa that my glide didn't require X support, I'd be happier) G'day, eh? :) - Teunis
Re: Memory Visual support?
memory visual is for reading/writing to/from a memory block and treating it like a video display. frame-buffer visuals is for the core framebuffer driver support in systems such as linux. It's sometimes accelerated if the driver has been written for such (afaik Matrox cards). This is a kernel-level graphic driver. I'm not sure if the memory visual can be targetted at specific memory locations but both are intended for different purposes. though if I remember correctly, a memory visual could probably be used on an Amiga as a display window under some circumstances? :) Other than all of that, I'm not aware of any constraints on either barring that whatever mode the framebuffer is set to has to be valid for the driver it's talking to. ie: mine's only 640x480, all other modes on my card are corrupt or nonoperational for the framebuffer driver. On Wed, 26 Apr 2000, Eric , Yu-En Lue wrote: Hihi I read the manual , it uses "display-visual" when opening the memory visual , however , in ggi_init , I see only string like "memory" , which one should I use? :) And is there any constriants or differences using the ggi-frame-buffer visual and the memory one? thanks!
