Re: More on DirectFB
yeah, rather than use DirectFB as a target why not port DirectFB to use ggi as the rendering engine. That seems to be more worthwhile. DirectGGI. Make sense? er isnt the point that DirectFB does accels on fb, which is why you want it as a target??? Justin
Re: evdev configuration
Justin Cormack wrote: All the info should be in /dev/input/event. The mouse devices are in addition and just provide emulated ps/2 or similar interfaces. As far as I remember you should get X and Y events too (evtest at the beginning should list all the types of event that can be generated). Which model do you have? right, the formatting of the event log suggests that it detects positional event types. But moving the stylus isn't logged. Hmm, may be I should debug GII a bit... Stefan Is it being lost by gii or never being received? What does evtest http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/ruby/utils/evtest.c?rev=1.10content-type=text/plaincvsroot=linuxconsole report? Justin
Re: Pomp for the page.
I was just here sitting trying to work on the pages when it dawned on me that what we need is a really impressive show of what ggi can do right there on the front of the web site. Some sort of plug-in would be cool. Is anyone working on a streaming media plug-in for netscape or any thing? Or is there anything we could put there? Or a ggi on Java 2D/3D target so you could run apps directly... Justin
Re: on Mesa, glide, and GGI :)
winterlion wrote: PS: anyone know of any embedded hardware that includes a 3D accel? :) No. I guess you will have to build something. Does it have to be low power or just small or what? low power *sigh*. I'm working with umm palmtop-style stuff. Need OpenGL :) and accelerated. None to concerned about chipset really but 3dfx has my favour due to openness (although I'm a little concerned about that giant fan :) Anyways, I could always go with one of those embedded pentium-III's or equivalent and do it all in software I guess. I don't really need over TV resolution although 640x480 would be nice :) [#$^#$ displays are expensive! :] Voodoo3 3000 doesnt have a fan. Eats quite a lot of power though. Utah-glx has some 3D support for one of the ATI laptop chipsets, though they are not very fast, might be good enough. Would need porting to fb of course... You could try underclocking the Voodoo (one of the low end PCI ones perhaps), at half the clock speed it might be low power and still have enough fill for 640x480. What are you building? Justin
Re: someone mentioned a GL-target for GGI?
winterlion [EMAIL PROTECTED] writes: Has this happened? It wouldn't be hard - not a big jump from glide-target anyways. It is impossible to write an OpenGL target, as you can't set modes or even open something to render on with the OpenGL API. You could write a GLX target, which would be completely pointless as you might just as well use X directly and loose the OpenGL overhead. So far everyone talking about an "OpenGL-target" seems to be confusing targets with something else. Not so. OpenGL gives you full access to a framebuffer once it has been created (though obviously accelerated operations may be much faster than direct pixel operations as you would expect). So once you have created an OpenGL context, there is no reasons why you shouldnt run GGI into it using OpenGL acceleration. Ok, you can't set modes without using glx or glide or fb or whatever you have GL running on, but some framebuffers cant set modes anyway, and you may be able to do it indirectly. Nor is OpenGL an overhead, even under X, as it may be accelerated better even for 2D operations. Clearly if you are running GGIMesa it could run very fast by passing all operations straight down to the GL layer (though there would be some issues of versions of GL etc). More importantly when we get Mesa-glide running on Glide on the framebuffer, there is the question of how to run GGI on this. GGI could either run over Mesa, over glide or on the framebuffer. Or rather than use Mesa-glide we could use a GGI on glide with a GGIMesa version accelerated for Glide (basically a GGIMesa Mesa-Glide hybrid). Or with GGI being generic, all of the above... Justin
Re: on Mesa, glide, and GGI :)
All right, bringing this up again :) I've got a working glide2x for 3dfx/banshee and 3dfx/3+ (afaik) under FB/dev. (patches available on official mailing list archive for glide-devel) I do -not- have a working OpenGL.. (any ideas?) Or, last I checked, a working GGI... but that's another story. (I really should just recheckout the CVS :) Anyways, I'd like to get GGI+OpenGL+Glide+FB running. Suggestions? (I -really- need console accel :) ... I've been working under X lately and am none too fond of it... I'll have a go next week, as I want this too. Or sooner. G'day, eh? :) - Teunis (or winterlion or whatever) PS: anyone know of any embedded hardware that includes a 3D accel? :) No. I guess you will have to build something. Does it have to be low power or just small or what? Justin
Re: XGGI as a nested X server
How is a nested X server established technically? Is the window for the the nested X server a normal X client as viewed by the hosting root X server? And what's the trick to enabling window managers within this=20 virtual X root server? Yes, the window is a normal X client. To run a window manager, go to a terminal, set DISPLAY to :1 (if that is where you started XGGI) and start the window manager. Justin
embedded qt
http://www.trolltech.com/announce/embeddedqt.html Trolltech are producing a version of Qt that doesnt require X, running directly on the Linux framebuffer. Anyone know anything about it? It claims to offer acceleration. Justin
Re: fb-dev, fbdev as display target for GGI, HOWTO ???
Did that /dev/fb0 is "up". Other than that LibGGI should autodetect fbdev and use it. Make sure of course, that the user has rw- permissions on the fb device in question. Hmm. When I changed GGI_DISPLAY to 'fbdev', under X, the screen goes black and looks very rudely console-like. I guess this driver does not understand graphics-mode, so that it also cooperates with a mouse pointer. Is it there, where the KGI comes into play?? Please, please more clarification!! er, no. Dont run the framebuffer under X. Run it on the console. Justin
Re: OFFTOPIC: which 3D card to buy
On Tue, Feb 29, 2000 at 09:26:27AM +0100, Erik Thiele wrote: which 3D card should i buy [.. everything boils down to GL or rather mesa ..] Well, you can't go wrong with 3dfx. It's got the most stable highest performance drivers out there. True if you want to run fullscreen, and you can live with the other limitations ie 16 bit colour and Z buffer, and 256x256 textures maximum. The Voodoo 4 and 5 overcome these limitations however, and I am just waiting for them to come out... Also there is no actual AGP support per se. They are however the only cards you can get full acceleration without running as root. The g400 is just not that fast yet if you want a stable driver (pre-warp GLX).. The current warp drivers are stable in my experience. There seem to be some severe fill rate limitations (at least on the non Max versions of these cards) which make them unusuable at high resolutions. AGP support works on some chipsets (BX, not Athlons). The g400 has an advantage however in that I have yet to convinced this thing (Voodoo3) to run in a window. When I tell it to run in a window it ends up full-screen anyway and it tries to use this LAME framebuffer copy hack which makes it not even worth it. I just haven't managed to get good 3D in a window with the voodoo3 with Mesa, at least not with X 3.3.6 and Mesa 3.1. If someone can tell me how PLEASE DO! = Why would you want it? Just wait till something crashes. gdb and full-screen voodoo3 don't mix. Trust me. = I think the framebuffer copy is all the hardware supports. Try adding another graphics card or debugging remotely. Mind you it often locks the machine totally when it does crash... nVidia is supposed to have kickass drivers. Eventually. The only stable drivers you can get now are for 3.3.5 and older X servers and they're so slow you'll wonder if you're actually getting accelleration at all. nVidia has not earned a reputation for cooperation with the community either. The new NVidia drivers are complete crap and lock within seconds. The old ones were usuable, I dodnt find them that slow on TNT 2 Ultras. Nvidia are paying for closed source drivers which are apparently very good; they will be out with XFree86 4. The closed source nature causes problems for some of us who need to change the code. In summary the situation is a mess now. What we want is GGI3D support, and Voodoo is likely to be the first target... Justin
Re: OpenGL and GGI
On Mon, 28 Feb 2000, James A Simmons wrote: On Sun, 27 Feb 2000, teunis wrote: Heya. Is it possible to do an accelerated 2D driver under OpenGL? Should be, I can't see why not. Yes you can. The 3D stuff would have to be software rendered ontop of the 2D code. There's enough 2D-style accels support in OpenGL that texture blitting, color ramps, clip planes/alpha/stencil masks etc could be used to good effect when accelerating X. 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. GLX only renders its GL contexts using GL, and does all of the rest of its (2D) accels its own way, correct? Thats what I thought too. I think that the acceleration might prove quite hard, and many cards do not actually have hardware accelerated stencils anyway for 3D. If implemented well you could run cube3D with accelerated sessions (or with more work run X sessions on the surface of a transparent torus). Unaccelerated of course is simple, just render into a texture using shared memory and use glTexSubImage to update a texture (say filling the screen) and then sort out the input. Justin
Re: evstack, Results of multi-headed quake test, and input fun
There is a GGI Glide target, but it's 2D. What's wanted is accellerated hardware 3D.. Something that CAN render 3 screens of Quake at a decent FPS. = I agree. So where do we start? First voodoo cards like many cards are triangle bases. Any triangle support? The next thing is how to program the libggi target to use things like textures, alpha blending and depth buffering. What is the future of Glide in the 3dfx plan of things? Given that there are (some) Glide programs that could run directly on a GGI Glide 3D target, and there is a Mesa-glide target, this would perhaps be the easiest way to go. It keeps the 3Dfx development rather apart from other Linux 3D development, and while it provides a demonstration of principle for GGI 3D it doesnt help support other cards, and now with full scpecs glide is not necessary. Justin
Re: evstack, Results of multi-headed quake test, and input fun
Sure, and you could simply draw two or three screens that way instead of drawing six. In fact, if you ever get GL hardware support in GGI, it might be possible to have 3 screens rendered in HARDWARE.. That would just seriously kick ass! Howdy!!! I back from my trip from San Jose. What you described below was one of this I discussed with 3Dfx about doing. It is quite possible to get GL support in GGI going. One of the topics I discussed with 3Dfx was GGI. I discovered they have someone that works for the company that does provide support for people that write their own things. The person to contact is [EMAIL PROTECTED] He is the current maintainer of the glide libraries at sourceforge.net. So this makes the next step. To create a GGI 3Dfx target. Their does exist a fbdev drivers for this card. The problem is I don't have such a card nor the money at this time to buy it (hint). I would enjoy creating something like Msrcus did for the matrox cards. Of course I like to milk it for more than drawing boxes. I'll send you a card (Voodoo 3 3000) - just send your address. Justin
file target problem
The file target in ggi-devel-000103 invariably segfaults if you ask the file target to write a ppm file rather than a raw file (can send more debugging info if you need it). Works fine in 2.0b2.1. The file target code is the same, so must be somewhere else. LibGGI: Disposing "generic-stubs" LibGGI: Closing handle: 0x80a3688 LibGGI: _ggiZapDL(0x808db50, 0x808edcc) called LibGGI: Disposing "generic-color" LibGGI: Closing handle: 0x80a3a38 LibGGI: _ggiZapDL(0x808db50, 0x808ee34) called LibGGI: Disposing "file" LibGGI: display-file: going down. LibGGI: display-file: GGIresetmode(0x808db50) (segv) Justin
ggi-glide-mesa
Now that the Glide 3 sources are out, we would like a ggi-glide-mesa 3D accelerated driver for Voodoo graphics cards, but unfortunately I dont have time to write one. However I will send anyone who will write one a Voodoo3 3000 card... might be able to arrange a G400 too. (desperate to get rid of X windows...) Justin
Re: Multiple users
Hi ! I've recently gotten a USB mouse and keyboard, and started looking at the Linux USB code. Yesterday I added support in LibGII for USB mice under Linux (use protocol "lnxusb"), and am now using my MouseMan Wheel with mhub. Great ! Works great with all four buttons and the wheel. As of kernel 2.3.25 the USB mouse driver only supports one USB mouse, ARGL ... will they make the same mistakes again over and over ? but if none of the USB people does it before me I intend to fix that. Good. TNX. As for keyboards it seems you can attach multiple USB keyboards, but everything will go into the normal (single-headed) console system via calls to handle_scancode(), so multiple keyboards are pretty useless. Ouch ... It has been discussed on the USB list actually, but the priority seems to be getting things working. It came up a few weeks back in terms of device naming, when several people revealed that they wished to put large numbers of keyboards plus mice, or large numbers of modems onto one box. Justin
Re: ggimesa+multi problem
I found the problem - ggiglut never calls ggiClose(), so there is no clean termination (leaves fb in odd state too). Fixed this by adding a close function to glut - there ought to be one anyway, I would count this as a glut bug. Is this with Mesa from CVS ? If it is I will fix it. I never had this problem but I will look into it. 3.1beta3 Justin
Re: ggimesa+multi problem
On Tue, Oct 12, 1999 at 10:30:30AM +0100, Justin Cormack wrote: I don't seem to be able to run ggiMesa on the multi target. Probably because the multi target doesn't provide a directbuffer. Ah yes. ok, I need to save some Mesa images to a file. As multi doesnt work, I tried to use the tile target with one of the tiles being a file target. However it doesnt save the picture if I use a .ppm file (the raw format seems to work however - can I convert this to ppm manually?) Justin
