From ggi-develop-request@eskimo.com Mon Jun 1 02:12:07 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA20364; Mon, 1 Jun 1998 02:12:05 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA14305; Mon, 1 Jun 1998 02:16:05 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 02:16:05 -0700 (PDT) Message-ID: From: Paul Sargent To: "'ggi-develop@eskimo.com'" Subject: RE: Current Mode negotiation Date: Mon, 1 Jun 1998 10:00:44 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"M6llm3.0.IV3.E5dSr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2413 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I would agree with both points here. The app is going to be the best 'person' to know whether it's going to need full out performance or a nice display, but being *nix users there's a bit of 'user knows best' in all of us. So I'd propose that in general the Mode request become something like: * 1024 x 768 @ * Hz (Wildcard for Frequency means give me anything you've got) * 1024 x 768 @ 75 Hz (Give me the closest thing to 75 you have) I'd then also have a system like the one guillaum@clipper.ens.fr proposed below to allow the user to override the range of frequencies available to the applications. These two should be able to co-exist quite nicely, but with the user override always taking precedence. The application call is only a request for a mode. How easy would that be to implement? Paul >-----Original Message----- >From: Marcus Sundberg [SMTP:e94_msu@elixir.e.kth.se] >Sent: Monday, June 01, 1998 12:45 AM >To: ggi-develop@eskimo.com >Subject: Re: Current Mode negotiation > >> > So I propose that we come up with a system that will stop this from >> > happening. I would say that refresh rates in excess of 100Hz are not >> > necessary, so a simple way would be to introduce a hard limit at some >> > point. >> >> I completely agree. Something in that direction is needed. >> >> > But what about the user that decides 'I value performance over my >> > eyes, therefore I want all modes at 60Hz'? >> >> You'd need to tell KGI: >> >> echo "0" > /proc/kgi/freq-limit >> to select highest possible frequency (current behaviour) >> echo "1" > /proc/kgi/freq-limit >> to select lowest feasible frequency >> echo "95" > /proc/kgi/freq-limit >> to tell KGI that it's not necessary to go higher than 95 Hz >> >> (this should be per-display in fact) > >I made a quick hack a long time ago (used the 971213 snapshot iirc) >that made it possible to change the monitor parameters on the fly >with a sysctl interface. > >However this is not really the right solution to this particlular >problem. The Right Thing To Do is to let the application choose >the refressh rate. XGGI would for example take the values from >/etc/XF86Config, while most apps would pass GGI_AUTO. > >//Marcus >-- >-------------------------------+------------------------------------ > Marcus Sundberg | http://www.stacken.kth.se/~mackan > Royal Institute of Technology | Phone: +46 707 295404 > Stockholm, Sweden | E-Mail: e94_msu@e.kth.se > > From ggi-develop-request@eskimo.com Mon Jun 1 05:02:05 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA20464; Mon, 1 Jun 1998 05:02:02 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA27244; Mon, 1 Jun 1998 05:00:26 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 05:00:26 -0700 (PDT) Date: Mon, 1 Jun 1998 07:58:38 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: RE: Current Mode negotiation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"JSl5e1.0.Zf6.OVfSr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2414 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 1 Jun 1998, Paul Sargent wrote: > So I'd propose that in general the Mode request become something like: > > * 1024 x 768 @ * Hz (Wildcard for Frequency means give me anything > you've got) > * 1024 x 768 @ 75 Hz (Give me the closest thing to 75 you have) > > I'd then also have a system like the one guillaum@clipper.ens.fr > proposed below to allow the user to override the range of frequencies > available to the applications. This would be a rather peicemeil solution to the general problem of allowing the app to position/time the display itself. It would require adding a frequency field to the mode request; Andy has expressed that we are not to change libGGI's API for a while yet. So while it would be easy I'd say holding out for a more thorough system is better. In the lull that has been going on, I have actually started transcoding the system I was working on into C, which is a step forward at least, but it will be taking a back seat to drivers as soon as Jason releases the KGI/EvStack/fbcon driver specifications. I would tender the question as to whether video memory bandwidth is actually constricted severely by refresh rate -- granted full frame loading for animation is bottlenecked on ISA systems for higher resolution and frequencies, but I'd venture most PCI cards can do a frame load during retrace at rather high frequencies, and they probably don't offer very high dotclocks without also having VRAM. So though desirable this feature isn't in my mind a priority. Please correct me if actual performance numbers to the contrary are available. As noted in Hartmut's summary of open issues, the consensus seems to be that the driver mode setting code should validate and set mode timings only, and that the actual calculations for anything beyond basic console textmodes should occur in userspace. Any userspace library to do this could obey systemwide default settings and allow overiding in the environment. Stephen mentioned working on this concept and I am as well. -- Brian S. Julin From ggi-develop-request@eskimo.com Mon Jun 1 07:32:27 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA20538; Mon, 1 Jun 1998 07:32:26 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA26195; Mon, 1 Jun 1998 07:27:14 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 07:27:14 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: ggi Q? (fwd) Date: 1 Jun 1998 14:29:01 GMT Organization: OnTV Pittsburgh, L.P. Lines: 30 Sender: Jason McMullan Distribution: local Message-ID: <6kudrd$1hh$1@butter.visus.com> References: <6ku2ma$11g$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"YCpjy2.0.BP6.0fhSr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2415 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Peter Amstutz wrote with confidence: > Sorry for bothering you, but I just installed ggi (at least the kernel > part). It boots OK, but how do I tell the kernel I have my vga in a mode > larger than 80*25? (80*43 or so, actually). > The install doc says I have to tell the kernel, but I cannot find info > on HOW to do this. Could you please point me to a location that does > have this info? > Thank you! Hmmm... The current KGI drivers don't seem to like being out of 80x25 (this is being worked on). For now, add a: append="vga=-1" to boot into 80x25 mode for your GI kernel, or if it's on disk, do a: /usr/sbin/rdev -v /dev/fd0 -1 -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Mon Jun 1 08:34:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA20582; Mon, 1 Jun 1998 08:34:41 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA08663; Mon, 1 Jun 1998 08:27:30 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 08:27:30 -0700 (PDT) Date: Mon, 1 Jun 1998 11:25:12 -0400 (EDT) From: Matt Agler cc: ggi-develop@eskimo.com Subject: Re: ggi Q? (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"5P48J.0.z62.QXiSr"@mx2> To: ggi-develop@eskimo.com Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2417 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Yes, there needs to be a GGI Usage Guide (listed right after the GGI Installation Guide on the Docs page). It should list all the features of GGI/KGI/whatever and HOW to use each one. I'm not in a position to write this but I sure would like to READ it! -Matt On Sun, 31 May 1998, Peter Amstutz wrote: > I just got this, since I don't run a ggi kernel at the moment I don't know > the answer. Perhaps someone can help this fellow? > > ---------- Forwarded message ---------- > Date: Sat, 30 May 1998 22:06:28 +0200 > From: udo@dinges.xs4all.nl > To: amstpi@freenet.tlh.fl.us > Subject: ggi Q? > > Hoi! > > Sorry for bothering you, but I just installed ggi (at least the kernel > part). It boots OK, but how do I tell the kernel I have my vga in a mode > larger than 80*25? (80*43 or so, actually). > The install doc says I have to tell the kernel, but I cannot find info > on HOW to do this. Could you please point me to a location that does > have this info? > Thank you! > > Udo > From ggi-develop-request@eskimo.com Mon Jun 1 08:34:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA20586; Mon, 1 Jun 1998 08:34:46 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA08098; Mon, 1 Jun 1998 08:25:21 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 08:25:21 -0700 (PDT) Date: Mon, 1 Jun 1998 16:05:42 +0200 (CEST) From: Emmanuel Marty X-Sender: core@gate.local Reply-To: Emmanuel Marty To: ggi-develop@eskimo.com cc: jmcc@ontv.com Subject: Re: offtopic/rant/rant/linux expo Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"aTc_r1.0.H-1.RViSr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2416 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Re :) > Yep - I knew about the X86 port (which is why I now have enough > `borrowable' code to do the VESA 2.0 KGI driver - I also plan to > modify the video.S ASM sources to come up with a `vesa=ask' menu > of graphics modes to switch to (and auto-detect where the linear > framebuffer is!) Ahh, ok. If you have questions about the port, feel free to ask, since I did it as a gesture of good will from the GGI team to the kernel team *smile* As for knowing where the linear framebuffer is, that's not a problem, VBE 1.2 and up (so that includes 2.0) provide a physical pointer to the lfb, when present on a board. I remember using it a LONG time ago, when I was writing an S3 driver (the chip 80% of the gamers PCs used at the time :) under DOS/4G for some famous game.. Had the framebuffer mapped and all :) > How hard is it to modify to handle multi-head? That's what most > people that were interested in EvStack were looking for... Well, the abstract console works exactly like the regular one (except for the removed vga code) i.e it renders fg_console. I still think it would be easier to modify the abstract console to do multihead and work with EvStack scrollers, than rewriting a console driver from scratch.. Note that fbcon/abstract consoles don't prevent you from doing graphics multihead, just console multihead. Which is quite annoying and one of the big EvStack advantages still, I agree.. > I'll check his patches w/respect to mine - I have it working > up to 2.1.103 Oh - don't bother then. It was to get it to run on 2.1.101 or so (based on my changes to get it to run on 2.1.92 - did the changes I did to /dev/graphics to come with kernel changes, work fine for you, by the way ?). If you got it to run on 2.1.103, that's all we need. > > I hope it helps you to start over again ? First thing to do is to make > > sure it runs on 2.1.103 with, say, the VGA driver, I guess. Then we know > > we have some platform to start moving the drivers. > > Already got that on my personal machine's tree... Hmm, I never got the VGA driver to run on my GGI guinea pig machine at home after you had done the necessary rewrite of most of the code :) Can you prepare a working tree (for 2.1.103 and all) ? The CVS server will be back up early this week, as soon as Andreas came back home from the expo and I have news from him. > And the SEMANTICS of the mode setting functions - there are > now VERY strict rules you have to follow w/respect to memory allocation > so that I can cleanly remove drivers & do multi-head. The changes I > make to the driver subsystem weren't just aestetic - they're meant > for cleaner driver code, too. Oh - sorry if it sounded like that. I didn't mean that - just that there should really be a mininum changes to the drivers, as they are already buggy enough :) But of course, changes that allow for smaller/cleaner code, are welcome. > Not a problem - and your vm86() code would also be useful for > VESA 1.0 support with banked VGA cards. Yup, I was thinking about that too. Quite slower, but at least it will get XGGI to work on any x86 board in the universe. We already have the banked memory manager, we just need the bios calls. > Sounds good - this is the dot-based call, correct? (so that we > can support the Amiga COPPER chip's `do THIS on this pixel of > this line' Yes, exactly. The hardware will then "do its best" to match the requirements, I suppose. > > Here's and idea - how about instead of `blocking till vsync' > you send a command to perform on vsync, ie: > > struct ggi_triggered { > int trigger; > int action; > ggi_coord dot; > union { > int i; > void *p; > } data; > }; > > enum GGITriggers {GGI_TRIG_VSYNC,GGI_TRIG_ACCEL_DONE,....}; > > enum GGIActions {GGI_MODE_SET,GGI_ORIGIN_SET,GGI_SPLITLINE_SET,....}; > > That way we can support most common vsync actions on most > architectures, with very low latency (interrupt backhandler? > and will be extensible. Good idea! I like it, because it doesn't try to second-guess the programmer, and you can add as many interrupt sources and actions performed then, and combine them as much as you like. Sort of a small programming language, like the code the copper understands :) Oh - I can't believe I forgot to ask : how did the Expo go ? :-) I haven't heard of Andy yet, and I'm very impatient to know :) How did Andy and your talk go ? Tell us all :) -- Emmanuel From ggi-develop-request@eskimo.com Mon Jun 1 08:48:58 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA20653; Mon, 1 Jun 1998 08:48:53 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA12176; Mon, 1 Jun 1998 08:44:52 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 08:44:52 -0700 (PDT) Date: Mon, 1 Jun 1998 16:25:19 +0200 (CEST) From: Emmanuel Marty X-Sender: core@gate.local To: ggi-develop@eskimo.com Subject: PROPOSAL: IRC session friday night Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"jGxgR3.0.4-2.kniSr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2418 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello all, This week, probably by wednesday-thursday, the CVS server will be up again and work can be shared again. Short-term and longer-term goals have been discussed on this list, but I propose we all attend an IRC session friday night, in order to set things straight once for all, so that we all know what to work on - and hopefully this will set all of us closer again. I propose we attend the session on the night of friday june 5th to saturday june 6th, at 12:00 AM MET (when we turn to saturday that is). This time should allow most people to be here : USA Europe Australia PST MST CST EST GMT+1 MET GMT+10 Fri Fri Fri Fri Fri Sat Sat 3:00P 4:00P 5:00P 6:00P 11:00P 12:00A 8:00A I hope I got all timezones right this time :) I apologize for the late time for Europeans, and the early time for Australians, but reversed daylight savings between those two continents make it so that we are only 8 hours apart in summer :) Session will take place on irc.ggi-project.org . If you still are not familiar with irc please try to connect now and do your experiments so that you are ready for the session. If you are unsure what timezone you are in, connect to the irc server and do /time - the irc session will start when it shows 0:00 on saturday june 6th, so adjust accordingly. We have a lot to talk about, so you can probably expect the session to last at least for three or four hours - have your coffee or coke bottles handy. Is that fine for everyone? I think this is much needed. For friday, I propose discussing : * What happened for the past two months with CVS closed and Degas. * How to move to Degas (apparently EvStack interface) drivers, from a proposition by Jason McMullan which will be available online before the session so that people can read it and come with ideas. * The raster-sync problem and solutions, if Brian is okay to tour us around. * libggi changes for 1.5 - keeping the same API and fixing the issues pointed by Hartmut That's the four main things I see for friday, please add yours. I also propose that we hold a session at the same time the next friday-to-saturday night, and that we invite the Berlin people for that second one - so that we can discuss issues such as libggi2d and integration into Berlin aswell, and reassure their team about what is going on with us. I think we should attend these sessions on a regular basis, as part of the "checkpointing" work we will have to do if we want some project organization. What do you think? -- Emmanuel From ggi-develop-request@eskimo.com Mon Jun 1 09:53:28 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA20740; Mon, 1 Jun 1998 09:53:24 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA10373; Mon, 1 Jun 1998 09:52:06 -0700 Resent-Date: Mon, 1 Jun 1998 09:52:06 -0700 X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Mon, 1 Jun 1998 18:51:09 +0200 (MET DST) From: Stefan Mars To: ggi-develop@eskimo.com Subject: Re: PROPOSAL: IRC session friday night In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"w9DZF2.0.mX2.omjSr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2420 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I hope I got all timezones right this time :) I apologize for the Maybe I should write you a program that automagically converts the time into different timezones for you :). Nah, not worth the time. A new irc session is a good idea, and a badly needed one. Sadly, you have chosen a rather bad time for me (exam on saturday), but I will try to see if I can be there for a while at least. I also assume that it will be logged and posted as usual? > * What happened for the past two months with CVS closed and Degas. > > * How to move to Degas (apparently EvStack interface) drivers, from a > proposition by Jason McMullan which will be available online before the > session so that people can read it and come with ideas. > > * The raster-sync problem and solutions, if Brian is okay to tour us > around. > > * libggi changes for 1.5 - keeping the same API and fixing the > issues pointed by Hartmut > I think we should attend these sessions on a regular basis, as part > of the "checkpointing" work we will have to do if we want some > project organization. What do you think? Sounds good. -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Mon Jun 1 11:16:45 1998 Return-Path: Received: from mx1.eskimo.com (36987@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA20777; Mon, 1 Jun 1998 11:16:41 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA00751; Mon, 1 Jun 1998 11:15:15 -0700 Resent-Date: Mon, 1 Jun 1998 11:15:15 -0700 Date: Mon, 1 Jun 1998 19:03:39 +0200 (CEST) From: Emmanuel Marty X-Sender: core@gate.local To: ggi-develop@eskimo.com Subject: irc session, take 2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"kSfGv2.0.NB.i-kSr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2421 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello, > A new irc session is a good idea, and a badly needed one. Sadly, you have > chosen a rather bad time for me (exam on saturday), but I will try to see > if I can be there for a while at least. I also assume that it will be > logged and posted as usual? Allright, that time seems to be a bad idea :) The session will be logged and posted to the website as usual. However, I would really like most people to be here.. What about sunday june 7th at 5:00 PM MET (11:00 AM EST) ? Here we go again.. PST MST CST EST GMT+1 MET GMT+10 Sun Sun Sun Sun Sun Sun Mon 08:00A 09:00A 10:00A 11:00A 04:00P 05:00P 01:00A Now that would be Andrew J. Apted who has to be up at 1 AM on the night of sunday to monday, but hopefully he's in holidays and can do that :) Is that fine for everyone ? -- Emmanuel From ggi-develop-request@eskimo.com Mon Jun 1 11:42:09 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA20796; Mon, 1 Jun 1998 11:42:04 -0700 Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by mx1.eskimo.com (8.8.8/8.8.8) with ESMTP id LAA03170; Mon, 1 Jun 1998 11:50:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA18076; Mon, 1 Jun 1998 11:37:33 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 11:37:33 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Tilman Vogel Newsgroups: local.ggi.develop Subject: Re: GGI Real-time API (re: unresolved issues and visual science) Date: Mon, 01 Jun 1998 20:32:37 +0200 Organization: Tilmans Linux-Box Lines: 24 Message-ID: <3572F3C5.2EE1EA83@altavista.net> References: NNTP-Posting-Host: bird.local.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 1 Jun 1998 18:32:37 GMT X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) To: Brian Julin Resent-Message-ID: <"ScUdN2.0.DQ4.dJlSr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2422 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello, Brian! Thank you very much for your extensive elaboration! I think it would be no problem to limit our project to one specific hardware scenario. At the moment the hardware environment consists mainly of SGIs an Macintosh computers. So we will have to buy new PCs anyway and we still can decide about the components to use. I would be glad if you can make suggestions for us which hardware to use. How big are the benefits from the AGP architecture? Since I haven't been programming with GGI: Could you please send me a sample code snippet which tells GGI to flip pages and waits for it. Looking at the source code I could not figure out which ggi-Function actually issues a page-flip. Maybe I am just blind... ggiFlush() is something different, right? What is the OpenGL glXSwapBuffers() equivalent? Another question: What are KGI-SUID targets? I thought KGI's goal was improving security by making it unnecessary to use suid. Or is this just a solution for the time being? Tilman From ggi-develop-request@eskimo.com Mon Jun 1 12:33:36 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA20840; Mon, 1 Jun 1998 12:33:28 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA26281; Mon, 1 Jun 1998 12:23:44 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 12:23:44 -0700 (PDT) X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Mon, 1 Jun 1998 21:20:55 +0200 (MET DST) From: Stefan Mars To: Tilman Vogel cc: ggi-develop@eskimo.com, Brian Julin Subject: Re: GGI Real-time API (re: unresolved issues and visual science) In-Reply-To: <3572F3C5.2EE1EA83@altavista.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Z5MI-.0.TQ6._-lSr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2424 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 1 Jun 1998, Tilman Vogel wrote: > I would be glad if you can make suggestions for us which hardware to > use. How big are the benefits from the AGP architecture? You should probably get very common hardware, because that is what drivers are likely to be written for first. Examples would be the Matrox Millenium II for example, which has had a history of quite rapid development in GGI. Some of our coders also have the specs for the matrox cards, which makes it easy to write/maintain a driver. I haven't tested AGP with GGI, nor have I heard of anyone else doing it, so it's hard to say. > Since I haven't been programming with GGI: Could you please send me a > sample code snippet which tells GGI to flip pages and waits for it. > Looking at the source code I could not figure out which ggi-Function > actually issues a page-flip. Maybe I am just blind... ggiFlush() is > something different, right? What is the OpenGL glXSwapBuffers() > equivalent? I will leave this to Brian, hopefully he has code available. Also I am unsure about our status here. > Another question: What are KGI-SUID targets? I thought KGI's goal was > improving security by making it unnecessary to use suid. Or is this just > a solution for the time being? It is a part of KGI's goal to remove the need for suid. However, not everyone wants to compile a KGI kernel just to test KGI, and so a kernel-kgi-module was written. It does the same as a normal KGI kernel, with the exception of needing suid. -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Mon Jun 1 13:06:54 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA20877; Mon, 1 Jun 1998 13:06:49 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA05345; Mon, 1 Jun 1998 13:04:55 -0700 Resent-Date: Mon, 1 Jun 1998 13:04:55 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Did you know... To: ggi-develop@eskimo.com Date: Mon, 1 Jun 1998 14:56:35 +0200 (MET DST) In-Reply-To: <356B071C.F8057FF@gmx.de> from "Thomas Tanner" at May 26, 98 08:17:00 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"uxALE.0.EJ1.cbmSr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2425 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Digital considers using GGI for Itsy, a handheld computer running Linux: > http://www.research.digital.com/wrl/itsy/talk/sld018.htm > > Who is going to help them with the port? 8) I. I have met the developer, seen the thing running. Funny piece of HW ! CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 1 13:12:06 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA20890; Mon, 1 Jun 1998 13:12:02 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA05627; Mon, 1 Jun 1998 13:07:53 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 13:07:53 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Current Mode negotiation To: ggi-develop@eskimo.com Date: Mon, 1 Jun 1998 19:02:59 +0200 (MET DST) In-Reply-To: from "Karsten Petersen" at May 31, 98 05:48:55 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Ckwys3.0.mN1.KemSr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2427 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > because of this i alwas told ggi my monitor can only make 85 hz. > i had the problem that the ggi tried to run my et6000 at 160hz refresh, > which produces a lot of display-errors. This is a bug, then. There is some other limit wrong. No setting may produce display errors. The ET6000 driver should be checked. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 1 13:21:24 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA20901; Mon, 1 Jun 1998 13:20:21 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA05492; Mon, 1 Jun 1998 13:05:24 -0700 Resent-Date: Mon, 1 Jun 1998 13:05:24 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Libggi Issues round two is open! To: ggi-develop@eskimo.com Date: Mon, 1 Jun 1998 15:34:28 +0200 (MET DST) Cc: tanner@gmx.de In-Reply-To: <356AF1EA.F34187C1@gmx.de> from "Thomas Tanner" at May 26, 98 06:46:34 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"y5sly3.0.ML1.0cmSr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2426 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi everybody ! [I'll try to translate the original message, so we can all understand it. T> Hello Hartmut! > > > Hi everybody! > > I put the current draft of the libggi open issues onto my web site, > > it should be at > > http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/ > > libggi/libggi-issues.html > > (without the line break, of course). > > Please read it. > > ... > > OK, folks, this is only the warm-up round. > > We should have not more than three days of discussion about it, and > > then decide. And then I'll bring up the next points on the list. > > LET'S GET THIS JOB DONE! > T> It is nice, that you want to fight our lacking progress and waking people T> up again > T> But we have a big Problem with that. T> People (users) expect a stable API ASAP, that will not change anymore, and T> the they can use. YES. And I promised then at the expo to have this ready in the next 3 months. T> However specifying a sophisticated and full grown API is nothing you do from T> one day to the other. T> This needs to take its time and has to grow/adapt/mature with the applications. T> Especially when dealing with something that fundamental like our LibGGI, T> we have to be very careful, as an initially bad design will defeat implementation. T> A quote from Steffen: T/S> "The current way looks like "we throw everything in a pot, and everyone takes T/S> what he needs. We cannot hold onto that for long". T> We want to present a stable API to the people ASAP. T> They will really not like more changes in our API, which are to be scheduled now. EXACTLY. THIS IS WHY WE WILL NOT CHANGE IT. IF YOU WANT, WRITE YOUR OWN. I DO NOT CARE. sorry for shouting. T> Our current LibGGI has several severe drawbacks. Just to mention some: T> - extremely unflexible Extension-scheme a la QuickHack (TM) T> - selecting a specific framebuffer- and pixel-oriented drawing-API T> -> this will only support specific Graphics cards T> but higher level APIs can access other HW (e.G printer via QuickDrawGX) T> which are ruled out be the current design. Nonsense. T> - several highly hardware specific functions T> -> if this continues, it will be a bloated API. T> - very unflexible mode selection: e.g. GT_xxBIT doesn't say anything about T> colorspace. T> - binding to RGB color model T> - bindung of events to a single visual T> - and lots of other things we cannot resolve quickly. T> Steffen and I deem especially OpenGL to be a well thpught and grown up API, T> which should be our primary goal to support. T> We think, that LibGGI _shouldn't_ be a drawing-API, but only a generic T> visuals-manager, that features loading of seperate APIs. I talked to Steffen. How do you come to that "WE" ??? T> My plan is: T> Build a preliminary framebuffer API (which is not yet set into stone) T> and then implement OpenGL on it ASAP (at best by porting MESA. This EXISTS ! MesaGGI works. And it works fine. There isn't much use of Mesa on a FB actually, but the current implementation already exists accelerated, too. Why step backwards ? T> The advantages are really obvious: T> - we do not fix ourselves to a given drawing API and are fully HW-independent And can only do OpenGL. How many people out there are interested in that ? OpenGL isn't the only thing one can do to do graphics. If we don't fix other API layers, noone can write for them. And a FB-centric OpenGL isn't of much use. It will crawl. T> - we instantly support a common and well designed API, we can release without T> more fuzz. T> - The extension problem goes away (the loaded APIs are almost completely independent T> of LibGGI). T> - we get some free space back, to step by step specify and grow the other APIs T> in a clean way: FB, GGI2D, GGI3D etc. > T> I am working as time allows on a more specific concept and plan to post it on the ML T> next week.(If I don't get everything done, I'll post an incomplete version, the T> rest can be sorted out be discussion). T> You can get a first glimpse by my Degassnapshot on my homepage T> (http://home.pages.de/~tanner/files/degas.tgz) > T> What I actually want to say is: When we make the API change in the next days, we will T> have to fix ourselves to that for all future. T> Maybe we can schedule the discussion until our people are back from the expo and T> I and maybe Steffen have posted our ideas ? O.K. - I am back. Steffen will stay somewhat longer (making holidays), but here is what I say to this discussion (and I have checked it with him): I have presented the current LibGGI to the people at Linux Expo. I talked to many of them, and all liked the concept. CONCLUSION : IT STAYS AS IT IS. Except for some minor glitches regarding extension handling and allowing to override verything, even modesetting etc. LibGGI will continue to have its functionality, which is: - Basic mode setting (Extension may introduce their own, better suited scheme) - Basic drawing for pixel (pixel/hline/vline/box) and vector (line) environments. - Basic color management. Things like WaitRetrace might go to an extension. Other than that : I have told people LibGGI will not change much, and will stabilize from API point-of-view within the next 3 months. Thus I completely draw LibGGI development to me. If you want to work on it, send me patches. CU,Andy P.S.: Thomas - I am getting quite upset at you trying to act "behind the scenes". Don't do this again. If you want to do some other implementation of LibGGI, do so, but call it by some other name. -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 1 13:51:39 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA20928; Mon, 1 Jun 1998 13:51:13 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA12817; Mon, 1 Jun 1998 13:44:25 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 13:44:25 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: EvStack - slight move... Date: 1 Jun 1998 20:45:26 GMT Organization: OnTV Pittsburgh, L.P. Lines: 20 Sender: Jason McMullan Message-ID: <6kv3t6$2jk$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"dn1Mm3.0.y73.VAnSr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2428 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com In the future releases of EvStack (ie, once CVS is up again) the EvStack kernel code will reside in drivers/video, side-by-side with the current fbcon code. EvStack will (via the scroll interface) be able to work with both fbcon and KGI based scrollers. drivers/console will go away. The fbcon integration will also give me a change to dig into the differences between KGI and fbcon, and what can be done to merge the two. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Mon Jun 1 14:22:31 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA20957; Mon, 1 Jun 1998 14:22:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA01927; Mon, 1 Jun 1998 14:18:39 -0700 Resent-Date: Mon, 1 Jun 1998 14:18:39 -0700 To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: Libggi Issues round two is open! Date: 1 Jun 1998 21:22:26 GMT Organization: OnTV Pittsburgh, L.P. Lines: 36 Sender: Jason McMullan Distribution: local Message-ID: <6kv62i$3u6$1@butter.visus.com> References: <6kv3g1$3kh$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"34Liq2.0.lT.kgnSr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2429 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com becka@rz.uni-duesseldorf.de wrote with confidence: > [snip rant] > > Thus I completely draw LibGGI development to me. If you want to work on it, > send me patches. > CU,Andy > P.S.: Thomas - I am getting quite upset at you trying to act "behind the > scenes". Don't do this again. If you want to do some other implementation > of LibGGI, do so, but call it by some other name. Please trim down the ego, please, or at least do it off-list Andy. That said, I don't know why you have such a problem w/Thomas's work - we have _all_ been diverging from the base code since the CVS went down. We have _all_ been doing things `behind the scenes'. Now that the CVS is coming back up (Steffen????) we'll begin merging things. Why not treat Thomas's libGGI as a development version? We need some place where people can try out new ideas, then submit them to you to place into the next rev of the stable libGGI. [a la Linux `odd' and `even' minor numbers] Again, there was no need for this - we are all friends here. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Mon Jun 1 14:46:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA20977; Mon, 1 Jun 1998 14:46:25 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA21201; Mon, 1 Jun 1998 14:22:12 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 14:22:12 -0700 (PDT) Date: Mon, 1 Jun 1998 16:47:22 -0400 (EDT) From: Brian Julin To: Tilman Vogel cc: ggi-develop@eskimo.com Subject: Re: GGI Real-time API (re: unresolved issues and visual science) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"RfF2h3.0.4B5.-jnSr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2430 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 1 Jun 1998, Stefan Mars wrote: > On Mon, 1 Jun 1998, Tilman Vogel wrote: > > I would be glad if you can make suggestions for us which hardware to > > use. How big are the benefits from the AGP architecture? I'd choose based on RT features; I don't have documentation on even a portion of currently available hardware so I wouldn't feel comfortable making a recommendation. Features to look for would be: CRTC and line counter readback Functional IRQ line with both retrace and accelerator triggers Built-in frame-flip or accelerator holdoff for interruptless operation External sync input and holdoff registers for "manual" syncronization Dual-ported ram and flicker-free register access Shadow pallette That would keep you happy for your current purposes and probably a good sight beyond. Perhaps some of the driver developers here could say how their cards stack up against this feature list; the cards I develop for are too old to be bought anymore. > > Since I haven't been programming with GGI: Could you please send me a > > sample code snippet which tells GGI to flip pages and waits for it. > > Looking at the source code I could not figure out which ggi-Function > > actually issues a page-flip. Maybe I am just blind... ggiFlush() is > > something different, right? What is the OpenGL glXSwapBuffers() > > equivalent? Currently the way to page flip is to allocate a mode with virt.y == 2 * visible.y and use ggiSetOrigin(). This is a vga-centric solution, and there will some day (but not in the near future) be a better API. However, this should continue to work (that is, it will work if ggiWaitRayPos() is implemented on your target/driver, with varying levels of reliability depending on the implementation): while () { /* Draw into frame 1 with libGGI or DirectBuffer. */ ggiWaitRayPos(vis, GGIRP_DONTCARE, GGIRP_SYNC); ggiSetOrigin(vis, 0, 0); /* Draw into frame 2 with libGGI or DirectBuffer. */ ggiWaitRayPos(vis, GGIRP_DONTCARE, GGIRP_SYNC); ggiSetOrigin(vis, 0, vis.y * DSCAN_FACTOR) } The presence of the DSCAN_FACTOR is either a bug or unresolved API issue, but sometimes it has been the case in my experience that a doublescanned mode has twice as many positions for the origin than it has logical pixels. Anyway, that's the way to do it as it now stands -- it's deficient. If you choose a card with the right feature set, though, and one supported by a KGI driver writer, you would most likely be able to convince them to add a simple ioctl to /dev/graphics specific to your card to set the card to automatically frame-flip every frame. That would serve as an interim substitute to having support in the API. > > Another question: What are KGI-SUID targets? I thought KGI's goal was > > improving security by making it unnecessary to use suid. Or is this just > > a solution for the time being? > > It is a part of KGI's goal to remove the need for suid. However, not > everyone wants to compile a KGI kernel just to test KGI, and so a > kernel-kgi-module was written. It does the same as a normal KGI kernel, > with the exception of needing suid. Actually it does more like the same as svgalib -- it's a one-process system and is not integrated with the console at all, so it is very much limited. But for development it is very handy, and for getting maximum speed on poorly designed graphics cards. If you are buying hardware for this anyway though, you should be able to get something useable with a secure KGI driver. -- Brian S. Julin From ggi-develop-request@eskimo.com Mon Jun 1 15:19:43 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA21002; Mon, 1 Jun 1998 15:19:35 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA09399; Mon, 1 Jun 1998 15:13:23 -0700 Resent-Date: Mon, 1 Jun 1998 15:13:23 -0700 Message-ID: <19980602001028.B10682@crap.casema.net> Date: Tue, 2 Jun 1998 00:10:28 -0400 From: "smoke van c.r.a.p" To: ggi-develop@eskimo.com Subject: Re: GGI Real-time API (re: unresolved issues and visual science) References: <356C3AA0.79FF8C4A@altavista.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Brian Julin on Sat, May 30, 1998 at 11:01:02PM -0400 Resent-Message-ID: <"o7i2D2.0.PI2.-ToSr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2431 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, May 30, 1998 at 11:01:02PM -0400, Brian Julin wrote: > > On Wed, 27 May 1998, Tilman Vogel wrote: > > most important: Accurate detection of the vsync. Over and over important ;)) Demos are no fun without syncing IMO. --8<--- > Most pentium processors have an undocumented operation code > that allows reading the processor cycle counter. On processors > without this feature, other hardware clocks must be used. > On older 386 models, the available hardware clocks are more > limited than on later models. I have no information > on such features in MIPS, sparc, alpha, m68k or other > architectures... for 386 and 486 one could (and probaly should?) use something like rtLinux, or hope to have the right videocard (which would be funny, for most pc's from back then don't really have the correct buses to put in the `great' *cough* hardware sold nowadays that _do_ support these features. Oh how I love people at IBM crushing Commodore Amiga ;)) --8<--- > 5) Questions: > > For root-access targets (SUID-KGI, SVGAlib, DGA etc) the task can > be run as a separate thread (though the process is subject to > task switching.) In fact, a lot of work can be done in > this fashion and reused in the kernel. Would any thread experts > care to put up a skeleton for this? The thread should optimally > work in atomic chunks -- is this possible to arrange? > > Is it possible to access pentium processor cycle counters in > userspace? -- I would think so... Yep :) I tried and found out that it was real easy. here follows my Very Bad Test: asm.S: -------------------------- #define __ASSEMBLY__ #include .globl counter .file "asm.S" counter: .byte 0x0f /* this is the weird pentium command to */ .byte 0x31 /* put the cycle-counter in EDX:EAX */ /* it's the number of cycles passed /* since the last boot */ ret /* return EAX */ -------------------------- test.c: --------------------------------- #include extern int counter(); void main(void) { while (1) { printf("%d\n",counter()); sleep(1); } return 0; } --------------------------------- compile and link together and see how much fun one can have with a pentium :) Now, for this is my first GNU as program (used to try nasm and tasm ;)), can someone tell me how to make it return edx:eax in stead of the eax it returns now ? ;) > > Separate to the issue of whether it goes in libGGI or > into some extension, I'd like opinions as to whether this interface > looks good or any suggested improvements. > The interface seems fine to me. Looks like a lot of hardware will be supported with this scheme. Now here's my plan for rtlinux-ggi things .. I thought of having a rtLinux task run at `enormous' frequencies like 8192 Hz. ( That's what i run my `copper-effect' (which really isn't a copper-effect, for 1st it's not an amiga and 2nd it's only 8192/70 = ~117 pixellines high, which is really bad compared to the 400 lines one usually has in DOS when waiting for the horizontal retrace.. (blahblah) ) at. ) But this is enough to have rtLinux find out when the vertical retrace will start (or actually when the drawing of the visible area is over). One can then put new data into the vga memory, so there's not even the need to swap pages. One could swap pages of course, and then this strict timing isn't really needed, but that's something different. Now all I have to do is find out the _fastest_ way on earth to send a bit from kernel-rtlinux-module-space to my ggi-user-space-application.. There's this device /dev/rtf0 which i should really give a try, but i thought it'd be even better if one could signal the ggi-process to sleep`()' and signal it to awake when the vertical retrace is over. How much time would it take before the userspace app is up & running again ? (given there's NO worst-case caching/swapping scenario involved - this IS a program that runs in fg - right ;) ) Smoke/C.R.A.P Nice to see that all you people are still alive after these "2 months" ;) From ggi-develop-request@eskimo.com Mon Jun 1 15:42:01 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA21015; Mon, 1 Jun 1998 15:41:56 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA02071; Mon, 1 Jun 1998 15:26:17 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 15:26:17 -0700 (PDT) Sender: thomas@eskimo.com Message-ID: <3573293A.89C4DB78@gmx.de> Date: Tue, 02 Jun 1998 00:20:42 +0200 From: Thomas Tanner X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: andreas.beck@ggi-project.org, GGI mailing list Subject: Re: Libggi Issues round two is open! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"a_ezQ1.0.9W.5goSr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2432 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi Andy, hi everybody ! First of all: wellcome back! > T> We want to present a stable API to the people ASAP. > T> They will really not like more changes in our API, which are to be scheduled now. > EXACTLY. THIS IS WHY WE WILL NOT CHANGE IT. > IF YOU WANT, WRITE YOUR OWN. I DO NOT CARE. Well. I'll see. I've worked on some specs and maybe they can influcence further development of our LibGGI. > T> We think, that LibGGI _shouldn't_ be a drawing-API, but only a generic > T> visuals-manager, that features loading of seperate APIs. > I talked to Steffen. How do you come to that "WE" ??? This is what I've understand from his mails/degas snapshot. Maybe I've got him wrong? > T> My plan is: > T> Build a preliminary framebuffer API (which is not yet set into stone) > T> and then implement OpenGL on it ASAP (at best by porting MESA. > This EXISTS ! MesaGGI works. And it works fine. > There isn't much use of Mesa on a FB actually, but the current implementation > already exists accelerated, too. Why step backwards ? Yes. I know. I just wan't some better integration of MesaGGI. > T> The advantages are really obvious: > T> - we do not fix ourselves to a given drawing API and are fully HW-independent > And can only do OpenGL. No! Don't get me wrong! Of course, OpenGL would not be the only API, it would be the _first_ one we release, because it's very mature and well supported. > How many people out there are interested in that ? Many. OpenGL is standard for 3D-programming and can also be used for other things. > And a FB-centric OpenGL isn't of much use. It will crawl. Of course, but it will take some time until we have full hw-acceleration. > I have presented the current LibGGI to the people at Linux Expo. I talked to > many of them, and all liked the concept. > CONCLUSION : IT STAYS AS IT IS. Except for some minor glitches regarding > extension handling and allowing to override verything, even modesetting etc. > LibGGI will continue to have its functionality, which is: > - Basic mode setting (Extension may introduce their own, better suited scheme) > - Basic drawing for pixel (pixel/hline/vline/box) and vector (line) > environments. > - Basic color management. > Things like WaitRetrace might go to an extension. > Other than that : > I have told people LibGGI will not change much, and will stabilize from API > point-of-view within the next 3 months. > Thus I completely draw LibGGI development to me. If you want to work on it, > send me patches. OK. You have spoken. Let's start. I'll send you my patch with the changes we've discussed some time ago. However, I do not agree with all issues... > P.S.: Thomas - I am getting quite upset at you trying to act "behind the > scenes". Don't do this again. If you want to do some other implementation > of LibGGI, do so, but call it by some other name. Do you really think this was "acting behind the scenes"? I just wanted to delay the api change discussion so that my work was not all for nothing ;-( -- Thomas Tanner ----------------------------- email: tanner@gmx.de tanner@ggi-project.org web: http://home.pages.de/~tanner GGI: http://www.ggi-project.org From ggi-develop-request@eskimo.com Mon Jun 1 16:09:21 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA21031; Mon, 1 Jun 1998 16:09:12 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA09766; Mon, 1 Jun 1998 16:06:40 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 16:06:40 -0700 (PDT) X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Tue, 2 Jun 1998 00:58:06 +0200 (MET DST) From: Stefan Mars To: Brian Julin cc: Tilman Vogel , ggi-develop@eskimo.com Subject: Re: GGI Real-time API (re: unresolved issues and visual science) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"_A6gI2.0.TO2.uFpSr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2433 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 1 Jun 1998, Brian Julin wrote: > I'd choose based on RT features; I don't have documentation on even > a portion of currently available hardware so I wouldn't feel comfortable > making a recommendation. Features to look for would be: > > CRTC and line counter readback > Functional IRQ line with both retrace and accelerator triggers > Built-in frame-flip or accelerator holdoff for interruptless operation > External sync input and holdoff registers for "manual" syncronization > Dual-ported ram and flicker-free register access > Shadow pallette If I remember correctly almost all new graphics hardware supports the above. But I checked against the S3 ViRGE specs, and it could be asked to do the above, with the possible exception of shadow pallette. There are other reasons why I wouldn't recommend an S3 though, the hardware is occasionaly a bit strange :) But anyway, while I certainly agree with Brian that the above is important I would like to point out that it is even more important that the manufacturer supports developers with specs so that we can write that driver (if we aren't working on it yet). Yes, you could use something that just has an X driver and run for example the Xlib target, but that introduces an overhead and still requires suid etc. > Currently the way to page flip is to allocate a mode with > virt.y == 2 * visible.y and use ggiSetOrigin(). This is a > vga-centric solution, and there will some day (but not in the > near future) be a better API. However, this should continue to > work (that is, it will work if ggiWaitRayPos() is implemented > on your target/driver, with varying levels of reliability > depending on the implementation): There is an irc meeting coming up, and one of the subjects is LibGGI-1.5. I will try to remember to talk about the API issue in this field. -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Mon Jun 1 18:31:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA21243; Mon, 1 Jun 1998 18:31:50 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA05654; Mon, 1 Jun 1998 18:36:57 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 18:36:57 -0700 (PDT) Sender: injector@clubneon.dyn.ml.org Message-ID: <35735674.6A639B72@stu.ac.cc.md.us> Date: Mon, 01 Jun 1998 21:33:40 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: PROPOSAL: IRC session friday night References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FbQ0X3.0.4O1.rSrSr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2434 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Should this be announced on the web page? Or do you think that everyone that should know is on this list? -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Mon Jun 1 22:26:43 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA21508; Mon, 1 Jun 1998 22:26:41 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id WAA25384; Mon, 1 Jun 1998 22:33:37 -0700 (PDT) Resent-Date: Mon, 1 Jun 1998 22:33:37 -0700 (PDT) From: Andrew Apted Message-ID: <19980602151048.23993@ajax.netspace.net.au> Date: Tue, 2 Jun 1998 15:10:48 +1000 To: ggi-develop@eskimo.com Subject: Re: irc session, take 2 Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Emmanuel Marty on Mon, Jun 01, 1998 at 07:03:39PM +0200 Resent-Message-ID: <"zlpfR2.0.WC6.kwuSr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2436 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Emmanuel writes: > What about sunday june 7th at 5:00 PM MET (11:00 AM EST) ? > > Here we go again.. > > PST MST CST EST GMT+1 MET GMT+10 > Sun Sun Sun Sun Sun Sun Mon > 08:00A 09:00A 10:00A 11:00A 04:00P 05:00P 01:00A > > Now that would be Andrew J. Apted who has to be up at 1 AM on the night of > sunday to monday, but hopefully he's in holidays and can do that :) :-) No worries. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Tue Jun 2 02:29:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA21782; Tue, 2 Jun 1998 02:29:37 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA19921; Tue, 2 Jun 1998 02:29:55 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 02:29:55 -0700 (PDT) Message-ID: <005801bd8e08$c5154530$3c3343c3@masteron-003.masteron.com> From: "Jim Kjellin" To: Subject: Re: Current Mode negotiation Date: Tue, 2 Jun 1998 11:28:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mx2.eskimo.com id CAA19897 Resent-Message-ID: <"kxAde1.0.7t4.HOySr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2438 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >I've had a thought. (no sarcastic comments please :-) > >At the moment the Mode negotiation in KGI selects the highest possible >refresh for the mode selected. This can lead to modes like 640x480@150Hz >and such like. While this is great if you're just sitting and staring at >a monitor, it could have a rather nasty effect on the performance of >various graphics boards. > >If a graphics board uses a single ported memory (SDRAM, SGRAM, EDO DRAM, >but not VRAM or WRAM) then the graphics processor must read the >framebuffer continually to supply data to the RAMDAC. The higher the >resolution the more it has to read. The higher the refresh the more >often it must read it. So setting an astronomical refresh rate means >that very little memory bandwidth is left to do operations on the >framebuffer. The net result is that performance will die. > >So I propose that we come up with a system that will stop this from >happening. I would say that refresh rates in excess of 100Hz are not And we don't need more than 8.3 character per filename ;). I personally use refreshratesranging from 75Hz -> 160 Hz, imposing this limit will not be a good idea. >necessary, so a simple way would be to introduce a hard limit at some >point. But what about the user that decides 'I value performance over my >eyes, therefore I want all modes at 60Hz'? Why not lets this be a configuration matter, let the user setup the diffrent refreshrates he/she(/it) wants for the diffrent resolutions. Choice is always good. > >Comments? > >Cheers > >Paul > --- Jim From ggi-develop-request@eskimo.com Tue Jun 2 02:29:46 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA21787; Tue, 2 Jun 1998 02:29:44 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA19450; Tue, 2 Jun 1998 02:22:17 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 02:22:17 -0700 (PDT) Message-ID: From: Paul Sargent To: "'ggi-develop@eskimo.com'" Subject: RE: Current Mode negotiation Date: Tue, 2 Jun 1998 10:07:03 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lW3-63.0.ol4.7HySr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2437 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Brian Wrote: > I would tender the question as to whether video memory bandwidth > is actually constricted severely by refresh rate. While I understand what you're saying the current system tends to set very high refresh rates "because it can", and no thought is given to any other side effects. It's entirely possible that you can set a mode that uses all of the available bandwidth "because it can". Admittedly the speed of the RAMDAC is the normal limiting factor before the memory bandwidth is, but with nextgen RAMDACs coming in above 250MHz (Permedia 2 is currently 230MHz) the bandwidth for refreshing the screen could be as high as 1GB/s (4Bytes per pixel * 250MHz). It's an extreme figure, but it's about half of anybody's memory bandwidth. It's not as small as you might think and any reduction in this can give a lot of performance. The other point is that VRAM is now dead. IBM and Samsung (the two major manufacturers) are end-of-lifeing their parts and so Graphics Chips designers have no option but to go for something like S[DG]RAM. In the future we are stuck with single ported RAMs (no commodity in graphics specific stuff). I hope that explains why I think this is a real issue. Paul >-----Original Message----- >From: Brian Julin [SMTP:bri@forcade.calyx.net] >Sent: Monday, June 01, 1998 12:59 PM >To: ggi-develop@eskimo.com >Subject: RE: Current Mode negotiation > >On Mon, 1 Jun 1998, Paul Sargent wrote: >> So I'd propose that in general the Mode request become something like: >> >> * 1024 x 768 @ * Hz (Wildcard for Frequency means give me anything >> you've got) >> * 1024 x 768 @ 75 Hz (Give me the closest thing to 75 you have) >> >> I'd then also have a system like the one guillaum@clipper.ens.fr >> proposed below to allow the user to override the range of frequencies >> available to the applications. > >This would be a rather peicemeil solution to the general problem of >allowing the app to position/time the display itself. It would require >adding a frequency field to the mode request; Andy has expressed that >we are not to change libGGI's API for a while yet. So while it would be >easy I'd say holding out for a more thorough system is better. In >the lull that has been going on, I have actually started transcoding >the system I was working on into C, which is a step forward at >least, but it will be taking a back seat to drivers as soon as Jason >releases the KGI/EvStack/fbcon driver specifications. > >I would tender the question as to whether video memory bandwidth >is actually constricted severely by refresh rate -- granted full >frame loading for animation is bottlenecked on ISA systems for >higher resolution and frequencies, but I'd venture most PCI cards >can do a frame load during retrace at rather high frequencies, >and they probably don't offer very high dotclocks without also >having VRAM. So though desirable this feature isn't in my mind >a priority. Please correct me if actual performance numbers >to the contrary are available. > >As noted in Hartmut's summary of open issues, the consensus >seems to be that the driver mode setting code should validate >and set mode timings only, and that the actual calculations >for anything beyond basic console textmodes should occur in >userspace. Any userspace library to do this could obey systemwide >default settings and allow overiding in the environment. >Stephen mentioned working on this concept and I am as well. > >-- >Brian S. Julin > From ggi-develop-request@eskimo.com Tue Jun 2 04:26:58 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA21833; Tue, 2 Jun 1998 04:26:56 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA03220; Tue, 2 Jun 1998 04:17:25 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 04:17:25 -0700 (PDT) Message-ID: From: Paul Sargent To: "'ggi-develop@eskimo.com'" Subject: RE: Current Mode negotiation Date: Tue, 2 Jun 1998 12:02:09 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KrTKP3.0.Bo.3zzSr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2439 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I agree. I don't want hardcoded frequency limits either. I'm just highlighting what a believe to be an oversight. Frequency of Screen refresh should be selectable. Paul >-----Original Message----- >From: Jim Kjellin [SMTP:jim.kjellin@masteron.com] >Sent: Tuesday, June 02, 1998 10:28 AM >To: ggi-develop@eskimo.com >Subject: Re: Current Mode negotiation > > >Why not lets this be a configuration matter, let the user setup the diffrent >refreshrates he/she(/it) wants for the diffrent resolutions. > >Choice is always good. > > >--- Jim > From ggi-develop-request@eskimo.com Tue Jun 2 07:11:36 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA21967; Tue, 2 Jun 1998 07:11:28 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA01860; Mon, 1 Jun 1998 19:08:54 -0700 Resent-Date: Mon, 1 Jun 1998 19:08:54 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: irc session, take 2 To: ggi-develop@eskimo.com Date: Mon, 1 Jun 1998 22:21:23 +0200 (MET DST) In-Reply-To: from "Emmanuel Marty" at Jun 1, 98 07:03:39 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"d5RWk2.0.wS.rwrSr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2435 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > What about sunday june 7th at 5:00 PM MET (11:00 AM EST) ? > > Here we go again.. > > PST MST CST EST GMT+1 MET GMT+10 > Sun Sun Sun Sun Sun Sun Mon > 08:00A 09:00A 10:00A 11:00A 04:00P 05:00P 01:00A > Is that fine for everyone ? Fine with me. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 2 08:02:55 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA22002; Tue, 2 Jun 1998 08:02:53 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA16906; Tue, 2 Jun 1998 08:05:26 -0700 Resent-Date: Tue, 2 Jun 1998 08:05:26 -0700 Date: Tue, 2 Jun 1998 11:05:34 -0400 (EDT) From: James A Simmons To: "'ggi-develop@eskimo.com'" Subject: RE: Current Mode negotiation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"5Kjjp1.0.084.rI1Tr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2440 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 2 Jun 1998, Paul Sargent wrote: > I agree. I don't want hardcoded frequency limits either. I'm just > highlighting what a believe to be an oversight. > > Frequency of Screen refresh should be selectable. I second this. But I believe root should be able to do this. It would be bad if jane doe blows his monitor. This should be done threw evstack. > > Paul > > >-----Original Message----- > >From: Jim Kjellin [SMTP:jim.kjellin@masteron.com] > >Sent: Tuesday, June 02, 1998 10:28 AM > >To: ggi-develop@eskimo.com > >Subject: Re: Current Mode negotiation > > > > > >Why not lets this be a configuration matter, let the user setup the diffrent > >refreshrates he/she(/it) wants for the diffrent resolutions. > > > >Choice is always good. > > > > > >--- Jim > > > From ggi-develop-request@eskimo.com Tue Jun 2 10:03:17 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA22120; Tue, 2 Jun 1998 10:03:08 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA01668; Tue, 2 Jun 1998 09:57:00 -0700 Resent-Date: Tue, 2 Jun 1998 09:57:00 -0700 Date: Tue, 2 Jun 1998 12:56:54 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: RE: Current Mode negotiation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"zXG_x1.0.xP.Rx2Tr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2441 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 2 Jun 1998, James A Simmons wrote: > > Frequency of Screen refresh should be selectable. > I second this. But I believe root should be able to do this. It would be > bad if jane doe blows his monitor. This should be done threw evstack. It has always been the intent that the KGI drivers protect the hardware completely, so restricting a maximum refresh rate need not be a root-only privilage. Root decides which kgi modules are loaded, and in so doing, protects the attached hardware. The monitor module overrides any request for a higher refresh rate than the monitor can take. Let me reclarify my previous statements on this and hopefully say some things that makes everyone happy here :). It's not that I don't think the current interface doesn't need changing, for many more reasons than it maxing out the refresh rate by default. It's just that adding little tweaks to the current system is not worth it; the change should be done right and I'm working on drafting out what "right" is and coding it and testing it. Those few people who have problems with memory bandwidth can simply alter their monitor driver to choke KGI down, for now. In the end I hope to provide a KGI subsystem interface for mode selection that is versitile, offers an avenue for extremely thorough mode validation and programming, for temporary quick development hacks, and for a spectrum of options between depending on the driver author's skill, documentation, and time. Userspace mode calculation utilities will have an interface to this system and can be written with varying degrees of sophistication. Kernel-space routines will be stark and relatively simpleminded. The main function of the kernel code is not to figure out how to program a mode, but rather to accept or reject pre-chewed mode requests from userspace. The system is VERY complicated because the problem it solves is very complex, however "cheat sheets" will be offered that will allow a driver writer to get a decent level of negotiation capability without investing in learning the nooks and crannies of the system. The end objective is that even if the subsystem interface is never used to it's full potential, it will never (sound of wood being knocked on) need to be changed. It is to some degree expandable and customizable. If Jason doesn't distract me with an EvStack driver interface description by this weekend I should have enough of a degree of functionality to release a barely functional version and start keeping a status log. This will tie into making mode setting completely overridable, as to offer a maximum degree of flexibility, the KGI drivers could be made able to suggest a library to dynamically load. I think this proposed step is a good one and will open doors for faster and more streamlined development. For example, VESA monitor and VBE drivers could be written which essentially just contain VBE mode index numbers that are kosher for a given monitor or available on a given chipset, and load a userspace library that knows what mode number to send based on a user request. This alternate system could be used without altering libGGI, would be extremely simple, and would allow GGI to work on the machines of people who don't want to void their warranty by using their equipment outside of the rather strict "specifications" which some manufacturers provide (i.e. a static table of resolutions and frequencies). (wow this e-mail sure got too long too fast :) -- Brian S. Julin From ggi-develop-request@eskimo.com Tue Jun 2 10:20:07 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA22126; Tue, 2 Jun 1998 10:20:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA09541; Tue, 2 Jun 1998 10:20:14 -0700 Resent-Date: Tue, 2 Jun 1998 10:20:14 -0700 Date: Tue, 2 Jun 1998 11:36:30 -0400 (EDT) From: James A Simmons Reply-To: James A Simmons To: Jason McMullan cc: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... In-Reply-To: <6kv3t6$2jk$1@butter.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cQMf11.0.dK2.BH3Tr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2442 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On 1 Jun 1998, Jason McMullan wrote: > In the future releases of EvStack (ie, once CVS is up again) > the EvStack kernel code will reside in drivers/video, side-by-side > with the current fbcon code. EvStack will (via the scroll interface) > be able to work with both fbcon and KGI based scrollers. > > drivers/console will go away. Yes. This is great. This will make porting easier. Is this new setup available from your web page. I was working on a similar thing. In fact I have seperated /dev/graphic from kgi. I feel that kgi is just for text functions. So I moved /dev/graphic into the ggidrv module and placed this into a seperate tree in the kernel source tree (driver/ggi). I will be placing this on my web page sometime today. One warning, ggidrv is broken. The kgi structs in evstack are different then the earlier kgi structures. Now that the CVS will be opening the drivers will be adapted for evstack. > > The fbcon integration will also give me a change to dig into > the differences between KGI and fbcon, and what can be done > to merge the two. > > -- > Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc > > On the wonderful world of Microsoft Products: > > Why put fault tolerance in the OS, when it's > already built into the User? > -- Steve Shaw > comp.os.linux.advocacy > From ggi-develop-request@eskimo.com Tue Jun 2 11:01:06 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA22199; Tue, 2 Jun 1998 11:01:04 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA02036; Tue, 2 Jun 1998 11:01:42 -0700 Resent-Date: Tue, 2 Jun 1998 11:01:42 -0700 Message-Id: <199806021755.NAA02400@pepsi.visus.com> Subject: New EvStack code... To: ggi-develop@eskimo.com Date: Tue, 2 Jun 1998 13:55:05 -0400 (EDT) Reply-To: jmcc@ontv.com From: Jason McMullan Content-Type: text Resent-Message-ID: <"-Mwuq1.0.WV.3u3Tr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2444 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Until CVS is back up... I'm releasing EvStack on http://pepsi.visus.com/~jmcc/EvStack (newest is EvStack-0.3.tar.gz) and accepting patches. Emmanuel's text -> dpp patch should be in, and I've made a first-pass at modifying the IBM vga driver to use dpp instead of text. Note the lack of libGGI in this distribution - you'll have to pick that up `under separate cover'... Also I have yet to move the code from linux/drivers/console to linux/drivers/video - I am reconsidering that.... [fbcon is a mess...] Please bang on it and send me bug reports/patches - I'll try to have a release out every two days. If you want diffs between releases, tell me now. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Tue Jun 2 11:03:49 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA22208; Tue, 2 Jun 1998 11:03:47 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA12468; Tue, 2 Jun 1998 11:03:52 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 11:03:52 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: Current Mode negotiation Date: 2 Jun 1998 18:05:19 GMT Organization: OnTV Pittsburgh, L.P. Lines: 17 Sender: Jason McMullan Distribution: local Message-ID: <6l1esv$66l$1@butter.visus.com> References: <6l1brn$5b4$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"g2oFm2.0.P23.1w3Tr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2443 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Brian Julin wrote with confidence: > If Jason doesn't distract me with an EvStack driver interface description > by this weekend I should have enough of a degree of functionality to > release a barely functional version and start keeping a status log. Hey - that's not fair! Emmanuel, tell him not to encourage my natural procrastination abilities! ;^) -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Tue Jun 2 11:46:41 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA22241; Tue, 2 Jun 1998 11:46:38 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA19347; Tue, 2 Jun 1998 11:40:27 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 11:40:27 -0700 (PDT) Message-Id: <199806021837.OAA03059@pepsi.visus.com> Subject: Re: EvStack - slight move... To: jsimmons@acsu.buffalo.edu Date: Tue, 2 Jun 1998 14:37:54 -0400 (EDT) Cc: ggi-develop@eskimo.com Reply-To: jmcc@ontv.com In-Reply-To: from "James A Simmons" at Jun 2, 98 02:14:06 pm From: Jason McMullan Content-Type: text Resent-Message-ID: <"DD5kQ1.0.4k4.KS4Tr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2445 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com James, [and everyone else], here's the model: /dev/ttyX - does NOT handle mode switching, events or any of that rot. Just does tty stuff. Without the `conlinux' compatability driver, doesn't even TOUCH VT handling in any way. /dev/graph - handles mode switching - INCLUDING text modes. Remember, for anything OTHER than a PC, textmodes == graphics modes. In EvStack, this driver is a kernel modules. KGI - provides the framework which a driver resides in. ggidrv-S3.o - provides a KGI display for each S3 card installed. ggidrv-VGA.o - provides a KGI display for a generic VGA card ggidrv-Herc.o - provides a KGIU display for your hercules card All of the above could be loaded for a 3 headed system. Each could be removed, inserted, etc. without having to reboot. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Tue Jun 2 12:14:47 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA22265; Tue, 2 Jun 1998 12:14:43 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA25986; Tue, 2 Jun 1998 12:13:04 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 12:13:04 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: VESA Monitor Timings To: ggi-develop@eskimo.com Date: Tue, 2 Jun 1998 20:17:16 +0200 (MET DST) In-Reply-To: from "Paul Sargent" at May 30, 98 04:26:16 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"i37Ri3.0.nL6.vw4Tr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2447 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I decided I needed a set of monitor timings for more than just the ones > currently included in the current snapshots. So I've done a set from the > the VESA DMT specs. Thanks. Applied. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 2 12:17:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA22270; Tue, 2 Jun 1998 12:17:38 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA26263; Tue, 2 Jun 1998 12:14:55 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 12:14:55 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Current Mode negotiation To: ggi-develop@eskimo.com Date: Tue, 2 Jun 1998 20:24:33 +0200 (MET DST) In-Reply-To: from "Paul Sargent" at Jun 1, 98 10:00:44 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"MVmDG.0.BQ6.hy4Tr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2448 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > The app is going to be the best 'person' to know whether it's going to > need full out performance or a nice display, but being *nix users > there's a bit of 'user knows best' in all of us. I'd say "user knows best", because it strongly depends on the user, if he can bear a given refresh. For me, I get annoyed below 60Hz, but others say they need to have at least 80, or they see flickers, while yet others might cope with 35Hz. So what I would suggest is enhancing all monitor drivers to be configureable like the timelist one is. Then a simple command like "tunemode highrefresh" or "tunemode highspeed" should do. I opt against putting that into the application to avoid some "smart" application to override my defaults. You will seldomly want to change your policy with the application, and if you want, this is what batch files are for. I'd be annoyed if some "smart" application would request 60 Hz on my VRAM card to speed things up (which won't happen, but flicker will annoy me). CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 2 12:22:03 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA22277; Tue, 2 Jun 1998 12:22:01 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA25923; Tue, 2 Jun 1998 12:12:47 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 12:12:47 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: S3/Virge Support To: ggi-develop@eskimo.com Date: Tue, 2 Jun 1998 20:09:27 +0200 (MET DST) In-Reply-To: <524299DFAB41D11193EF00805F8598024F665D@brekka.ch2m.com> from "Fulgham, Brent/SCO" at May 28, 98 10:30:44 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"YFbBZ2.0.qK6.iw4Tr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2446 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > 1. When I insmod the driver, the monitor changes modes, but it shifts > the left edge of the screen towards the right by approximately four or > five characters (say 30 - 40 pixels?). Under X I would adjust the > horizontal sync to correct this. Is there some way to "tune" this? This depends on the driver you use. timelist is nicely tuneable using the "tunemode" utility. Others are not (fixed in the monosync entries, calculated for multisync). We should add the capability to tune these. > 2. For some reason the test programs in the LibGGI/demos directory > don't think I can set my monitor at 1024x768 at any color depth. > How is this determined by GGI? Chipset driver normally. Some other constraints may also apply. Please send your complete configuration (.config from /drivers/). CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 2 12:34:34 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA22299; Tue, 2 Jun 1998 12:34:31 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA29665; Tue, 2 Jun 1998 12:34:24 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 12:34:24 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Libggi Issues round two is open! To: ggi-develop@eskimo.com (mailing list GGI) Date: Tue, 2 Jun 1998 20:30:37 +0200 (MET DST) In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jun 1, 98 03:34:28 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"8Y7zg3.0.OF7.-E5Tr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2449 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello all ! > P.S.: Thomas - ... S O R R Y ! I want to sincerely apologize for being rude and impolite, especially on the list. Thanks to all who have notified me. Thomas : Please accept my sincere apologies. I'll send you PM about it. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 2 12:37:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA22304; Tue, 2 Jun 1998 12:37:08 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA00495; Tue, 2 Jun 1998 12:37:53 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 12:37:53 -0700 (PDT) Date: Tue, 2 Jun 1998 20:28:40 +0200 (CEST) From: Emmanuel Marty X-Sender: core@gate.local To: ggi-develop@eskimo.com cc: jmcc@ontv.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"nSRjB3.0.d7.DI5Tr"@mx2> Resent-From: ggi-develop@eskimo.com Subject: Unidentified subject! Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2450 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jason McMullan was sober when he wrote: > Until CVS is back up... > > I'm releasing EvStack on http://pepsi.visus.com/~jmcc/EvStack I will maintain the CVS repository from now on. Tomorrow (wednesday), I am putting a new server online, where I intend to move (among other things) all services for ggi-project.org, such as the primary DNS and mail exchanger. That's where I'll set the CVS server up as well, together with anything else that would come in handy - I have plenty of bandwidth there and the server is quite oversized for now. No worries, there will be no interruption of service as both the new and old server will answer until all traffic has moved. Tomorrow evening, Andreas will populate it (cvs import the current GGI source tree) and we'll check that everything works fine. It means that by thursday morning (MET), CVS will be available to developers again - so you won't have to post snapshost there for long :) Andreas will announce that better, but I plan to do the following : host two CVS server, a "stable" and "development" one . The stable will have a rather restricted access (i.e. a few people) and will generate stable snapshots that people such the Berlin Consortium can expect to work fine, not fearing we broke something last night or introduced uncoordinated changes (sounds familiar? :). All developers will have access to the "developer" CVS tree, where new ideas can be tested. devel snapshots can be generated as well if needed. Then the few people responsible for the stable tree will carefully pick things and move them into the stable server. It will possible as well, to post patches via anonymous FTP then informing us of the patch on the mailing list. > (newest is EvStack-0.3.tar.gz) and accepting patches. Emmanuel's > text -> dpp patch should be in, and I've made a first-pass > at modifying the IBM vga driver to use dpp instead of text. Beware - the EvStack version forked off the Dali tree a long time ago, we should sync the changes made to the Dali version, into the EvStack version, too. Or re-port the current Dali VGA driver, supposedly it's simple :-) > Note the lack of libGGI in this distribution - you'll > have to pick that up `under separate cover'... Yes.. No worries - you have better to do that syncing with current libggi all the time. Please see with Andy how EvStack can be migrated in the CVS server thursday together with libggi. > Also I have yet to move the code from linux/drivers/console > to linux/drivers/video - I am reconsidering that.... > [fbcon is a mess...] Maybe an evstack subdirectory there? I agree, fbcon files aren't sorted much (and mixed with video4linux files, too). /me glares at Alan and Geert :) Wherever the EvStack files are in the kernel tree, as long as they come in as an optional, portable patch, that's fine by most people standards. Hmm, does that mean we have to put a linux kernel tree on the CVS server as well (like at vger) ? Or will you just put patches there (like it is currently) ? > Please bang on it and send me bug reports/patches - I'll > try to have a release out every two days. If you want diffs > between releases, tell me now. Try to wrap up a functional version for thursday-sometime (ie. running the VGA driver), and able to merge in with libggi, so that it can be commited to CVS and everyone can work on it :) I think you should ditch from the files you commit to CVS, all drivers besides the VGA one, as they all are outdated and aren't ported anyway (better start over from the Dali ones). -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 2 16:26:19 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA22563; Tue, 2 Jun 1998 16:26:17 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA12033; Tue, 2 Jun 1998 16:16:06 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 16:16:06 -0700 (PDT) Date: Tue, 2 Jun 1998 20:36:13 +0200 (CEST) From: Emmanuel Marty X-Sender: core@gate.local To: ggi-develop@eskimo.com Subject: Re: Current Mode negotiation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"YCInw2.0.rx2.rU8Tr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2453 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jason McMullan did write: (oops, sorry if the previous mail lacked a subject, I write first and think later) > Hey - that's not fair! Emmanuel, tell him not to encourage > my natural procrastination abilities! ;^) Bah, if your proposal isn't up before the IRC session (sunday that is), we'll just assign you the win32 port of evstack.. Now you should be scared *grin* -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 2 19:13:03 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA22728; Tue, 2 Jun 1998 19:13:00 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA19993; Tue, 2 Jun 1998 19:14:24 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 19:14:24 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Tales of Magic ... To: ggi-develop@eskimo.com (mailing list GGI) Date: Tue, 2 Jun 1998 23:58:10 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"7Lzsj.0.Eu4.z5BTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2454 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Mists whirl over the opening deep down in the woods. It is midnight, and a full moon is about to reach zenith. A big fire is burning in the middle of the gathering. It's red and yellow flames fill the scene with an unreal light. Its reflection in the eyes of those terrifying figures, minions of DOOM would scare any innocent soul that would accidentially pass by. They are singing and chanting a ritual as old as the earth, to summon the Master back from the outer planes, where he has been defending his kingdom and spread the word about their power. A ringing sound floats over the place, as the master materializes, being pulled back from the weird place called Opex. He is hovering over the fireplace and steps out to speak to his minions: "Minions - hear me ! I have just returned from a big gathering of those that hold the secret powers that will change our world. I have good news and bad. It does not seem, as if we would join the inner sancturary soon, but word about us is spreading, and we are growing more and more, becoming more powerful as we walk. But there is hard work ahead of us. There are many potential followers out there, and I promised them, to slow down our pace and less often change the secret enchantments needed to summon the power of our magic. So hear me minions, what the tides of time are bringing us : Our main repository of magic spells has been reopened for a few of us that have reached the inner circles of wisdom, and those will be obliged to care and feed the beasts living there. Those masters are for now : - Andreas_Beck - Emmanuel_Marty - Hartmut_Niemann - Jason_McMullan - Steffen_Seeger The magic incantation is e.g. CVSROOT=Andreas_Beck@ggi.hrz.tu-chemnitz.de:/disk/cvs/ggi using the same words of wisdom to pass the exam of the authorization demon, as they did before. However latest news reach me, that our primary hall of wisdom has a jammed door and I have no "knock" spell ready. Therefore our brave master of halls and homes, the high wizard Emmanuel will use it's "Emmanuel's secure shelter" spell to give us a new home soon. He will notify us, when he has gathered all the components and cast his spell. He might also open another home that is lightly built and with no roof, so experiments can be done there without harm. Noone will care if it blows up. It will just be restored to a sane state, then. In the past, we have seen to many powers being released without proper control. This is too dangerous for all of us, so we decided to change the rules for adding to the powers to submitting the new spells as diffs to the maintaining masters. Note, that the masters have complete power over the fields they control. Don't question their wisdom - if they reject a new spell, there is normally a reason. Improve it the way they suggest, and chances rise you get it in. There is still the lofty house of experiments, for those who want to ramble around with new things. We will also change the way our development works. We have to stop the "do what you like, and what you can do best" for a while. We will never get around to remove some nasty side effects and nuisances, like the funny smell after teleporting this way. I will set "milestones" and we will _all_ work towards them. Maintainers will not accept other patches (except they fix obvious bugs or similar), while working towards a milestone. Sorry - I know this won't be as much fun, but that is exactly the reason, that will finally drive us to do all this nasty legwork and cut those little buglets out. The general line of development for the next few months will be : 1. Set LibGGI in stone. Until the 1st of July I will make changes to the LibGGI API and some internals that will allow some of the limitations to go away. Especially for Extensions. The calling API will not change significantly for usermode programs. However extensions will be allowed to do things like mode setup and such for covering enhanced needs. From then on, until the 1st of September, we will track down any bugs we can find in there. It must be foolproof to install by then. 2. Set KGI in stone. Steffen will lead this one. Let's wait for him to come back. This will run in parallel to 1. 3. Other APIs/libraries are added/enhanced. This means especially LibGGI2D and MesaGGI. 1. and 2. _must_ be completed before this happens. 4. When the most interesting libs are complete, the ports to DOS, Win and optionally BeOS/Solaris etc. are done. Development will be _frozen_ until LibGGI runs under DOS and Win. PERIOD. We _must_ get this done, and this way, we _have_ to do it and _all_ will at least _try_ to make it work. So dear minions forgive me taking away some of your freedom. This isn't slavery, it is done for the good of all. Speak kindly to the masters, and they will probably consider any change you send them. Our repository must be guarded against leaving it in inconsistent state, where noone can find the wisdom and power he wants. Don't fall to desperation, when you have to work on building walls, when you could craft mighty spells. Without the walls a single storm might blow us away. Help us all to survive. As soon as our stronghold is safe, we can again do what I told the powers at Opex : REACH FOR THE STARS ! " Then, with mighty thunder rolling over the plane of the gathering, the master wields his mighty wand, and Nectar and Ambrosia spring from the giant stones that surround the fire in a magic circle. The unreal sounds of mystic music rise through the air as does the sweet smell of burning incense. The feast is now just about to start ... [to be continued] -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 2 20:55:41 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA22778; Tue, 2 Jun 1998 20:55:39 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id UAA01301; Tue, 2 Jun 1998 20:54:11 -0700 Resent-Date: Tue, 2 Jun 1998 20:54:11 -0700 Date: Tue, 2 Jun 1998 22:52:03 -0500 (CDT) From: "Edward S. Marshall" To: andreas.beck@ggi-project.org Cc: mailing list GGI Subject: Re: Tales of Magic ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"nebPR2.0.AK.XZCTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2455 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 2 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Mists whirl over the opening deep down in the woods. [...] Man, I hope someone is archiving these. Andreas, these inspirational posts of yours are too cool for words. :-) -- -------------------. emarshal at logic.net .--------------------------------- Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/ Linux labyrinth 2.1.101 #2 SMP Sun May 10 22:34:20 GMT 1998 i586 unknown 10:50pm up 5 days, 10 min, 3 users, load average: 0.09, 0.31, 0.25 From ggi-develop-request@eskimo.com Tue Jun 2 21:02:24 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA22792; Tue, 2 Jun 1998 21:02:22 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA13268; Tue, 2 Jun 1998 21:08:33 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 21:08:33 -0700 (PDT) Message-Id: <199806022010.QAA04199@pepsi.visus.com> Subject: Re: EvStack - slight move... To: jsimmons@acsu.buffalo.edu (James A Simmons) Date: Tue, 2 Jun 1998 16:10:27 -0400 (EDT) Cc: ggi-develop@eskimo.com Reply-To: jmcc@ontv.com In-Reply-To: from "James A Simmons" at Jun 2, 98 03:34:01 pm From: Jason McMullan Content-Type: text Resent-Message-ID: <"y6qpW2.0.4F3.-mCTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2456 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com 'James A Simmons wrote with particular insight...' > One other thing. What if I have two cards and two monitors. Then this > should be ggi-Matox-multisync.o and ggi-S3-timelist.o right. What if I > switch the monitors? Make new modules gg-Matrox-timelist.o and > ggi-S3-multisync.o. Any solutions? > Well, that's the bastard about the current KGI build scheme. What we really need is some sort of `monitor class' that you can insert first, then say for a system with a VGA monitor on a S3, a Samsung Syncmaster GLsi 17" on another S3 card, and another VGA monitor on a Matrix, you could: # insmod ggi-monitor-vga.o # insmod ggi-monitor-Samsung17GLsi.o # # insmod ggi-display-S3.o display=0:vga,1:Samsung17GLsi # insmod ggi-display-Matrox.o display=2:vga # # cat /proc/evstack/heads #Head Display Monitor 0 S3-Virge vga 1 S3-Virge Samsung17GLsi 2 Matrix-Millenium vga where display=: Hmm... With the `display class' concept, we could (theortically) create monitor classes where you can load their parameters via /proc, ie: # echo "create-monitor 1" >/proc/evstack/class/monitor-vga # cat </proc/evstack/monitor/1 set horiz 50-60 set vert 31.5,32,36-130 EOF # Any ideas? -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Tue Jun 2 21:10:43 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA22798; Tue, 2 Jun 1998 21:10:40 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA14911; Tue, 2 Jun 1998 21:17:01 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 21:17:01 -0700 (PDT) Delivered-To: fixup-ggi-develop@eskimo.com@fixme Message-ID: <3574CDC4.541B7F54@ne.uswest.net> Date: Tue, 02 Jun 1998 23:15:00 -0500 From: Phil Brutsche X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: ggi-develop@eskimo.com CC: "Edward S. Marshall" Subject: Re: Tales of Magic ... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ocdQD3.0.se3.wuCTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2457 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Edward S. Marshall wrote: > > On Tue, 2 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > > Mists whirl over the opening deep down in the woods. [...] > > Man, I hope someone is archiving these. Andreas, these inspirational posts > of yours are too cool for words. :-) I've been archiving this list since December or so on my computer, so I can try to dig them out if anyone wants to see them. -- ---------------------------------------------------------------------- Phil Brutsche "Be of stout heart, Number One. We've handled the Borg. We can certainly handle Admiral Jellico." - Jean-Luc Picard Help stop spam! Visit http://www.cauce.org ---------------------------------------------------------------------- From ggi-develop-request@eskimo.com Tue Jun 2 21:28:34 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA22805; Tue, 2 Jun 1998 21:28:28 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA18634; Tue, 2 Jun 1998 21:29:40 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 21:29:40 -0700 (PDT) Date: Tue, 2 Jun 1998 23:13:17 +0000 (GMT) From: Michael Funk X-Sender: mwfunk@foo.bar.com Reply-To: mwfunk@uncc.campus.mci.net To: GGI list Subject: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Soep53.0.-Y4.c4DTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2458 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hopefully this isn't an inflammatory question to ask: was any decision ever made regarding the licensing of KGI? A while back there was some discussion of putting it under a non-copyleft license, so that other free OS's (*BSD's, etc.) could use it without fear of 'tainting' their kernels, as the GPL is inclined to do. I ask this now because it seems like if this is ever going to happen, it needs to be done as soon as possible. It's my understanding that a GPL'd piece of software can be relicensed only if all of the developers agree to it. As time goes on, and the number of contributors increase, this will become darned near impossible. If anyone has any intention of 'freeing' KGI from the copyleft, so that it may be shared with others while respecting their own licenses, it needs to be done ASAP. Mike From ggi-develop-request@eskimo.com Tue Jun 2 21:32:54 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA22810; Tue, 2 Jun 1998 21:32:46 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA20026; Tue, 2 Jun 1998 21:34:56 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 21:34:56 -0700 (PDT) From: Andrew Apted Message-ID: <19980603131627.01972@ajax.netspace.net.au> Date: Wed, 3 Jun 1998 13:16:27 +1000 To: ggi-develop@eskimo.com Subject: Re: Unidentified subject! Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Emmanuel Marty on Tue, Jun 02, 1998 at 08:28:40PM +0200 Resent-Message-ID: <"YxTUV1.0.Pu4.R9DTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2459 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Emmanuel writes: > > Also I have yet to move the code from linux/drivers/console > > to linux/drivers/video - I am reconsidering that.... > > [fbcon is a mess...] > > Maybe an evstack subdirectory there? I agree, fbcon files aren't sorted > much (and mixed with video4linux files, too). It's not that bad :-). All the low-level drivers are called '*fb.c', all the framebuffer handlers are called 'fbcon-*.[ch]', and all the abstract console drivers are called '*con.c'. That covers most of it. [And video4linux is in drivers/char, just to pick nits :-)]. > Wherever the EvStack files are in the kernel tree, as long as they come > in as an optional, portable patch, that's fine by most people standards. > > Hmm, does that mean we have to put a linux kernel tree on the CVS server > as well (like at vger) ? Or will you just put patches there (like it is > currently) ? Come to think of it, putting the EvStack code in drivers/video is a really bad idea IMO. That really *would* make a mess. I was going to suggest using drivers/char, but that's pretty darn messy now, let alone *after* putting EvStack in it :-). How about "drivers/evstack" ? There are nearly 30 sources files, so having it's own directory would not be overkill, and it certainly makes development easier (being able to symlink drivers/evstack -> wherever the CVS snapshot is). Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Tue Jun 2 21:48:30 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA22817; Tue, 2 Jun 1998 21:48:28 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id VAA11694; Tue, 2 Jun 1998 21:54:52 -0700 Resent-Date: Tue, 2 Jun 1998 21:54:52 -0700 From: Andrew Apted Message-ID: <19980603123654.10913@ajax.netspace.net.au> Date: Wed, 3 Jun 1998 12:36:54 +1000 To: ggi-develop@eskimo.com Subject: Re: Couple of naive questions Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Brian Julin on Tue, Jun 02, 1998 at 06:07:01PM -0400 Resent-Message-ID: <"glHR8.0.Wr2.FSDTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2460 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Brian writes: > 2) Is there a compact syntax way to do something like this: > > struct c { int a; > char b; > }; > > struct c d = { 5, 'f' }; > > ..... through a construct something like: > > struct c { int a = 5; char b = 'a' } Unfornately not. > 2a) Can you somehow syntactically nest structure definitions e.g. > > struct e { int a; struct g { int d; char e } b} Now that one is OK. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Tue Jun 2 22:14:39 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA22849; Tue, 2 Jun 1998 22:14:38 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id WAA00288; Tue, 2 Jun 1998 22:19:27 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 22:19:27 -0700 (PDT) Sender: injector@clubneon.dyn.ml.org Message-ID: <3574DC27.AEC9C676@stu.ac.cc.md.us> Date: Wed, 03 Jun 1998 01:16:23 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Tales of Magic ... References: <3574CDC4.541B7F54@ne.uswest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"oNPpn2.0.J4.SpDTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2461 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Phil Brutsche wrote: > > Edward S. Marshall wrote: > > Man, I hope someone is archiving these. Andreas, these inspirational posts > > of yours are too cool for words. :-) > I've been archiving this list since December or so on my computer, > so I can try to dig them out if anyone wants to see them. The last 6 months are on the website, and before that can be found gziped on the ftp site. -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Tue Jun 2 23:03:17 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA22891; Tue, 2 Jun 1998 23:03:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA03355; Tue, 2 Jun 1998 23:04:14 -0700 Resent-Date: Tue, 2 Jun 1998 23:04:14 -0700 Message-ID: <000901bd8ebd$b32d8570$0c0a0a0a@MASSACRE> From: "David Waite" To: Subject: Re: EvStack - slight move... Date: Wed, 3 Jun 1998 02:03:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0305.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0305.0 Resent-Message-ID: <"1_jlF3.0.Bq.RTETr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2462 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com ># insmod ggi-monitor-vga.o ># insmod ggi-monitor-Samsung17GLsi.o ># ># insmod ggi-display-S3.o display=0:vga,1:Samsung17GLsi ># insmod ggi-display-Matrox.o display=2:vga > Hmm... With the `display class' concept, we could (theortically) >create monitor classes where you can load their parameters >via /proc, ie: > ># echo "create-monitor 1" >/proc/evstack/class/monitor-vga ># cat </proc/evstack/monitor/1 >set horiz 50-60 >set vert 31.5,32,36-130 >EOF ># This is what I originally thought would be a good idea for monitors- eventually just pass the monitor parameters to the driver to get a monitor setting. I originally thought something like tacking on a monitor.info file dring insmod of the driver.. but now I see that this isn't the best idea. Something that would be of use is a way to change monitors on the fly, without rmmod'ing the driver. For instance, labtops could definately use this, for when they are jacked into a docking station/monitor. If a /proc interface is defined, what would be passed though? Would it need to supprt multisync /timelist /possibly DDC control? -David Waite From ggi-develop-request@eskimo.com Tue Jun 2 23:24:43 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA22934; Tue, 2 Jun 1998 23:24:42 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id XAA13169; Tue, 2 Jun 1998 23:24:51 -0700 (PDT) Resent-Date: Tue, 2 Jun 1998 23:24:51 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Unable to open default visual To: ggi-develop@eskimo.com Date: Wed, 3 Jun 1998 00:04:55 +0200 (MET DST) In-Reply-To: <199804071158.NAA11744@tokyo.e.kth.se> from "Marcus Sundberg" at Apr 7, 98 01:58:26 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"yPTIt2.0.UD3.hmETr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2463 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > > $ export LIBGGI_DISPLAY=kgi; Should enforce using kgi. > > > Forgive my nitpicking, but this just doesn't cut it. If libGGI isn't able > > > to communicate with the X server, it should assume it is not being run in > > > an X environment, ignore the DISPLAY variable, and go on to the next > > > target. > Ie, the driver lib gets unloaded if initialization fails, > thus this tiny patch should do what Nathan suggested: Thanks. Applied. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 3 03:39:05 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA23203; Wed, 3 Jun 1998 03:39:04 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA11979; Wed, 3 Jun 1998 03:33:53 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 03:33:53 -0700 (PDT) Message-ID: From: Paul Sargent To: "'ggi-develop@eskimo.com'" Subject: RE: Couple of naive questions Date: Wed, 3 Jun 1998 11:18:35 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uo7F7.0.2x2.EQITr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2465 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com LClk is normally Load Clk or Loop Clk. Basically it's the input that tells the RAMDAC when to latch data. For a 128bit DAC running at 32bpp, LClk will have a frequency of PClk / 4 (i.e. 4 pixels in each 128bit word.) Paul >-----Original Message----- >From: Brian Julin [SMTP:bri@forcade.calyx.net] >Sent: Tuesday, June 02, 1998 11:07 PM >To: ggi-develop@eskimo.com >Subject: Couple of naive questions > > > > >A couple things I feel like an amateur to have to ask, but >better to ask than remain ignorant: > >1) In the RAMDAC, what is lclk? pclk = pixel clock >(or dclock = dotclock) and mclk = memory clock, that much is obvious... >What's the "l" stand for? > >2) Is there a compact syntax way to do something like this: > >struct c { int a; > char b; > }; > >struct c d = { 5, 'f' }; > >... through a construct something like: > >struct c { int a = 5; char b = 'a' } > > >2a) Can you somehow syntactically nest structure definitions e.g. > >struct e { int a; struct g { int d; char e } b} > >... or am I just being a spoiled Perl5 brat? :) > >-- >Brian S. Julin > From ggi-develop-request@eskimo.com Wed Jun 3 04:24:26 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA23230; Wed, 3 Jun 1998 04:24:25 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA15127; Wed, 3 Jun 1998 04:19:08 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 04:19:08 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806031115.NAA27189@cip8.e-technik.uni-erlangen.de> Subject: Re: KGI license? To: mwfunk@uncc.campus.mci.net Date: Wed, 3 Jun 1998 13:15:50 +0200 (MESZ) Cc: ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: from "Michael Funk" at Jun 2, 98 11:13:17 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"OCl2j1.0.Ei3.g4JTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2466 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I am not in charge, and my opinion is in no way 'official', but if I recall correctly, this was resolved the following way: - drivers and software that is shipped together with some OS like the kernel interfaces, will have the same license the kernel has, i.e. GPL for Linux, BSD for *BSD. (My conclusion: for proprietary OSs, this must read: a license compatible with the OS license. Think BeOS.) This can mean that the basic VGA driver is under BSD license in the BSD tree and under GPL in the Linux tree, but this is seen as no problem. - add-ons that are distributed separately (like Permedia driver...) can have any license the author wants. - I am not sure about the kernel-independent parts (libggi*). GPL? Andy? > > Hopefully this isn't an inflammatory question to ask: was any decision > ever made regarding the licensing of KGI? A while back there was some > discussion of putting it under a non-copyleft license, so that other > free OS's (*BSD's, etc.) could use it without fear of 'tainting' their > kernels, as the GPL is inclined to do. > > I ask this now because it seems like if this is ever going to happen, > it needs to be done as soon as possible. It's my understanding that > a GPL'd piece of software can be relicensed only if all of the developers > agree to it. As time goes on, and the number of contributors increase, > this will become darned near impossible. If anyone has any intention > of 'freeing' KGI from the copyleft, so that it may be shared with others > while respecting their own licenses, it needs to be done ASAP. > > Mike > > Hartmut -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 3 04:51:44 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA23250; Wed, 3 Jun 1998 04:51:42 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA03938; Tue, 2 Jun 1998 15:07:16 -0700 Resent-Date: Tue, 2 Jun 1998 15:07:16 -0700 Date: Tue, 2 Jun 1998 18:07:01 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Couple of naive questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Ert7o1.0.Oz.IU7Tr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2451 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com A couple things I feel like an amateur to have to ask, but better to ask than remain ignorant: 1) In the RAMDAC, what is lclk? pclk = pixel clock (or dclock = dotclock) and mclk = memory clock, that much is obvious... What's the "l" stand for? 2) Is there a compact syntax way to do something like this: struct c { int a; char b; }; struct c d = { 5, 'f' }; ... through a construct something like: struct c { int a = 5; char b = 'a' } 2a) Can you somehow syntactically nest structure definitions e.g. struct e { int a; struct g { int d; char e } b} ... or am I just being a spoiled Perl5 brat? :) -- Brian S. Julin From ggi-develop-request@eskimo.com Wed Jun 3 04:52:35 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA23255; Wed, 3 Jun 1998 04:52:34 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA25434; Wed, 3 Jun 1998 04:52:53 -0700 Resent-Date: Wed, 3 Jun 1998 04:52:53 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806031151.NAA15810@sunserver1.rz.uni-duesseldorf.de> Subject: Re: Libggi shorty: internal state reporting -- my final comment. In-Reply-To: <199806031141.NAA27833@cip8.e-technik.uni-erlangen.de> from Hartmut Niemann at "Jun 3, 98 01:41:10 pm" To: niemann@cip.e-technik.uni-erlangen.de (Hartmut Niemann) Date: Wed, 3 Jun 1998 13:51:23 +0200 (MET DST) Cc: ggi-develop@eskimo.com, becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8BXkR3.0.CD6.IaJTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2467 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Topic 1.3 on my list: internal state reporting. > So I suggest to the Lord Of The Library: > - we will want some interface to the driver state > - this does not go into LibGGI. It is simply not needed widely enough > to justify adding this call to this library. > - as soon as need arises, some portable solution (some LibGGItweak) has > to be suggested, implemented and discussed. Hit the nail right on the head. This we will do. CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Wed Jun 3 05:24:21 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA23279; Wed, 3 Jun 1998 05:24:19 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA00342; Wed, 3 Jun 1998 05:27:52 -0700 Resent-Date: Wed, 3 Jun 1998 05:27:52 -0700 From: Hartmut Niemann Message-Id: <199806031141.NAA27833@cip8.e-technik.uni-erlangen.de> Subject: Re: Libggi shorty: internal state reporting -- my final comment. To: ggi-develop@eskimo.com Date: Wed, 3 Jun 1998 13:41:10 +0200 (MESZ) Cc: becka@sunserver1.rz.uni-duesseldorf.de (Andreas Beck) In-Reply-To: <199805260853.KAA19711@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at May 26, 98 10:53:10 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"5ijsd3.0.85.65KTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2468 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This was the request: > Topic 1.3 on my list: internal state reporting. > There is currently no way to communicate internal state information > (like the screen refresh rate, driver name and revision) to an application. > > Can we all agree on > - there is no *libggi* internal state worth reporting except for > debugging (where some DebugPrintf is the way to go). > Or is there any? > - there are driver-internal states worth reporting (screen refresh rate, > screen timing ...) but the high-level side of this reporting > should go into some libGGIinternalstate library? [1] > > Then I make the motion > -> not to enhance the Libggi API with state-reporting functions, at least > not for 1.5. > > I still want this reporting, but introducing yet another libggi function is > IMHO the wrong approach. > There was some very good discussion, and the most interesting points were: - There is no interesting libggi state. - The driver state (KGI state) is interesting to some diagnostic programs, but not to 'normal' applications. - a /proc/ or /dev/ggistat-based solution is not very portable, so it can not be the only choice. It would be handy for debugging though. (Think Windows here :-) There was only one remark in favor of putting this functionality into the libggi, and a valid one, that too many small libraries will be impractical, and that a larger lib is easier to handle. So I suggest to the Lord Of The Library: - we will want some interface to the driver state - this does not go into LibGGI. It is simply not needed widely enough to justify adding this call to this library. - as soon as need arises, some portable solution (some LibGGItweak) has to be suggested, implemented and discussed. Andy? Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 3 06:03:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA23318; Wed, 3 Jun 1998 06:03:40 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA25619; Wed, 3 Jun 1998 05:45:30 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 05:45:30 -0700 (PDT) From: Andrew Apted Message-ID: <19980603224052.46428@ajax.netspace.net.au> Date: Wed, 3 Jun 1998 22:40:52 +1000 To: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... Reply-To: ggi-develop@eskimo.com References: <199806022010.QAA04199@pepsi.visus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806022010.QAA04199@pepsi.visus.com>; from Jason McMullan on Tue, Jun 02, 1998 at 04:10:27PM -0400 Resent-Message-ID: <"Ytzzi.0.BG6.eLKTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2469 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jason McMullan writes: > Well, that's the bastard about the current KGI build scheme. > What we really need is some sort of `monitor class' that > you can insert first, then say for a system with a VGA > monitor on a S3, a Samsung Syncmaster GLsi 17" on another > S3 card, and another VGA monitor on a Matrix, you could: [SNIP] > Hmm... With the `display class' concept, we could (theortically) > create monitor classes where you can load their parameters > via /proc, ie: > > # echo "create-monitor 1" >/proc/evstack/class/monitor-vga > # cat </proc/evstack/monitor/1 > set horiz 50-60 > set vert 31.5,32,36-130 > EOF > # > > Any ideas? A monitor class sounds good. Monitor drivers are pretty small, so how about rolling the current three drivers into one generic driver, and have that permanently linked into the kernel ? Loading their parameters just as you've described (via /proc) is IMHO the best way. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Wed Jun 3 06:14:44 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA23324; Wed, 3 Jun 1998 06:14:43 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA00452; Wed, 3 Jun 1998 06:12:40 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 06:12:40 -0700 (PDT) Date: Wed, 3 Jun 1998 09:10:32 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: Libggi shorty: internal state reporting -- my final comment. In-Reply-To: <199806031151.NAA15810@sunserver1.rz.uni-duesseldorf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Oivvi.0.w6.3lKTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2470 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > > So I suggest to the Lord Of The Library: > > - we will want some interface to the driver state > > - this does not go into LibGGI. It is simply not needed widely enough > > to justify adding this call to this library. > > - as soon as need arises, some portable solution (some LibGGItweak) has > > to be suggested, implemented and discussed. > > Hit the nail right on the head. This we will do. Can we make it a shared page and use it for RT status as well? For example, we've discovered that the pentium cycle counter can be read from userspace, which will allow for a fast, non-context-switch implementation of ggiGetRayPos(), but only if the app has a relatively fresh formula to calculate the ray position from the cycle counter value, which depends on the kernel occasionally compensating for drift and changing the formula params for the app to use. -- Brian S. Julin From ggi-develop-request@eskimo.com Wed Jun 3 06:34:39 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA23333; Wed, 3 Jun 1998 06:34:37 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA04011; Wed, 3 Jun 1998 06:31:13 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 06:31:13 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806031328.PAA00138@cip8.e-technik.uni-erlangen.de> Subject: Re: irc session, take 2 To: andreas.beck@ggi-project.org Date: Wed, 3 Jun 1998 15:28:35 +0200 (MESZ) Cc: ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jun 1, 98 10:21:23 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"bP1461.0.Y-.U0LTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2471 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > > What about sunday june 7th at 5:00 PM MET (11:00 AM EST) ? > > > > Here we go again.. > > > > PST MST CST EST GMT+1 MET GMT+10 > > Sun Sun Sun Sun Sun Sun Mon > > 08:00A 09:00A 10:00A 11:00A 04:00P 05:00P 01:00A > > > Is that fine for everyone ? > Is that 5 PM *MET* or *MESZ*, i.e. 5 pm local time (which is daylight saving now, AFAIK :-). The websize says 3 PM GMT, this would be 5pm Mitteleuropaeische Sommerzeit, not Mitteleuropaeische Zeit. Or am i one hour off? Hartmut Emmanuel, are you going to open the irc server for testing earlier? I tried to connect today but failed. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 3 07:51:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA23433; Wed, 3 Jun 1998 07:51:35 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA19409; Wed, 3 Jun 1998 07:42:31 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 07:42:31 -0700 (PDT) X-Authentication-Warning: acc7.ac.cc.md.us: [208.214.13.87] didn't use HELO protocol Message-ID: <35758994.34F2@stu.ac.cc.md.us> Date: Wed, 03 Jun 1998 10:36:20 -0700 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: irc session, take 2 References: <199806031328.PAA00138@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KWDn2.0.wk4.53MTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2472 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > > > > > > > > What about sunday june 7th at 5:00 PM MET (11:00 AM EST) ? > > > > > > Here we go again.. > > > > > > PST MST CST EST GMT+1 MET GMT+10 > > > Sun Sun Sun Sun Sun Sun Mon > > > 08:00A 09:00A 10:00A 11:00A 04:00P 05:00P 01:00A > > > > > Is that fine for everyone ? > > > Is that 5 PM *MET* or *MESZ*, i.e. 5 pm local time (which is > daylight saving now, AFAIK :-). > > The websize says 3 PM GMT, this would be 5pm Mitteleuropaeische > Sommerzeit, not Mitteleuropaeische Zeit. Or am i one hour off? This could be my fault, or just the fault of Daylight Saving Time. I figured that if GMT+1 = 4PM then GMT would = 3PM, correct? Right now most states in the US are using Daylight Saving Time, so I listed the timezones as DT instead of ST. Where I am now, Maryland, is EDT which is GMT-4, and would be 11AM as seen above. So my question, not understanding your local time zone names, should it read MESZ instead of MET to make the 5PM correct? Anyway GMT+2 is 5PM. From ggi-develop-request@eskimo.com Wed Jun 3 08:53:14 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA23502; Wed, 3 Jun 1998 08:53:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA01542; Wed, 3 Jun 1998 08:41:31 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 08:41:31 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: EvStack - slight move... Date: 3 Jun 1998 15:43:16 GMT Organization: OnTV Pittsburgh, L.P. Lines: 23 Sender: Jason McMullan Distribution: local Message-ID: <6l3quk$2pr$3@butter.visus.com> References: <6l3hao$v9v$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"IBusE3.0.vN.cwMTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2473 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andrew Apted wrote with confidence: > A monitor class sounds good. Monitor drivers are pretty small, so how > about rolling the current three drivers into one generic driver, and > have that permanently linked into the kernel ? > Loading their parameters just as you've described (via /proc) is IMHO > the best way. [Aside] Brian, aren't you working on the new mode negotiation code? Why don't you get together with Andrew and see if the `generic monitor class' in-the-kernel option is a good one. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Wed Jun 3 09:15:04 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA23523; Wed, 3 Jun 1998 09:14:59 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA07419; Wed, 3 Jun 1998 09:09:27 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 09:09:27 -0700 (PDT) Date: Wed, 3 Jun 1998 12:07:09 -0400 (EDT) From: Brian Julin To: Jason McMullan cc: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... In-Reply-To: <199806031511.LAA13051@pepsi.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"MtxJ-2.0.gp1.oKNTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2474 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998, Jason McMullan wrote: > Sounds good - the idea I like best so far is to register > drivers as `classes' and use the /proc (or a /dev) interface > to register instances of those classes to form a head. I'm actually warming up to this idea. It should be thought through what this looks like on other OSes though, since the driver code needs to be reusable and thus should set up their "/proc" entry through kernel-driver functions that allow interchanging the backend implementation of the "runtime class interface". Also, I think we should not hardcode the subsystem classes, but rather just have a table that registers subsystems. Some displays may not really have a "monitor" at all, and some developer may want to add another subsystem category, like video capture or something. It also simplifies code like: while (cnt-- && !(cmd == CMD_READY)) { register int err; DEBUG1("check_mode:cmd=%i; cnt=%i", cmd, cnt); if ((err = kgim_clock_check_mode (dpy, mode, cmd))) { return err; } DEBUG1("check_mode: clock ok."); if ((err = kgim_ramdac_check_mode(dpy, mode, cmd))) { return err; } DEBUG1("check_mode: ramdac ok."); if ((err = kgim_chipset_check_mode(dpy, mode, cmd))) { return err; } DEBUG1("check_mode: chipset ok."); if (cmd == CMD_LOWER || cmd == CMD_RAISE) { if ((err = kgim_clock_check_mode(dpy, mode, cmd))) { return err; } DEBUG1("2nd clock check ok."); } if ((err = kgim_graphics_check_mode(dpy, mode, cmd))) { return err; } DEBUG1("check_mode: graphics ok."); if ((err = kgim_monitor_check_mode(dpy, mode, &cmd))) { return err; } DEBUG1("check_mode: monitor ok."); #if DEBUG_LEVEL > 0 printk_mode(mode, "mode:\n"); #endif } to something more along the lines of: curr_subsys = disp->head->subsystems while (curr_subsys) { if ((err = curr_subsys->check_mode(dpy, mode, &cmd)) { return err; } DEBUG("check_mode: %s ok.", curr_subsys->name); curr_subsys = curr_subsys->next; } To be fair though there is the sticky issue of what order the subsystems have to check/set modes, but I'm sure that can be resolved during subsystem registration in a satisfactory manner which may not be perfect, and would make the above a tiny bit more complex, but would be a heck of a lot more flexible. Steffen, are we asking too much for the timeline? -- Brian S. Julin From ggi-develop-request@eskimo.com Wed Jun 3 09:38:42 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA23618; Wed, 3 Jun 1998 09:38:36 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA00945; Wed, 3 Jun 1998 09:40:00 -0700 Resent-Date: Wed, 3 Jun 1998 09:40:00 -0700 Date: Wed, 3 Jun 1998 12:20:08 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... In-Reply-To: <6l3quk$2pr$3@butter.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ql5lt.0.dE.UnNTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2475 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On 3 Jun 1998, Jason McMullan wrote: > [Aside] Brian, aren't you working on the new mode negotiation > code? Why don't you get together with Andrew and see if the > `generic monitor class' in-the-kernel option is a good > one. Well, in general I think I'm about sold on the idea of ditching insmod parameters for a /proc/ interface if we can find a workable alternate on all potential KGI target OSes. As for "in-kernel", I think it should remain a loadable module just to keep things flexible -- why force someone who wants to just use VESA modes to load code for multisync negotiation? IMO all subsystem modules should be built if possible in such a way that they can support more than one occurance of their hardware attached to different displays, and be runtime configurable, which pretty much means the same thing -- you send in your monitor parameters to a generic monitor driver module. But still you might have monitors too simple or too complex for that "generic" monitor driver, so you should be able to load a different one, and load as many different simultaneous ones as you wish. Not to be redundant, but -- Steffen's call. P.S. please don't use a USENET mechanism to post to the list, not all of us are set up to reply that way. -- Brian S. Julin From ggi-develop-request@eskimo.com Wed Jun 3 11:38:31 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA23722; Wed, 3 Jun 1998 11:38:28 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA05355; Wed, 3 Jun 1998 11:36:46 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 11:36:46 -0700 (PDT) Date: Wed, 3 Jun 1998 14:34:34 -0400 (EDT) From: James A Simmons To: ggi-develop@eskimo.com Subject: Re: Unidentified subject! In-Reply-To: <19980603131627.01972@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"EtsKb2.0.ZJ1.yUPTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2476 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998, Andrew Apted wrote: > Emmanuel writes: > > > > Also I have yet to move the code from linux/drivers/console > > > to linux/drivers/video - I am reconsidering that.... > > > [fbcon is a mess...] > > > > Maybe an evstack subdirectory there? I agree, fbcon files aren't sorted > > much (and mixed with video4linux files, too). > > It's not that bad :-). All the low-level drivers are called '*fb.c', > all the framebuffer handlers are called 'fbcon-*.[ch]', and all the > abstract console drivers are called '*con.c'. That covers most of it. > [And video4linux is in drivers/char, just to pick nits :-)]. > > > Wherever the EvStack files are in the kernel tree, as long as they come > > in as an optional, portable patch, that's fine by most people standards. > > > > Hmm, does that mean we have to put a linux kernel tree on the CVS server > > as well (like at vger) ? Or will you just put patches there (like it is > > currently) ? > > Come to think of it, putting the EvStack code in drivers/video is a > really bad idea IMO. That really *would* make a mess. > > I was going to suggest using drivers/char, but that's pretty darn messy > now, let alone *after* putting EvStack in it :-). > Agree. That would be such a mess. Once fbcon is assimulated then we can take over video. > How about "drivers/evstack" ? There are nearly 30 sources files, so > having it's own directory would not be overkill, and it certainly makes > development easier (being able to symlink drivers/evstack -> wherever > the CVS snapshot is). > > Cheers, > _____________________________________________ ____ > \ / > Andrew Apted \/ > > From ggi-develop-request@eskimo.com Wed Jun 3 12:12:04 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA23740; Wed, 3 Jun 1998 12:12:02 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA10756; Wed, 3 Jun 1998 11:59:42 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 11:59:42 -0700 (PDT) Date: Wed, 3 Jun 1998 14:57:29 -0400 (EDT) From: James A Simmons To: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"iYYj-3.0.wd2.RqPTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2478 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > As for "in-kernel", I think it should remain a loadable module just > to keep things flexible -- why force someone who wants to just > use VESA modes to load code for multisync negotiation? I agree but the person compiling the kernel should have a chose to put this in the kernel or as a module. Some people might be funny about being forced to use a module. > > IMO all subsystem modules should be built if possible in such a way that > they can support more than one occurance of their hardware attached > to different displays, and be runtime configurable, which pretty > much means the same thing -- you send in your monitor parameters > to a generic monitor driver module. But still you might have > monitors too simple or too complex for that "generic" monitor driver, > so you should be able to load a different one, and load as many > different simultaneous ones as you wish. Agree. > > Not to be redundant, but -- Steffen's call. > > P.S. please don't use a USENET mechanism to post to the > list, not all of us are set up to reply that way. > > -- > Brian S. Julin > From ggi-develop-request@eskimo.com Wed Jun 3 13:05:09 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA23794; Wed, 3 Jun 1998 13:05:06 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA05028; Wed, 3 Jun 1998 13:05:00 -0700 Resent-Date: Wed, 3 Jun 1998 13:05:00 -0700 To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: KGI license? Date: 3 Jun 1998 15:48:19 GMT Organization: OnTV Pittsburgh, L.P. Lines: 36 Sender: Jason McMullan Distribution: local Message-ID: <6l3r83$2pr$4@butter.visus.com> References: <6l2ktb$l3f$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"SFI6B1.0.CE1.anQTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2479 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Michael Funk wrote with confidence: > Hopefully this isn't an inflammatory question to ask: was any decision > ever made regarding the licensing of KGI? A while back there was some > discussion of putting it under a non-copyleft license, so that other > free OS's (*BSD's, etc.) could use it without fear of 'tainting' their > kernels, as the GPL is inclined to do. The KGI Linux kernel patches should be GPL - with the provision that they can be modified for use with binary-only kernels [SCO, Solaris], but any changes to the files in drivers/console/* must be made public. The IBM vga driver (chipset, ramdac, etc), the libGGI vendor-IBM driver, and the VGA-fixed monitor driver should be BSD (or Public Domain) LibGGI (and all other libs we distribute) will be LGPL (modified if necessary to allow non-GPL plugins) Any disagreements with this? -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Wed Jun 3 13:24:51 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA23832; Wed, 3 Jun 1998 13:24:47 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA27998; Wed, 3 Jun 1998 13:22:04 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 13:22:04 -0700 (PDT) Date: Wed, 3 Jun 1998 16:19:48 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"AnpBy1.0.Gr6.e1RTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2481 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998, James A Simmons wrote: > > As for "in-kernel", I think it should remain a loadable module just > > to keep things flexible -- why force someone who wants to just > > use VESA modes to load code for multisync negotiation? > I agree but the person compiling the kernel should have a chose to put > this in the kernel or as a module. Some people might be funny about being > forced to use a module. Agreed... The FreeBSD group doesn't like modules at all for some reason. The change to this MO would actually ease the situation slightly, as there would no longer be an init_module() that did anything other than register the subsystem in a table, so you wouldn't have to override that function symbol, just compile in the table entry and the module functions. -- Brian S. Julin From ggi-develop-request@eskimo.com Wed Jun 3 14:19:56 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA23937; Wed, 3 Jun 1998 14:19:32 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA12079; Wed, 3 Jun 1998 14:18:50 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 14:18:50 -0700 (PDT) Message-Id: <199806031525.LAA08901@dew.wserv.com> From: "Jordan Mendelson" To: Subject: RE: irc session, take 2 Date: Wed, 3 Jun 1998 11:22:09 -0400 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <35758994.34F2@stu.ac.cc.md.us> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Resent-Message-ID: <"vTVMn.0.by2.tsRTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2482 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > > What about sunday june 7th at 5:00 PM MET (11:00 AM EST) ? > > > > > > > > Here we go again.. > > > > > > > > PST MST CST EST GMT+1 MET GMT+10 > > > > Sun Sun Sun Sun Sun Sun Mon > > > > 08:00A 09:00A 10:00A 11:00A 04:00P 05:00P 01:00A > > > > > > > Is that fine for everyone ? > > > > > Is that 5 PM *MET* or *MESZ*, i.e. 5 pm local time (which is > > daylight saving now, AFAIK :-). > > > > The websize says 3 PM GMT, this would be 5pm Mitteleuropaeische > > Sommerzeit, not Mitteleuropaeische Zeit. Or am i one hour off? > > This could be my fault, or just the fault of Daylight Saving Time. > > I figured that if GMT+1 = 4PM then GMT would = 3PM, correct? > > Right now most states in the US are using Daylight Saving Time, so I > listed the timezones as DT instead of ST. Where I am now, Maryland, is > EDT which is GMT-4, and would be 11AM as seen above. > > So my question, not understanding your local time zone names, should it > read MESZ instead of MET to make the 5PM correct? Anyway GMT+2 is 5PM. Please people, use GMT to set appointments. I can't make heads or tails out of all these funky localized times. Obviously, people outside the US won't know if we are in daylight [savings] time or standard time. (currently we are in daylight time). Plus, some parts of the US do not have daylight [savings] time (Arizona and what not). So please, use GMT... at least then we can all figure out exactly what time is when. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From ggi-develop-request@eskimo.com Wed Jun 3 14:23:27 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA23942; Wed, 3 Jun 1998 14:23:21 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA12389; Wed, 3 Jun 1998 14:20:07 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 14:20:07 -0700 (PDT) Message-Id: <199806031511.LAA13051@pepsi.visus.com> Subject: Re: EvStack - slight move... To: bri@forcade.calyx.net (Brian Julin) Date: Wed, 3 Jun 1998 11:11:34 -0400 (EDT) Cc: ggi-develop@eskimo.com Reply-To: jmcc@ontv.com In-Reply-To: from "Brian Julin" at Jun 3, 98 09:00:29 am From: Jason McMullan Content-Type: text Resent-Message-ID: <"9lkA63.0.R13.2uRTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2483 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com 'Brian Julin wrote with particular insight...' > I think allowing the modules to be loaded separately, and removed > and replaced, would be terrific. Steffen will have to decide whether > this can be done in a timely fashion though. IMO, modules should > be loaded separately and allowed to take their own insmod params; > the current system of funnelling it all through the kernel module > (which hardly anyone is obeying anyway) is cumbersome. If we > could load them in and then send an activate command to the kernel > module to tie them together and call their init() functions that > would be a good first step. IMO all modules should be ready to > support multiple displays, so you can, say, load one subsystem driver > and use it in combination with other sets of drivers for the other > subsystems. This involves not having overridable symbols but rather > doing things through jump tables; the subsystem's init functions proper > would do nothing but register their jump table entries in a central > kernel structure, and then the kernel would call a init_display > function for each display the module is to drive. Sounds good - the idea I like best so far is to register drivers as `classes' and use the /proc (or a /dev) interface to register instances of those classes to form a head. Ie: (timelist/S3 on head 0, multisync/S3 on head 1) # insmod monitor-timelist.o (/proc/evstack/monitor/timelist appears) # insmod monitor-multisync.o (/proc/evstack/monitor/multisync appears) # echo "set-spec horiz=31.5-135 vert=50-70" >/proc/evstack/monitor/multisync (set defaults for multisync) # insmod display-S3-virge.o (/proc/evstack/display/S3-virge appears) # Set up head 0 # echo "set-monitor head=0 class=timelist" >/proc/evstack/head/control (/proc/evstack/head/0 appears) # echo "set-spec horiz=31.5,35,45" >/proc/evstack/head/0/monitor (set up timelist instance) # echo "set-display head=0 class=S3-virge device=1" >/proc/evstack/head/control (attach the `second' S3-virge to head 0) # Set up head 1 # echo "set-monitor head=1 class=multisync" >/proc/evstack/head/control # echo "set-display head=1 class=S3-virge device=0" >/proc/evstack/head/control > I have a basic change to suggest for the mode negotiation KGI > interface as well, such that experimental systems will be easy to add > without changing the KGI interface; I am working on the > spec and some test code that implements the current system using it. > Hopefully Steffen will be OK with adding this before the KGI > interface is "frozen", otherwise we will pretty much be stuck > with any deficiencies in the "frozen" scheme. IHMO, KGI should be frozen in the interface to the kernel (include/ggi/kgi*.h), but the drivers/* internals should be re-workable. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Wed Jun 3 14:48:49 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA23959; Wed, 3 Jun 1998 14:48:42 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA19955; Wed, 3 Jun 1998 14:51:52 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 14:51:52 -0700 (PDT) Date: Wed, 3 Jun 1998 09:00:29 -0400 (EDT) From: Brian Julin To: Jason McMullan cc: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... In-Reply-To: <199806022010.QAA04199@pepsi.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"6hrRc.0.ct4.qLSTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2484 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 2 Jun 1998, Jason McMullan wrote: > Any ideas? I think allowing the modules to be loaded separately, and removed and replaced, would be terrific. Steffen will have to decide whether this can be done in a timely fashion though. IMO, modules should be loaded separately and allowed to take their own insmod params; the current system of funnelling it all through the kernel module (which hardly anyone is obeying anyway) is cumbersome. If we could load them in and then send an activate command to the kernel module to tie them together and call their init() functions that would be a good first step. IMO all modules should be ready to support multiple displays, so you can, say, load one subsystem driver and use it in combination with other sets of drivers for the other subsystems. This involves not having overridable symbols but rather doing things through jump tables; the subsystem's init functions proper would do nothing but register their jump table entries in a central kernel structure, and then the kernel would call a init_display function for each display the module is to drive. I have a basic change to suggest for the mode negotiation KGI interface as well, such that experimental systems will be easy to add without changing the KGI interface; I am working on the spec and some test code that implements the current system using it. Hopefully Steffen will be OK with adding this before the KGI interface is "frozen", otherwise we will pretty much be stuck with any deficiencies in the "frozen" scheme. -- Brian S. Julin From ggi-develop-request@eskimo.com Wed Jun 3 17:21:19 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA24121; Wed, 3 Jun 1998 17:21:17 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA27093; Wed, 3 Jun 1998 17:26:13 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 17:26:13 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806031547.RAA03037@cip8.e-technik.uni-erlangen.de> Subject: S3 864 anyone? To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Wed, 3 Jun 1998 17:47:26 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Ez36Y3.0.-c6.YcUTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2485 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Is anybody working on a driver for the 864? Is it technically very different from the 96x series? Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 3 19:00:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA24235; Wed, 3 Jun 1998 19:00:32 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA17728; Wed, 3 Jun 1998 18:59:08 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 18:59:08 -0700 (PDT) Date: Wed, 3 Jun 1998 00:48:41 +0200 (MEST) From: Jan Kneschke To: ggi-develop@eskimo.com Subject: mouse events in ggi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"uNBVd3.0.iK4.YzVTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2486 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com i just started the port synaesthesia to ggi. right now i have the output working (using DirectBuffer). now, i have to know how to get mouse events from ggi without using evstack. is there such a possibility ?? thats all Jan --- Project: GGI - S3-Vision-driver -- http://www.ggi-project.org/ -)= Jan (Weigon) Kneschke -- Kiel -- Northern Germany =(- From ggi-develop-request@eskimo.com Wed Jun 3 19:15:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA24270; Wed, 3 Jun 1998 19:15:44 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA22592; Wed, 3 Jun 1998 19:19:52 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 19:19:52 -0700 (PDT) Date: Wed, 3 Jun 1998 16:45:11 -0400 (EDT) From: Steve Cheng Sender: steve@maxt7m23.ipoline.com To: GGI Mailing List Subject: Re: KGI license? In-Reply-To: <6l3r83$2pr$4@butter.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"b_Ziu.0.oW5._GWTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2487 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On 3 Jun 1998, Jason McMullan wrote: > The KGI Linux kernel patches should be GPL - > with the provision that they can be modified for > use with binary-only kernels [SCO, Solaris], > but any changes to the files in drivers/console/* > must be made public. This defeats the purpose of GPL, doesn't it? GPL doesn't require the source to be "made public"; rather, the author must provide the source on the "medium customarily used for software interchange" or offer to provide the source under this medium along with the binary. The GPL also requires any other work based on the GPL'd work to be GPL itself. The linking the patches to the binary kernel is also considered to be a combined work; thus, the binary would also fall under the terms of the GPL unless excepted. This virus effect is integral to GPL because it helps promote free software. A provision that the patches can be modified for use with binary-only kernels (without GPL'ing the whole thing) is just too big a change, and is illogical and contrary to the main body of the license. I understand that the patches would need to be GPL because Linux is GPL'd, but what about a dual license? (like Perl's Artistic License) Besides, for non-GPL use[*], it seems logical to require permission for use with some other license instead of the GPL (e.g. same license as OS as Hartmut suggested). (Of course I don't have any official force on this issue, but this is my perception as an outsider.) [*] Remember, non-GPL doesn't always mean binary-only kernels. E.g. *BSD. // Steve e-mail: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Wed Jun 3 19:15:59 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA24275; Wed, 3 Jun 1998 19:15:53 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA22967; Wed, 3 Jun 1998 19:21:14 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 19:21:14 -0700 (PDT) Date: Wed, 3 Jun 1998 21:54:19 +0200 (CEST) From: Emmanuel Marty X-Sender: core@gate.local To: ggi-develop@eskimo.com Subject: CVS reopening schedule Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"F557x.0.Xc5.FIWTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2488 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello all, I think you will like the following news: I have, as announced, installed and put online a new server today where everything related to ggi-project.org (and others) will be moved. The CVS server is up and running on this machine as I write this. The following schedule will be held : Right now (wednesday evening my time), the CVS has no repository. Andy is going to create one by importing his ggi source tree there, where libggi and KGI are already split. Tomorrow at the same time, the repository will be setup, and I will open access to Jason McMullan, Hartmut Niemann and Steffen Seeger (if he's back from the USA) so that they can checkin the parts they handle (EvStack, documentation, preliminary KGI-degas). They will have 48 hours to get their files in the tree, deciding of the organization with Andy. Saturday evening my time, the tree they have setup will be cloned, forming the "stable" and "development" trees. The former will be maintained only by the people mentioned above and myself. The latter will be open to all developers who had CVS access before The Closure. Both trees will be open for anonymous cvs access too at the same time. It will work like this: everyone will work on the development tree. Then the 'finished' bits of it will carefully be picked and merged into the stable tree, on a regular basis (I propose every weekend ?). GGI applications developers who download the stable snapshot will have the guarantee to use something that compiles and works; while development is not hindered since anyone can checkin their work and experiments into the other tree. Snapshot generation for both trees, for people who can't checkout by anonymous CVS (if any) might be ready saturday as well. So, saturday, when CVS reopens for all, that leaves you about a day before the IRC session, to checkout from the new server, merge your changes into the development tree, and get your questions and ideas ready for the meeting. I hope this is fine for everyone? :) -- Emmanuel From ggi-develop-request@eskimo.com Wed Jun 3 19:21:09 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA24280; Wed, 3 Jun 1998 19:21:07 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA23026; Wed, 3 Jun 1998 19:21:39 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 19:21:39 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <3575B4EE.55603593@cistron.nl> Date: Wed, 03 Jun 1998 22:41:18 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: KGI license? References: <6l2ktb$l3f$1@butter.visus.com> <6l3r83$2pr$4@butter.visus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"MTZj53.0.bd5.WIWTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2489 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jason McMullan wrote: > > Michael Funk wrote with confidence: > > Hopefully this isn't an inflammatory question to ask: was any decision > > ever made regarding the licensing of KGI? A while back there was some > > discussion of putting it under a non-copyleft license, so that other > > free OS's (*BSD's, etc.) could use it without fear of 'tainting' their > > kernels, as the GPL is inclined to do. > > The KGI Linux kernel patches should be GPL - > with the provision that they can be modified for > use with binary-only kernels [SCO, Solaris], > but any changes to the files in drivers/console/* > must be made public. > > The IBM vga driver (chipset, ramdac, etc), > the libGGI vendor-IBM driver, and > the VGA-fixed monitor driver should be BSD (or Public Domain) > > LibGGI (and all other libs we distribute) will > be LGPL (modified if necessary to allow non-GPL > plugins) > > Any disagreements with this? A little. KGI should be say BSD (the simplified 2 clause license) so it can be used in all OS'es (or double license BSD/GPL). THis is only relevant for the base stuff that's needed for a KGI port. Libggi should be BSD, as this will be an essential component when *BSD has KGI. However, the extension libraries to the base libggi could be LGPL I think (just as long as XGGI can be run on a pure BSD license system, there will not be any concerns from the BSD'ers I think). Drivers should also be either simply BSD or double license (for the Cyrix driver permission is needed from Cyrix of course) We agreed on about this position a while back. Emmamuel, I haven't heard from you: did you start on OBSD-KGI? Otherwise I will do this as I have some time again to work on GGI. Wouter From ggi-develop-request@eskimo.com Wed Jun 3 19:22:14 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA24285; Wed, 3 Jun 1998 19:22:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA23176; Wed, 3 Jun 1998 19:22:07 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 19:22:07 -0700 (PDT) Message-ID: <810CCC6435ADD1119E640060085BED6A15DD95@NT_FS1> From: Brian Hurt To: "'ggi-develop@eskimo.com'" Subject: RE: Use of shared pages/SYSV SHMs Date: Wed, 3 Jun 1998 15:42:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Resent-Message-ID: <"2TCg83.0.wf5.2JWTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2490 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wednesday, June 03, 1998 10:38 AM, Brian Julin [SMTP:bri@forcade.calyx.net] wrote: > > > > How does the use of SYSV SHMs or other shared page mechanisms > for a kernel<->userspace interface shake out on various > architectures/OSs? It strikes me that these are the most generic > form of interface we have (and also the handiest in a lot of ways) > since, barring the initial aquisition of the SHM, it's just a > pointer to a page (or more) of memory. I'm not involved (currently) in active GGI development, but I do write device drivers as my day job. The biggest problem with all the SYSV IPCs are that they tend have extreme system-wide and per-processor limitations. mmaps() work better. The best and most generic way to share memory between two processes is to have both processes mmap the same file. You can also share memory between a driver and a process by mmaps. > > Not only can SHMs transmit any information an IOCTL can, but they > can be updated by the kernel at any time and don't have to wait > for a user request, which means when SHMs are available user > requests sometimes won't have to go into kernel space, especially > in ASYNC mode with a command cache arrangement. Ping-pong > buffers are IMO an inferior form of command cache since they _have_ > to be submitted rather than being optionally submitted, perhaps > to be processed during another kernel<->user transition rather than > forcing one to occur just to flush the command cache (though they > are a clever innovation, to be fair). You have now introduced synchronization problems, which ioctls() avoid (or can deal with much easier). There is no good, fast, portable way to synchronize between a driver and multiple processes, or even between multiple processes that I know of. Unless you're dealing with large amounts of data accesses often, you're not going to be gaining much. Perhaps a better solution would be to register for the driver/controlling process to signal the current process when the information changes- allowing the process to cache the information with confidence that it hasn't changed. But even that is probably over-engineering. ioctl()s just aren't that slow. YMMV, as always. From ggi-develop-request@eskimo.com Wed Jun 3 19:36:32 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA24311; Wed, 3 Jun 1998 19:36:28 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA02325; Wed, 3 Jun 1998 19:35:08 -0700 Resent-Date: Wed, 3 Jun 1998 19:35:08 -0700 Date: Wed, 3 Jun 1998 19:34:02 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: S3 864 anyone? In-Reply-To: <199806031547.RAA03037@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"GABgG1.0.nZ.IVWTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2491 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998, Hartmut Niemann wrote: > Is anybody working on a driver for the 864? > Is it technically very different from the 96x series? vgadoc says it is exactly the same as a 964 but with max 4MB DRAM instead of 8MB. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Wed Jun 3 19:53:16 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA24351; Wed, 3 Jun 1998 19:53:07 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA29174; Wed, 3 Jun 1998 19:45:20 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 19:45:20 -0700 (PDT) Date: Wed, 3 Jun 1998 13:18:07 -0700 (PDT) From: KC5TJA To: Jason McMullan cc: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <6l3r83$2pr$4@butter.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ZlbUw2.0.X77.jeWTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2492 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > The IBM vga driver (chipset, ramdac, etc), > the libGGI vendor-IBM driver, and > the VGA-fixed monitor driver should be BSD (or Public Domain) HIGHLY AGREED. This sort of thing should be made as public as possible, as it helps foster development for your platform. Want to support a new video card? Use the VGA driver as a starting point... :) Then make the modifications necessary. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Wed Jun 3 20:23:15 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA24379; Wed, 3 Jun 1998 20:23:11 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id UAA10725; Wed, 3 Jun 1998 20:29:18 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 20:29:18 -0700 (PDT) From: Andrew Apted Message-ID: <19980604132421.41454@ajax.netspace.net.au> Date: Thu, 4 Jun 1998 13:24:21 +1000 To: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Brian Julin on Wed, Jun 03, 1998 at 04:19:48PM -0400 Resent-Message-ID: <"BhEt.0.Cd2.5IXTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2493 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Brian writes: > > > As for "in-kernel", I think it should remain a loadable module just > > > to keep things flexible -- why force someone who wants to just > > > use VESA modes to load code for multisync negotiation? > > I agree but the person compiling the kernel should have a chose to put > > this in the kernel or as a module. Some people might be funny about being > > forced to use a module. > > Agreed... Me too. In menuconfig it could look something like this: Monitor Drivers < > Timelist support (CONFIG_MONITOR_TIMELIST) < > Multisync support (CONFIG_MONITOR_MULTISYNC) < > VESA modes support (CONFIG_MONITOR_VESA) And basic monitor support (i.e. monosync) would always be compiled in (being so simple and small). Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Wed Jun 3 21:32:51 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA24427; Wed, 3 Jun 1998 21:32:47 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA25949; Wed, 3 Jun 1998 21:31:49 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 21:31:49 -0700 (PDT) Date: Wed, 3 Jun 1998 23:04:49 +0200 (CEST) From: Emmanuel Marty X-Sender: core@gate.local To: ggi-develop@eskimo.com Subject: IRC session sunday Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"MEA-23.0.GL6.kCYTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2494 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello, Okay, just to set things straight: the meeting will start at 5 PM of my time, which means 5 PM in France, Germany, etc. That means 3 PM GMT, on sunday. Hartmut: sorry, you tried to connect to the irc server _right_ during the downtime of about an hour I had today, for our server room electrical upgrade :-) It will work now. If there was any problem, I will be logged on there about half an hour before the meeting starts, and I will be on Undernet (in channel #linux) as well, for the paranoid case the server was down or something. All good now? :) -- Emmanuel From ggi-develop-request@eskimo.com Wed Jun 3 21:46:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA24435; Wed, 3 Jun 1998 21:46:39 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA00661; Wed, 3 Jun 1998 21:51:31 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 21:51:31 -0700 (PDT) Date: Wed, 3 Jun 1998 22:47:34 -0400 (EDT) From: Brian Julin To: Colin Plumb cc: ggi-develop@eskimo.com Subject: Re: Using RDTSC for ggiGetRayPos() In-Reply-To: <199806040043.SAA02541@nyx10.nyx.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"NDg3C.0.BA.HVYTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2496 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998, Colin Plumb wrote: > Brian Julin suggested: > > Can we make it a shared page and use it for RT status as well? > > For example, we've discovered that the pentium cycle counter can be > > read from userspace, which will allow for a fast, non-context-switch > > implementation of ggiGetRayPos(), but only if the app has a > > relatively fresh formula to calculate the ray position from the > > cycle counter value, which depends on the kernel occasionally > > compensating for drift and changing the formula params for the app > > to use. > > Um, this is going to die horribly on laptops. I'm trying to write a good > gettimeofday() for Linux, and it's complicated by the fact that systems > like APM slow down the processor clock whenever the system is idle. > This usually affects the TSC as well, resulting in it having a poor > correlation with wall-clock time. Thanks for the information (very useful.) Still, I'd assert shared memory is the way to go -- take a look at ping-pong buffers. These mostly already use shared memory but they could use it better IMO. Currently the application writes in a page until it is full, then segfaults on a second page -- the kernel empties the page that was full during the segfault and maps it out. The app continues writing in the second page, which is mapped in. However, if the "protocol" were changed to simply use one area, the app could write and simply check a counter in the area that says the last location that the kernel has processed up to, so as not to overwrite unused data. Every time the app writes, it increments a second counter that tells the kernel how much new data is in the page. Instead of segfaulting chunks the app can call an ioctl. In the meantime, the kernel could be reading/emptying the page whenever it finds itself in kernel space for whatever reason -- maybe as a periodic realtime or IRQ driven task or maybe just as a tack-on to in-kernel evstack processing; whatever works best. Of course there are issues to be resolved -- make it thread and SMP safe on both the user and kernel-space sides and shut down kernel processing on that particular page when the app loses VC focus. Above my head admittedly, but that would be the most flexible way to go about it. > Now something similar could be used with ggiGetRayPos(), but that > would entail exporting this whole mess, which has hooks deep in the > Linux scheduler and wouldn't be particularly portable. Use of a read-only SHM might help you too -- keep status in the SHM and any app can find it via it's cookie. The status would read as the value of the cycle counter when the accuracy was last determined, and the accuracy at that point. Thus an app would know roughly how reliable the value is, and could use a call of "getroughtimeofday" to get a possibly errored result, but know what the error limits are. This would possibly be more desireable for many apps than having to wait for a context switch. You didn't mention back-calibrating the cycle counter with the timer tick so you know the rate it increases while power saving, why? Does it vary? Also, we are in a bind with non-RT linux on 386s, as we need to make a periodic task possibly at a rather fast frequency if crummy video cards are being used. This screws with the scheduler like the PC speaker sound driver does. Wasteful, but you suffer if you use obselete equipment, I guess... there's no other way to do it that I can think of. Thanks again. -- Brian S. Julin From ggi-develop-request@eskimo.com Wed Jun 3 21:48:45 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA24440; Wed, 3 Jun 1998 21:48:43 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA29203; Wed, 3 Jun 1998 21:48:22 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 21:48:22 -0700 (PDT) Date: Wed, 3 Jun 1998 23:10:06 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: RE: Use of shared pages/SYSV SHMs In-Reply-To: <810CCC6435ADD1119E640060085BED6A15DD95@NT_FS1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"jEFoL3.0.587.FSYTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2495 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998, Brian Hurt wrote: > I'm not involved (currently) in active GGI development, but I do write > device drivers as my day job. The biggest problem with all the SYSV > IPCs are that they tend have extreme system-wide and per-processor > limitations. mmaps() work better. The best and most generic way to > share memory between two processes is to have both processes mmap > the same file. You can also share memory between a driver and a > process by mmaps. I'm only really attracted to SYSV SHMs over MMAPs because they would be easily locatable through the SYSV IPC protocols. If they are resource limited, MMAPs will do; they are just a little more cumbersome to set up. > You have now introduced synchronization problems, which ioctls() > avoid (or can deal with much easier). There is no good, fast, portable > way to synchronize between a driver and multiple processes, or > even between multiple processes that I know of. My main problem with the IOCTLs are they aren't particularly flexible, and they _always_ cause a context switch. I can't speak to what SMP/thread/multiprocess syncronization problems there will be -- but probably they will be mostly surmountable. We'll probably not have multiple opens for graphics devices for a while, but we should pick an API than will be useful when we do get around to engineering this. I could see IOCTLs causing a lot of contention between processes because of the blocking behavior. Most of this data isn't real-time "syncronized", just needs proper contention handling. Only the vretrace stuff needs real-time attention, and then only when there isn't good support in the hardware for the desired functionality (old graphics adaptors on a 386 may be our worst case scenario, if other architectures don't have horrors in store for us in this area,) so we avoid needing complex stuff when possible. > Unless you're dealing with large amounts of data accesses often, > you're not going to be gaining much. I think a realtime graphics task like animation qualifies for "large amounts of data accesses often". Thanks for the comments -- if you find time to look at the KGI structure and offer comments, please please do so :). We need some experienced thought in this area. Thanks a bunch. -- Brian S. Julin From ggi-develop-request@eskimo.com Wed Jun 3 23:07:22 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA24502; Wed, 3 Jun 1998 23:07:20 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id XAA17843; Wed, 3 Jun 1998 23:10:17 -0700 (PDT) Resent-Date: Wed, 3 Jun 1998 23:10:17 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: EvStack-0.4.tar.gz Date: 4 Jun 1998 06:07:55 GMT Organization: OnTV Pittsburgh, L.P. Lines: 14 Sender: Jason McMullan Message-ID: <6l5djr$ojg$2@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"NS95v2.0.dM4.6fZTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2497 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Oh - and there's no diff availible because the diff was larger than the archive - it's now down to ~400k Sleep.. must get sleep.. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Wed Jun 3 23:08:42 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA24507; Wed, 3 Jun 1998 23:08:40 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA20450; Wed, 3 Jun 1998 23:10:11 -0700 Resent-Date: Wed, 3 Jun 1998 23:10:11 -0700 From: Andrew Apted Message-ID: <19980604133537.52715@ajax.netspace.net.au> Date: Thu, 4 Jun 1998 13:35:37 +1000 To: ggi-develop@eskimo.com Subject: Re: mouse events in ggi Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Jan Kneschke on Wed, Jun 03, 1998 at 12:48:41AM +0200 Resent-Message-ID: <"5Zpyy3.0.F_4.1fZTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2498 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jan Kneschke writes: > i just started the port synaesthesia to ggi. right now i have the output > working (using DirectBuffer). now, i have to know how to get mouse events > from ggi without using evstack. is there such a possibility ?? Just use ggiEventPoll(vis, emPointer, &timeval) to check for any mouse events, and ggiEventRead(vis, &ggi_event, emPointer) to get the events. For example: ... // handle any input events for (;;) { ggi_event ev; struct timeval tv; tv.tv_sec = 0; tv.tv_usec = 50000; if (! ggiEventPoll(the_vis, emPointer, &tv)) { // no events were received break; } ggiEventRead(the_vis, &ev, emPointer); if (ev.any.type == evPtrRelative) { mouse_abs_x += ev.pmove.x; mouse_abs_y -= ev.pmove.y; } else if (ev.any.type == evPtrAbsolute) { mouse_abs_x = ev.pmove.x; mouse_abs_y = ev.pmove.x; } if (ev.any.type == evPtrButtonPress) { do_press(ev.pbutton.button); } else if (ev.any.type == evPtrButtonRelease) { do_release(ev.pbutton.button); } } Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Wed Jun 3 23:09:19 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA24512; Wed, 3 Jun 1998 23:09:18 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA20464; Wed, 3 Jun 1998 23:10:13 -0700 Resent-Date: Wed, 3 Jun 1998 23:10:13 -0700 From: Andrew Apted Message-ID: <19980604134841.30684@ajax.netspace.net.au> Date: Thu, 4 Jun 1998 13:48:41 +1000 To: ggi-develop@eskimo.com Subject: Re: KGI license? Reply-To: ggi-develop@eskimo.com References: <6l2ktb$l3f$1@butter.visus.com> <6l3r83$2pr$4@butter.visus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <6l3r83$2pr$4@butter.visus.com>; from Jason McMullan on Wed, Jun 03, 1998 at 03:48:19PM +0000 Resent-Message-ID: <"dZObA.0.P_4.1fZTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2499 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jason writes: > LibGGI (and all other libs we distribute) will > be LGPL YES ! > (modified if necessary to allow non-GPL plugins) Not necessary. The plugins are dynamically loaded, so there's no problem. (Just like non-GPL modules can be used on Linux). The only thing would be to distribute non-LGPL plugin code separately from the main LibGGI code. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Wed Jun 3 23:22:14 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA24517; Wed, 3 Jun 1998 23:22:13 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA27446; Wed, 3 Jun 1998 23:27:52 -0700 Resent-Date: Wed, 3 Jun 1998 23:27:52 -0700 To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: EvStack-0.4.tar.gz Date: 4 Jun 1998 06:06:43 GMT Organization: OnTV Pittsburgh, L.P. Lines: 17 Sender: Jason McMullan Message-ID: <6l5dhj$ojg$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"hhs5j.0.Pi6.avZTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2500 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com It's the Amazing Shrinking EvStack! I've trimmed out all the drivers that didn't work and the libGGI documentation, and added the patch for Linux 2.1.103 (and took out the old stale one) The VGA driver got borken in the process (the full driver - the build-in boot driver still works fine.) I'm too sleepy to debug it right now.... -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Thu Jun 4 00:45:27 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA24579; Thu, 4 Jun 1998 00:45:23 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA05611; Thu, 4 Jun 1998 00:36:57 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 00:36:57 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: mouse events in ggi Date: 4 Jun 1998 03:06:59 GMT Organization: OnTV Pittsburgh, L.P. Lines: 19 Sender: Jason McMullan Distribution: local Message-ID: <6l530j$ji7$2@butter.visus.com> References: <6l508o$imk$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"vs5VT3.0.XN1.BwaTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2501 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jan Kneschke wrote with confidence: > i just started the port synaesthesia to ggi. right now i have the output > working (using DirectBuffer). now, i have to know how to get mouse events > from ggi without using evstack. is there such a possibility ?? Yes - just use the libGGI Event* (Poll/Read/etc) functions (think of them alot like select() and read() with an event filtering mask) - this should work on all libGGI targets (X, KGI, SVGAlib, etc.) -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Thu Jun 4 01:22:54 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA24644; Thu, 4 Jun 1998 01:22:51 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA17733; Thu, 4 Jun 1998 01:20:10 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 01:20:10 -0700 (PDT) Date: Thu, 4 Jun 1998 18:37:18 -0700 (MST) From: teunis To: GGI Developers Subject: I'm back - did I miss anything? :) [message priority=noise] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"gQvgo3.0.rK4.rYbTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2502 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hiya - just following this news on EvStack about to be released *grin* Anybody having probs with S3 ViRGE driver? Last I heard everything was working pretty decently (it is here :) Am looking forward (muchly) to re-porting the driver into EvStack :) No other news here... G'day, eh? :) - Teunis Incidentally, I'm now at computersupportcentre.com though (afaik) mauve.computersupportcentre.com is still valid.... (we lost our ISP so we switched but the old ISP refused to allow us our domain back... we've got it back now) From ggi-develop-request@eskimo.com Thu Jun 4 01:28:04 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA24663; Thu, 4 Jun 1998 01:28:03 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA02325; Wed, 3 Jun 1998 19:35:08 -0700 Resent-Date: Wed, 3 Jun 1998 19:35:08 -0700 Date: Wed, 3 Jun 1998 19:34:02 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: S3 864 anyone? In-Reply-To: <199806031547.RAA03037@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"GABgG1.0.nZ.IVWTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2491 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998, Hartmut Niemann wrote: > Is anybody working on a driver for the 864? > Is it technically very different from the 96x series? vgadoc says it is exactly the same as a 964 but with max 4MB DRAM instead of 8MB. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Thu Jun 4 02:00:10 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA24698; Thu, 4 Jun 1998 02:00:04 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA20767; Thu, 4 Jun 1998 01:45:48 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 01:45:48 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806040838.KAA23950@cip8.e-technik.uni-erlangen.de> Subject: libggi: palettes To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Thu, 4 Jun 1998 10:38:36 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Kutd8.0.M45.wwbTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2503 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! One more in the API refining series: The pallette (color lookup table, CLUT). There are several areas, where our specification is vague: 1) The only way to detect whether there is a platte or not is to try to set it or to read the first value and check whether that fails. Do we want to leave and document this this way? Say 'yes'. One consequence is that the target that implements SetPalette MUST implement GetPalette as well. So either both will fail or none. Side note: if we document that ggi[PG]etPalette returns some GGI_OK without doing anything for len==0, if a palette is present, then this wouldn't even need dummy variables. if (ggiGetPaletteVec(vis,0,0,NULL)==GGI_OK){ /* we got a palette! */ } else { /* getting the palette entry failed */ } 2) The size of the palette can be determined by the bits-per-pixel value ONLY, which is only part of the directbuffer API. The ggi_graphtype contains this information, 'cypted', too. So we could document the macro in internal.h: #define VIS_FB_BPP(vis) (vis->info.fb.bpp) as 'the' one option to determine the bpp value of the display, or define some macro/function that returns the bpp from the graphtype. my favourite: unsigned int ggiVisualBpp(vis). IMHO an application should be able to find out whether it runs on black-and-white, 16, 256 or >30000 colours. 3) The hardest part: Do we want to guarantee the palette to contain anything on start? On the one hand it would simplify some applications that don't care too much, if one can assume that there is a reasonable default that contains (e.g.) at least the 8 basic colours in two shades each. for X it would be best not to mess too much with the palette (bad flicklering), but if you put a 2:2:2 color cube (as opposed to the 3:3:2 cube used currently) into the last 64 elements of the standard palette, this would improve things a lot because the main colours of the display (background, borders ...) wouldn't change every time you activate the GGI window. There were many voices that said: no default at all, but I would like to propose that the palette is guaranteed to have at least white, black, green, blue, red, yellow, magenta, cyan So that small applications don't need to set it, if all they do is a red border around white text on black background. 4) An idea popped into my mind, when collecting this: Currently we specify the s parameter to define where to load values. WHat about this: If you specify s==GGI_AUTO, the target will itself choose a place in the palette for you. Reason: If you know at program startup, that you will need n different colours, you set these n colours in the palette and don't care where. Only very few programs will set the palette more than once AND want to retain old values. For a windowing environment it could very well make sense to assign positions 0 to 20 to the window manager, 30 to 100 to app1, and 101 to 200 to app2. So if we leave this assignment to the library, it *might* help. And if someone doesnt want to implement fancy strategies, if (s==GGI_AUTO) s=0; is all enhancements necessary. Comments? Hartmut. Let's document it that way? -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Thu Jun 4 02:12:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA24712; Thu, 4 Jun 1998 02:12:50 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id CAA14175; Thu, 4 Jun 1998 02:07:41 -0700 Resent-Date: Thu, 4 Jun 1998 02:07:41 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3576518D.87C8570D@ebc.ericsson.se> Date: Thu, 04 Jun 1998 09:49:33 +0200 From: Marcus Sundberg Reply-To: e94_msu@e.kth.se X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: mouse events in ggi References: <19980604133537.52715@ajax.netspace.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Yc9LG1.0.tS3.JFcTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2505 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jan Kneschke writes: > i just started the port synaesthesia to ggi. right now i have the output > working (using DirectBuffer). now, i have to know how to get mouse events > from ggi without using evstack. is there such a possibility ?? Hmmmm... I have already ported synaesthesia to GGI. Get ggisyna from http://www.stacken.kth.se/~mackan/ggi/ My port is based on synaesthesia 1.2, and I know that synaesthesia 1.3 has been out for a few months. If you want to port 1.3 to GGI I syggest you use ggisyna as a base and incorporate the changes in it. The original synaesthesia is a horrible mess of mixed C and C++, while ggisyna is pure and well modularised C. //Marcus From ggi-develop-request@eskimo.com Thu Jun 4 02:19:13 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA24719; Thu, 4 Jun 1998 02:19:12 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id CAA13862; Thu, 4 Jun 1998 02:06:59 -0700 Resent-Date: Thu, 4 Jun 1998 02:06:59 -0700 Date: Thu, 4 Jun 1998 00:47:01 -0700 (PDT) From: Nathan X-Sender: gblues@gblues To: ggi-develop@eskimo.com Subject: Re: Couple of naive questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"PxpM91.0.zN3.iEcTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2504 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 2 Jun 1998, Brian Julin wrote: > 2) Is there a compact syntax way to do something like this: > > struct c { int a; > char b; > }; > > struct c d = { 5, 'f' }; > > ... through a construct something like: > > struct c { int a = 5; char b = 'a' } how about: struct foo {int a; char b;} bar = { 5, 'a' }; That should work. > 2a) Can you somehow syntactically nest structure definitions e.g. I don't think so. You have to declare the nested structures first, then you can use them inside other structures, I believe. > ... or am I just being a spoiled Perl5 brat? :) Perl5 kicks butt =) Nathan gblues@jps.net From ggi-develop-request@eskimo.com Thu Jun 4 02:21:42 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA24727; Thu, 4 Jun 1998 02:21:40 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id VAA11694; Tue, 2 Jun 1998 21:54:52 -0700 Resent-Date: Tue, 2 Jun 1998 21:54:52 -0700 From: Andrew Apted Message-ID: <19980603123654.10913@ajax.netspace.net.au> Date: Wed, 3 Jun 1998 12:36:54 +1000 To: ggi-develop@eskimo.com Subject: Re: Couple of naive questions Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Brian Julin on Tue, Jun 02, 1998 at 06:07:01PM -0400 Resent-Message-ID: <"glHR8.0.Wr2.FSDTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2460 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Brian writes: > 2) Is there a compact syntax way to do something like this: > > struct c { int a; > char b; > }; > > struct c d = { 5, 'f' }; > > ..... through a construct something like: > > struct c { int a = 5; char b = 'a' } Unfornately not. > 2a) Can you somehow syntactically nest structure definitions e.g. > > struct e { int a; struct g { int d; char e } b} Now that one is OK. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Thu Jun 4 02:29:05 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA24746; Thu, 4 Jun 1998 02:29:04 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id CAA21329; Thu, 4 Jun 1998 02:23:43 -0700 Resent-Date: Thu, 4 Jun 1998 02:23:43 -0700 From: Hartmut Niemann Message-Id: <199806040923.LAA24784@cip8.e-technik.uni-erlangen.de> Subject: Re: Libggi Issues round two is open! -- my final word To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Thu, 4 Jun 1998 11:23:46 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8cboP1.0.9D5.SUcTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2506 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This is my final proposal after the long ggiPuts discussion. It was heated, it was a good discussion, but I must admit I am hard to convice :-) > > > (chapters 1.12 ggiPuts wrapping and 1.14 Character size reporting) > > > > > > This call (ggiPut*) is meant as a very simple method of displaying text. > > > > > > Is there complete agreement about the fact that ggiPuts should work > > > in text mode AND in graphics mode? I hope so. Everybody said this. ggiPuts will be documented to work in text mode AND in graphic mode. > > > The first question that arose is, what to do with too long lines. > > > Cut or wrap? > > CUT seems to be the way to go. Mentalguy said: > > 1. ggiPuts() always draws the characters in a single line; formatting > characters like tab, newline, etc. are not treated specially Only \000 is treated specially: end of string. But that's C :-) > 2. text is always clipped by the clipping region (of course) > 3. if the text origin specified to ggiPuts() is outside the visual's > clipping area (in any direction), the text is displayed anyway, clipped > properly. > > The reasoning here is that if ggiPuts(), being the most basic function for > drawing text strings, wraps, or decides not to print text based on the > location of the origin, it's very difficult to get un-wrapped or otherwise > simpler behavior at a higher level. However, if ggiPuts() behaves in the > most simplistic, consistent manner possible, implementing wrapping or other > functionality at a higher level is relatively easy. I second this and want to make this documented behaviour. > > > > The second question is how to determine the size of the letters in pixels, > > > which is currently 1x1 in text mode (does it work, BTW?), and > > > 8x8 in graphics mode. We have the choice between fixing these values > > > (and providing some means to determine portably whether a mode is > > > graphical) or adding a function for querying the character cell size. > > There was a heated discussion about this. My proposal goes like this: - there is a function to query the char cell size: ggi_error ggiGetCharCellSize(vis, int * width, int * height); please remember that the char cell size is not a *mode* property, except for text mode, where it is 1x1 by definition! - The font is guaranteed to be at least 8x8 (fixed for all chars) and nobody is encouraged to implement something bigger, except for good (hardware) reasons. Once again, the ggiPuts implementation is dependent on the frame buffer layout, not on it's *size*. If you want to allow loading different fonts, you need a device independent format to specify the font data, fall back methods for strange hardware, different implementations for text and graphics and all kinds of rubbish, which is why I suggest: - ggiPuts is going to use iso-8859-1 (latin1) charset. It will not support unicode, will not support loading different charsets. But if one implementation does not support full iso-8859-1 but does support ASCII 0x20-0x7e (which is a subset if iso, isn't it?), then this is regarded a class 99 bug (i.e. document it, but no hurry fixing it.) - ggiPuts will not support loadable hardware charsets. This is VGA-centric anyway and of limited use, and shouldn't go into the base library. A libggitext is the right place for these functions, as it is for loadable fonts in general. This is MHO and a proposal only. Now I pass the word to the Master Of The API. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Thu Jun 4 03:39:28 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA24850; Thu, 4 Jun 1998 03:39:25 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA02273; Thu, 4 Jun 1998 03:14:24 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 03:14:24 -0700 (PDT) X-Authentication-Warning: tingeling.lysator.liu.se: mars owned process doing -bs Date: Thu, 4 Jun 1998 12:12:02 +0200 (MET DST) From: Stefan Mars To: Hartmut Niemann cc: ggi Mailingliste Subject: Re: libggi: palettes In-Reply-To: <199806040838.KAA23950@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"6DNDu.0.PZ.zDdTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2507 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > 1) The only way to detect whether there is a platte or not is > to try to set it or to read the first value and check whether that fails. > Do we want to leave and document this this way? Say 'yes'. No way. It's always a good idea to have functions that set something, return a value that tells us how it went. > One consequence is that the target that implements SetPalette > MUST implement GetPalette as well. So either both will fail or none. Can't we document that a valid target must implement GetPalette anyway? > Side note: if we document that ggi[PG]etPalette returns some GGI_OK without > doing anything for len==0, if a palette is present, then this > wouldn't even need dummy variables. Stupid question: What a PetPalette? *grin* > 2) The size of the palette can be determined by the bits-per-pixel value > ONLY, which is only part of the directbuffer API. > The ggi_graphtype contains this information, 'cypted', too. > So we could document the macro in internal.h: > > #define VIS_FB_BPP(vis) (vis->info.fb.bpp) > > as 'the' one option to determine the bpp value of the display, > or define some macro/function that returns the bpp from the graphtype. > > my favourite: unsigned int ggiVisualBpp(vis). I prefer a function actually. It makes more sense to me, because a program should interact with the environment using an API, not by having to look into the various structures that ought to be internal to the API. An API call usually also makes the code more readable. > 3) The hardest part: Do we want to guarantee the palette to contain > anything on start? > On the one hand it would simplify some applications that don't care > too much, if one can assume that there is a reasonable default > that contains (e.g.) at least the 8 basic colours in two shades each. I don't think it is worth this trouble. Program knows best what colors it need, and should be responsible for setting them. In other words, we don't guarantee a usable palette. > 4) An idea popped into my mind, when collecting this: > Currently we specify the s parameter to define where to load values. > WHat about this: > If you specify s==GGI_AUTO, the target will itself choose a place > in the palette for you. I think that the descision algorithm would become rather complicated. If we don't chose s at random, then we would have to remember where we have loaded before, where we have not, in which order they were loaded etc. To much trouble for something I actually see little use in. -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Thu Jun 4 03:41:14 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA24858; Thu, 4 Jun 1998 03:41:13 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA04782; Thu, 4 Jun 1998 03:33:51 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 03:33:51 -0700 (PDT) Date: Thu, 4 Jun 1998 12:31:22 +0200 (METDST) From: Jacek Konieczny To: ggi Mailingliste Subject: Re: Libggi Issues round two is open! -- my final word In-Reply-To: <199806040923.LAA24784@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"7Dytc3.0.UA1.DWdTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2508 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 4 Jun 1998, Hartmut Niemann wrote: > If you want to allow loading different fonts, you need a device independent > format to specify the font data, fall back methods for strange hardware, > different implementations for text and graphics and all kinds of rubbish, > which is why I suggest: > - ggiPuts is going to use iso-8859-1 (latin1) charset. It will not > support unicode, will not support loading different charsets. > But if one implementation does not support full iso-8859-1 but does > support ASCII 0x20-0x7e (which is a subset if iso, isn't it?), then this > is regarded a class 99 bug (i.e. document it, but no hurry fixing it.) IMHO ggiPuts should support only ASCII. Allowing it to display other characters will make people use it to display a lot of text which in some cases can be internationalized. Such programs would work for most west-european countries and USA, but when somebody would like to use ISO-8859-2 or something it would mean changing a lot in source code. I know this from my experience. So if ggiPuts is not to be used in i18n it shouldn't display any characters exceding ASCII. Or the set of charsets above ASCII should be user-definable. Greets, Jacek From ggi-develop-request@eskimo.com Thu Jun 4 03:41:19 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA24863; Thu, 4 Jun 1998 03:41:18 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA05342; Thu, 4 Jun 1998 03:39:09 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 03:39:09 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806041035.MAA10624@sunserver1.rz.uni-duesseldorf.de> Subject: Re: S3 864 anyone? In-Reply-To: from "Jon M. Taylor" at "Jun 3, 98 07:34:02 pm" To: ggi-develop@eskimo.com Date: Thu, 4 Jun 1998 12:35:05 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"EGgX_2.0.MJ1.BbdTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2509 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Is anybody working on a driver for the 864? > > Is it technically very different from the 96x series? > > vgadoc says it is exactly the same as a 964 but with max 4MB DRAM > instead of 8MB. Beware. 9xx is VRAM, 8xx DRAM. This requires some changes in RAMDAC code and timing setup. CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Thu Jun 4 04:10:16 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA24882; Thu, 4 Jun 1998 04:10:14 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA00751; Mon, 1 Jun 1998 11:15:15 -0700 Resent-Date: Mon, 1 Jun 1998 11:15:15 -0700 Date: Mon, 1 Jun 1998 19:03:39 +0200 (CEST) From: Emmanuel Marty X-Sender: core@gate.local To: ggi-develop@eskimo.com Subject: irc session, take 2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"kSfGv2.0.NB.i-kSr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2421 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello, > A new irc session is a good idea, and a badly needed one. Sadly, you have > chosen a rather bad time for me (exam on saturday), but I will try to see > if I can be there for a while at least. I also assume that it will be > logged and posted as usual? Allright, that time seems to be a bad idea :) The session will be logged and posted to the website as usual. However, I would really like most people to be here.. What about sunday june 7th at 5:00 PM MET (11:00 AM EST) ? Here we go again.. PST MST CST EST GMT+1 MET GMT+10 Sun Sun Sun Sun Sun Sun Mon 08:00A 09:00A 10:00A 11:00A 04:00P 05:00P 01:00A Now that would be Andrew J. Apted who has to be up at 1 AM on the night of sunday to monday, but hopefully he's in holidays and can do that :) Is that fine for everyone ? -- Emmanuel From ggi-develop-request@eskimo.com Thu Jun 4 04:25:37 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA24897; Thu, 4 Jun 1998 04:25:35 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA08723; Thu, 4 Jun 1998 04:22:27 -0700 Resent-Date: Thu, 4 Jun 1998 04:22:27 -0700 Message-Id: <199806041119.NAA24251@c125.ryd.student.liu.se> X-Mailer: exmh version 2.0.2 To: ggi-develop@eskimo.com cc: alex@c125.ryd.student.liu.se Subject: Re: irc session, take 2 In-reply-to: Your message of "Wed, 03 Jun 1998 11:22:09 EDT." <199806031525.LAA08901@dew.wserv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jun 1998 13:19:04 +0200 From: Alexander Larsson Resent-Message-ID: <"XAykH2.0.282.mDeTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2510 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > > > What about sunday june 7th at 5:00 PM MET (11:00 AM EST) ? > > > > > > > > > > Here we go again.. > > > > > > > > > > PST MST CST EST GMT+1 MET GMT+10 > > > > > Sun Sun Sun Sun Sun Sun Mon > > > > > 08:00A 09:00A 10:00A 11:00A 04:00P 05:00P 01:00A > > > > > > > > > Is that fine for everyone ? > > > > (Sorry for the many quotes, lost the original mail...) I can't be there. I don't work so much on ggi right now, i'm hacking on another project. BUT i was planning on doing some more work on ggi-mesa this summer. Soo, can someone please be there on sunday and make sure we get the 'frames' stuff into the libggi-api. I really need it. / Alex From ggi-develop-request@eskimo.com Thu Jun 4 05:25:55 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA24938; Thu, 4 Jun 1998 05:25:52 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA22445; Thu, 4 Jun 1998 05:11:44 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 05:11:44 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806041209.OAA27849@cip8.e-technik.uni-erlangen.de> Subject: Re: libggi: palettes To: mars@lysator.liu.se (Stefan Mars) Date: Thu, 4 Jun 1998 14:09:08 +0200 (MESZ) Cc: ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: from "Stefan Mars" at Jun 4, 98 12:12:02 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"N4R_d1.0.bU5.-xeTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2511 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > 1) The only way to detect whether there is a platte or not is > > to try to set it or to read the first value and check whether that fails. > > Do we want to leave and document this this way? Say 'yes'. > > No way. It's always a good idea to have functions that set something, > return a value that tells us how it went. Stefan, can you clarify what *you* mean? I meant: you try to get or set the palette, and if the function call returns -GGI_ERROR_SOMETHING, it didn't work, and you can conclude that the graphics board doesn't have a palette or that it isn't supported.. > > > One consequence is that the target that implements SetPalette > > MUST implement GetPalette as well. So either both will fail or none. > > Can't we document that a valid target must implement GetPalette anyway? Not necessarily. There will be a generic GetPalette implementation that returns 'failure', and there is no need to reimplement that if you don't put functionality into it. > > > Side note: if we document that ggi[PG]etPalette returns some GGI_OK without > > doing anything for len==0, if a palette is present, then this > > wouldn't even need dummy variables. > > Stupid question: What a PetPalette? *grin* Oops: [GS] But do you like the suggestion? > > > 4) An idea popped into my mind, when collecting this: > > Currently we specify the s parameter to define where to load values. > > WHat about this: > > If you specify s==GGI_AUTO, the target will itself choose a place > > in the palette for you. > > I think that the descision algorithm would become rather complicated. If > we don't chose s at random, then we would have to remember where we have > loaded before, where we have not, in which order they were loaded etc. > > To much trouble for something I actually see little use in. I disagree. The decision algorithm can be as complicated as you want, but it will normally very simple, and I see good reason for this. - normally you put all entries into the palette you want to have at startup, so each application sets the palette only once. - For a fullscreen mode, there is nobody competing about the CLUT, so set s=0. If you don't want to implement it differently, too. - On X it might be good to allocate from the end, to have the 'general' colours not messed up. Wouter (?) said he had code to copy the system-wide X palette into a private one and to allocate some colours there. - and if someone thinks of a real 'allocation' scheme, he'll build one. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Thu Jun 4 06:11:03 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA24971; Thu, 4 Jun 1998 06:11:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA01967; Mon, 1 Jun 1998 11:46:08 -0700 Resent-Date: Mon, 1 Jun 1998 11:46:08 -0700 Date: Mon, 1 Jun 1998 20:47:11 +0200 (MEST) From: Jan Kneschke To: ggi-develop@eskimo.com Subject: Re: GGI Real-time API (re: unresolved issues and visual science) In-Reply-To: <3572F3C5.2EE1EA83@altavista.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Lr5EW3.0.ZU.jRlSr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2423 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 1 Jun 1998, Tilman Vogel wrote: > Hello, Brian! > > Thank you very much for your extensive elaboration! > > I think it would be no problem to limit our project to one specific > hardware scenario. At the moment the hardware environment consists > mainly of SGIs an Macintosh computers. So we will have to buy new PCs > anyway and we still can decide about the components to use. > > I would be glad if you can make suggestions for us which hardware to > use. How big are the benefits from the AGP architecture? > > Since I haven't been programming with GGI: Could you please send me a > sample code snippet which tells GGI to flip pages and waits for it. > Looking at the source code I could not figure out which ggi-Function > actually issues a page-flip. Maybe I am just blind... ggiFlush() is > something different, right? What is the OpenGL glXSwapBuffers() > equivalent? > > Another question: What are KGI-SUID targets? I thought KGI's goal was > improving security by making it unnecessary to use suid. Or is this just > a solution for the time being? kgi-suid is just a target for driver programmers, because at dali there is no possibility to remove the driver-module from the kernel. if the driver isn't ok the dummy-program (demo) exits and resets the screen. you just try to fix the bug compile again ... it is just for faster driver development. > Tilman > > thats all Jan --- Project: GGI - S3-Vision-driver -- http://www.ggi-project.org/ -)= Jan (Weigon) Kneschke -- Kiel -- Northern Germany =(- From ggi-develop-request@eskimo.com Thu Jun 4 06:15:18 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA24976; Thu, 4 Jun 1998 06:15:17 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA01524; Thu, 4 Jun 1998 05:49:21 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 05:49:21 -0700 (PDT) X-Authentication-Warning: tingeling.lysator.liu.se: mars owned process doing -bs Date: Thu, 4 Jun 1998 14:47:02 +0200 (MET DST) From: Stefan Mars To: Hartmut Niemann cc: ggi Mailingliste Subject: Re: libggi: palettes In-Reply-To: <199806041209.OAA27849@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ZcHS71.0.RN.EVfTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2512 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > 1) The only way to detect whether there is a platte or not is > > > to try to set it or to read the first value and check whether that fails. > > > Do we want to leave and document this this way? Say 'yes'. > > > > No way. It's always a good idea to have functions that set something, > > return a value that tells us how it went. > Stefan, can you clarify what *you* mean? > I meant: you try to get or set the palette, and if the function call > returns -GGI_ERROR_SOMETHING, it didn't work, and you can conclude that > the graphics board doesn't have a palette or that it isn't supported.. Ok, here is how I understood what you said (I haven't checked against the source as I don't have it available on this machine). As I understood you, the API call ggiSetPalette is declared void and doesn't return a sucess/failure notice to the caller. In my mind that is a bad idea (tm), and all our functions should have a return value. Be it a pointer if we have allocated something, or a GGI_OK if we have set something etc.. doesn't matter, but it should return something. The other possibility that you described above is to first set the palette, then read it back and compare with what you just set. If they are the same we conclude that set was ok, otherwise it was a failure. That doesn't create very nice code, and is essentially extra work for the application-programmer. In short, for consistency and a clean nice API, all the API calls should have a return value from which the status can be found. Just my opinion, and I have a record about going against everyone else on this list if you haven't noticed :) > > > Side note: if we document that ggi[PG]etPalette returns some GGI_OK without > > > doing anything for len==0, if a palette is present, then this > > > wouldn't even need dummy variables. > > > > Stupid question: What a PetPalette? *grin* > Oops: [GS] > But do you like the suggestion? It should work out ok. PetPalette, n: Small creature that lives within your PC. If not fed correctly with data it will overthrow the ggiSetPalette API call and replace the GLUT with a favourite colormap of it's own. Should generally be avoided. Infected machines can only be fixed by EvStack. > > I think that the descision algorithm would become rather complicated. If > > we don't chose s at random, then we would have to remember where we have > > loaded before, where we have not, in which order they were loaded etc. > > > > To much trouble for something I actually see little use in. > I disagree. We can probably fight forever about this, so let's hear what everyone else has to say about it. -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Thu Jun 4 06:37:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA25017; Thu, 4 Jun 1998 06:37:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA10870; Thu, 4 Jun 1998 06:28:24 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 06:28:24 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806041325.PAA29635@cip8.e-technik.uni-erlangen.de> Subject: Re: libggi: palettes To: mars@lysator.liu.se (Stefan Mars) Date: Thu, 4 Jun 1998 15:25:51 +0200 (MESZ) Cc: ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: from "Stefan Mars" at Jun 4, 98 02:47:02 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-lKtR.0.ff2.q3gTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2513 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > > > 1) The only way to detect whether there is a platte or not is > > > > to try to set it or to read the first value and check whether that fails. > > > > Do we want to leave and document this this way? Say 'yes'. > > > > > > No way. It's always a good idea to have functions that set something, > > > return a value that tells us how it went. > > Stefan, can you clarify what *you* mean? > > Ok, here is how I understood what you said > [...] > doesn't matter, but it should return something. Yes, to make it absolutely clear: ggi[SG]etPalette do return an error code and always did. This was not my point, and I think I agree with you that this is a good idea. The question was: "does this error code checking suffice to detect the presence of a CLUT, or is there a need for some other means?" > > The other possibility that you described above is to first set the > palette, then read it back and compare with what you just set. If they are > the same we conclude that set was ok, otherwise it was a failure. That > doesn't create very nice code, and is essentially extra work for the > application-programmer. This is not what I meant. I meant: You can set a value, and if it failed it failed. OR you can get value #0 e.g., and if you get an error code, you can safely assume there is no palette present. Setting and reading back and comparing is IMHO not necessary and *really* complicated. > > In short, for consistency and a clean nice API, all the API calls should > have a return value from which the status can be found. Yes. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Thu Jun 4 06:50:15 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA25042; Thu, 4 Jun 1998 06:50:14 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA14817; Thu, 4 Jun 1998 06:48:34 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 06:48:34 -0700 (PDT) Date: Thu, 4 Jun 1998 09:46:24 -0400 (EDT) From: James A Simmons To: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... In-Reply-To: <19980604132421.41454@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"XwxS8.0.Hd3.lMgTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2514 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 4 Jun 1998, Andrew Apted wrote: > Brian writes: > > > > > As for "in-kernel", I think it should remain a loadable module just > > > > to keep things flexible -- why force someone who wants to just > > > > use VESA modes to load code for multisync negotiation? > > > I agree but the person compiling the kernel should have a chose to put > > > this in the kernel or as a module. Some people might be funny about being > > > forced to use a module. > > > > Agreed... > > Me too. In menuconfig it could look something like this: > > Monitor Drivers > > < > Timelist support (CONFIG_MONITOR_TIMELIST) > < > Multisync support (CONFIG_MONITOR_MULTISYNC) > < > VESA modes support (CONFIG_MONITOR_VESA) Exactly> In fact I have a patch that does this. Once the CVS is up I will put it in their. > > And basic monitor support (i.e. monosync) would always be compiled in > (being so simple and small). > > Cheers, > _____________________________________________ ____ > \ / > Andrew Apted \/ > > From ggi-develop-request@eskimo.com Thu Jun 4 07:05:02 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA25053; Thu, 4 Jun 1998 07:05:00 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA00591; Wed, 3 Jun 1998 11:52:47 -0700 Resent-Date: Wed, 3 Jun 1998 11:52:47 -0700 Date: Wed, 3 Jun 1998 14:52:35 -0400 (EDT) From: James A Simmons To: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"4QfU21.0.x8.yjPTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2477 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998, Brian Julin wrote: > On 3 Jun 1998, Jason McMullan wrote: > > > [Aside] Brian, aren't you working on the new mode negotiation > > code? Why don't you get together with Andrew and see if the > > `generic monitor class' in-the-kernel option is a good > > one. > > Well, in general I think I'm about sold on the idea of ditching > insmod parameters for a /proc/ interface if we can find a > workable alternate on all potential KGI target OSes. As well as am I. The basic idea of loading all the needed drivers and have them sleep until we wake them up with /proc. What if we had a utility that could alter the module data. Say if the module is loaded then its data is in the kernel memory (/dev/kmem)? Then we could have a utility , has to be run as root to use kmem, that seraches for this data and can alter it. This method was the one I used to learn how the SCO UNIX kernel worked. > > As for "in-kernel", I think it should remain a loadable module just > to keep things flexible -- why force someone who wants to just > use VESA modes to load code for multisync negotiation? > > IMO all subsystem modules should be built if possible in such a way that > they can support more than one occurance of their hardware attached > to different displays, and be runtime configurable, which pretty > much means the same thing -- you send in your monitor parameters > to a generic monitor driver module. But still you might have > monitors too simple or too complex for that "generic" monitor driver, > so you should be able to load a different one, and load as many > different simultaneous ones as you wish. > > Not to be redundant, but -- Steffen's call. > > P.S. please don't use a USENET mechanism to post to the > list, not all of us are set up to reply that way. > > -- > Brian S. Julin > From ggi-develop-request@eskimo.com Thu Jun 4 07:28:30 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA25072; Thu, 4 Jun 1998 07:28:28 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA05307; Tue, 2 Jun 1998 15:09:42 -0700 Resent-Date: Tue, 2 Jun 1998 15:09:42 -0700 Date: Tue, 2 Jun 1998 17:46:19 -0400 (EDT) From: James A Simmons To: Jason McMullan cc: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... In-Reply-To: <199806022010.QAA04199@pepsi.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"kkbfK1.0.XI1.XW7Tr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2452 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 2 Jun 1998, Jason McMullan wrote: > 'James A Simmons wrote with particular insight...' > > One other thing. What if I have two cards and two monitors. Then this > > should be ggi-Matox-multisync.o and ggi-S3-timelist.o right. What if I > > switch the monitors? Make new modules gg-Matrox-timelist.o and > > ggi-S3-multisync.o. Any solutions? > > > > Well, that's the bastard about the current KGI build scheme. > What we really need is some sort of `monitor class' that > you can insert first, then say for a system with a VGA > monitor on a S3, a Samsung Syncmaster GLsi 17" on another > S3 card, and another VGA monitor on a Matrix, you could: Yes I have a idea. I have notice with the newer kernels that you have to insmod the head module then hardware specific modules. Such as sound we have to load sound.o then sb.o or adlib.o. Also we have to consider if people want to compile this into the kernel instead of as a module (you never know). So for the module we could have # insmod ggidrv.o # insmod timelist.o display = 0; # insmod multisync.o display = 1; # insmod S3.o display = 0; # insmod millenium.o display = 1; If you have a card that supports two monitors (Matrox does). Then #insmod ggidrv.o #insmod timelist.o display = 0; #insmod multisync.o display = 1; #insmod millenium.o display = 0,1; > > # insmod ggi-monitor-vga.o > # insmod ggi-monitor-Samsung17GLsi.o > # > # insmod ggi-display-S3.o display=0:vga,1:Samsung17GLsi > # insmod ggi-display-Matrox.o display=2:vga > # > # cat /proc/evstack/heads > #Head Display Monitor > 0 S3-Virge vga > 1 S3-Virge Samsung17GLsi > 2 Matrix-Millenium vga > > where display=: > > > Hmm... With the `display class' concept, we could (theortically) > create monitor classes where you can load their parameters > via /proc, ie: > > # echo "create-monitor 1" >/proc/evstack/class/monitor-vga > # cat </proc/evstack/monitor/1 > set horiz 50-60 > set vert 31.5,32,36-130 > EOF > # > > > Any ideas? > > > -- > Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc > > On the wonderful world of Microsoft Products: > > Why put fault tolerance in the OS, when it's > already built into the User? > -- Steve Shaw > comp.os.linux.advocacy > From ggi-develop-request@eskimo.com Thu Jun 4 07:35:10 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA25078; Thu, 4 Jun 1998 07:35:03 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA31714; Wed, 3 Jun 1998 01:03:44 -0700 Resent-Date: Wed, 3 Jun 1998 01:03:44 -0700 Message-ID: <19980603080345.D16538@earthlink.net> Date: Wed, 3 Jun 1998 08:03:45 +0000 From: "Rev. Joseph Carter" To: mwfunk@uncc.campus.mci.net, GGI list Subject: Re: KGI license? Mail-Followup-To: mwfunk@uncc.campus.mci.net, GGI list References: Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=UnaWdueM1EBWVRzC X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Michael Funk on Tue, Jun 02, 1998 at 11:13:17PM +0000 X-Operating-System: Linux icarus2 2.1.101 Resent-Message-ID: <"KBCBZ3.0.Ll7.UDGTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2464 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com --UnaWdueM1EBWVRzC Content-Type: text/plain; charset=us-ascii On Tue, Jun 02, 1998 at 11:13:17PM +0000, Michael Funk wrote: > Hopefully this isn't an inflammatory question to ask: was any decision > ever made regarding the licensing of KGI? A while back there was some > discussion of putting it under a non-copyleft license, so that other > free OS's (*BSD's, etc.) could use it without fear of 'tainting' their > kernels, as the GPL is inclined to do. Then release it under both the GPL and BSD licenses. This is possible afterall, though it would make more sense in that case to just release it as BSD and call it good enough. Perhaps perl's Artistic license is a better idea since it does maintain some revision control? > I ask this now because it seems like if this is ever going to happen, > it needs to be done as soon as possible. It's my understanding that > a GPL'd piece of software can be relicensed only if all of the developers > agree to it. As time goes on, and the number of contributors increase, > this will become darned near impossible. If anyone has any intention > of 'freeing' KGI from the copyleft, so that it may be shared with others > while respecting their own licenses, it needs to be done ASAP. I would agree here. The GPL is in a few ways very restrictive. Some argue that's good. Others that it's bad. I don't think we should get into a major debate about that here, but if the plan is to make it more universal, it should be done soon. --UnaWdueM1EBWVRzC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3a iQEVAwUBNXUDWHRYxo9QvaDtAQFp6Af+NUGcHwYeZwZoSGzzIZQljbPsmHIJgNAU ZkEnyidHRIm+qbHFYS1SC6Cu+3xG/bVfVdSsz4nh5BhY9+0tseD1xn28W324mONU exACyvnfKkcLdM4nGj4h6WcFUjHliYH6+/I0faj2QdLHIhcKGAb39INOproGTBeG 0JTlfG0rVMaYgRGrZpLTTRnDHj8Yqd8NXuM2Lewl3Z26TCRFo3cMPR9AGx9LmAnJ aMcD8G+0dWZC9h+hftiS7S6z9Xuw3RksNhTty5bGucmsV5d1DKHhrmpbCFR4q06l u0lPKS44oNn8ovgVpBjw3mRBg8tWvIyjsF7w1mRjtiMBE1E+MKRAFQ== =FyUj -----END PGP SIGNATURE----- --UnaWdueM1EBWVRzC-- From ggi-develop-request@eskimo.com Thu Jun 4 07:38:06 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA25083; Thu, 4 Jun 1998 07:37:48 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA08862; Wed, 3 Jun 1998 13:17:30 -0700 Resent-Date: Wed, 3 Jun 1998 13:17:30 -0700 Date: Wed, 3 Jun 1998 11:37:38 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Use of shared pages/SYSV SHMs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"XZ6L-3.0.f92.DzQTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2480 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com How does the use of SYSV SHMs or other shared page mechanisms for a kernel<->userspace interface shake out on various architectures/OSs? It strikes me that these are the most generic form of interface we have (and also the handiest in a lot of ways) since, barring the initial aquisition of the SHM, it's just a pointer to a page (or more) of memory. Not only can SHMs transmit any information an IOCTL can, but they can be updated by the kernel at any time and don't have to wait for a user request, which means when SHMs are available user requests sometimes won't have to go into kernel space, especially in ASYNC mode with a command cache arrangement. Ping-pong buffers are IMO an inferior form of command cache since they _have_ to be submitted rather than being optionally submitted, perhaps to be processed during another kernel<->user transition rather than forcing one to occur just to flush the command cache (though they are a clever innovation, to be fair). So perhaps we should be looking at using these instead of playing with IOCTLs and such? A few convenience functions in the kernel driver and behind the scenes in libGGI to abstract use of a memory page for command/data transmit and to handle creation/deletion/MMU of SHMs in a graphics multiprocess environment would enhance GGI/KGI and simplify things. On the SUID-KGI and DOS ports, you simply substitute a regular memory area and a pointer, with some sort of advisory locking to emulate permissions/MMU, not that multi-graphics-process will be a common occurance with these. If SHMs aren't available you have to make do with a copy-to-from-user function and a single IOCTL or other system call to kickstart things, but that's an OS deficiency that can't be resolved in a better manner. How many UNIXes implement SYSV SHM, some other form of shared memory (like MMAP on physical memory), or at minimum a copy-to-from-user mechanism ... probably all of them. How about BeOS and MacOS, they have an analog, right? Is there any reason why we use IOCTLs other than for the blocking effect? Sorry for the rant, but when I hear talk of "setting KGI in stone" I get bothered. libGGI can be set in stone without crippling it, since the code underneath the API can change. KGI IS in some part the code underneath the API, so if we set it in stone it better be done right. It's a much more sensitive standard to be setting. I'm done now :) -- Brian S. Julin From ggi-develop-request@eskimo.com Thu Jun 4 08:16:45 1998 Return-Path: Received: from mx2.eskimo.com (root@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA25109; Thu, 4 Jun 1998 08:16:36 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA18004; Thu, 4 Jun 1998 07:01:58 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 07:01:58 -0700 (PDT) Date: Thu, 4 Jun 1998 09:59:40 -0400 (EDT) From: James A Simmons To: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"6FPdE1.0.6P4.EZgTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2515 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Brian writes: > > > > > > > As for "in-kernel", I think it should remain a loadable module just > > > > > to keep things flexible -- why force someone who wants to just > > > > > use VESA modes to load code for multisync negotiation? > > > > I agree but the person compiling the kernel should have a chose to put > > > > this in the kernel or as a module. Some people might be funny about being > > > > forced to use a module. > > > > > > Agreed... > > > > Me too. In menuconfig it could look something like this: > > > > Monitor Drivers > > > > < > Timelist support (CONFIG_MONITOR_TIMELIST) > > < > Multisync support (CONFIG_MONITOR_MULTISYNC) > > < > VESA modes support (CONFIG_MONITOR_VESA) Exactly> In fact I have a patch that does this. Once the CVS is up I will put it in their. Here is another suggestion. A seperater module for 3D stuff. So you insmod i386.o insmod monitor.o, insmod S3 or whatever and then insmod 3d.o. Their has been alot of no don't add high end graphics to ggi. Here we leave it as a option to the user and for cards that don't have any high end graphics config could be setup so one doesn't compile it. > > > > And basic monitor support (i.e. monosync) would always be compiled in > > (being so simple and small). > > > > Cheers, > > _____________________________________________ ____ > > \ / > > Andrew Apted \/ > > > > > From ggi-develop-request@eskimo.com Thu Jun 4 08:49:59 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA25120; Thu, 4 Jun 1998 08:44:38 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA04555; Thu, 4 Jun 1998 08:27:53 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 08:27:53 -0700 (PDT) Date: Thu, 4 Jun 1998 10:44:09 -0400 (EDT) From: Brian Julin To: Colin Plumb cc: ggi-develop@eskimo.com Subject: Re: Using RDTSC for ggiGetRayPos() In-Reply-To: <199806040717.BAA19339@nyx10.nyx.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"X-tPQ2.0.v61.gphTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2516 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 4 Jun 1998, Colin Plumb wrote: > (I Cc:'d my reply to ggi-develop@eskimo.com, but it bounced because > I'm not subscribed. You might want to send my previous mail > (appended in case you need a copy) and this there to share.) I'll just not edit out any of your message as I reply and CC the list, how's that? > > On Wed, 3 Jun 1998, Colin Plumb wrote: > >> Um, this is going to die horribly on laptops. I'm trying to write a good > >> gettimeofday() for Linux, and it's complicated by the fact that systems > >> like APM slow down the processor clock whenever the system is idle. > >> This usually affects the TSC as well, resulting in it having a poor > >> correlation with wall-clock time. > > Brian Julin replied: > > Thanks for the information (very useful.) > > > Still, I'd assert shared memory is the way to go -- take a look at > > ping-pong buffers. These mostly already use shared memory but they > > could use it better IMO. Currently the application writes in a page > > until it is full, then segfaults on a second page -- the kernel > > empties the page that was full during the segfault and maps it > > out. The app continues writing in the second page, which is mapped in. > > > However, if the "protocol" were changed to simply use one area, > > the app could write and simply check a counter in the area that says > > the last location that the kernel has processed up to, so as not to > > overwrite unused data. Every time the app writes, it increments a > > second counter that tells the kernel how much new data is in the page. > > Instead of segfaulting chunks the app can call an ioctl. > > > In the meantime, the kernel could be reading/emptying the page > > whenever it finds itself in kernel space for whatever reason -- > > maybe as a periodic realtime or IRQ driven task or maybe just > > as a tack-on to in-kernel evstack processing; whatever works best. > > Yes, that's an excellent protocol. Every time the kernel completes > one action, it checks for more using the following algorithm: > > - Check for new work. > - If found, return it. > - Set "I'm done" flag. > - Double-check that there really is no new work. > - If there is any, clear the flag and return it. > - Stop looking for work until ioctl(). > > The application does: > - Write new work to buffer. > - Increment pointer > - Check "kernel is done" flag. If set, ioctl(). > > > The problem is that this is a very simple protocol that can be emulated > with a glue library over something else very easily. No compatibility > problems. > > > Use of a read-only SHM might help you too -- keep status in the > > SHM and any app can find it via it's cookie. The status would read > > as the value of the cycle counter when the accuracy was last determined, and > > the accuracy at that point. Thus an app would know roughly how reliable > > the value is, and could use a call of "getroughtimeofday" to get > > a possibly errored result, but know what the error limits are. This > > would possibly be more desireable for many apps than having to wait for > > a context switch. > > The problem here is that the information exported from the kernel is > rather more complex, so it's hard to get the interface right. And > because the kernel has to keep it updated in real-time, without prompting, > it's a real backwards-compatibility burden. Ah. Well, if we have a hope of understanding it, it can all be wrapped in a library invisible to the user at least. I did take a course in discreet control of dynmic systems, so I'm OK with feedback control, transforms and matrices. Probably a bit rusty though. > libggi helps with a lot of that, but the kernel and libggi parts are going > to have to know a lot about each other. > > Not impossible, but let me tell you, the algorithms are fairly advanced > control theory augmented with a lot of practical experience and cynicism, > and are a bitch to design. Read Dave Mills' NTP papers for some idea of > what you're trying to do. (http://www.eecis.udel/edu/~mills/) Every time > an interrupt gets delayed, it adds noise that you have to filter out. OK, I will -- I love RT stuff :) > (Just out of curiosity, what information are you trying to provide and > what is available from the hardware to help? Since you know the dot clock > and all the dividers that make up the screen, you just need a counter > in sync with the dot clock? How well can you get the beam position from > the hardware?) The answer is -- sometimes. On some chips you can read back the ray position. On most you should only do so in kernel space because doing so requires root privilages to access the register. In these cases I suppose letting the chip count a few cycles and then returning with a very rough calibration of the cycle counter would be acceptable, since the delay back to userspace isn't huge. There are two levels of information we want to supply. The basic API is very simple, ggiGetRayPos() returns the current ray position, and ggiWaitRayPos doesn't return until the ray position is reached. The stumbling block is that the context switch going back to the application can vary in duration, thus the search for a way to do things from userspace. Of course by the same token, pure userspace processes are subject to task switching. Talk about being caught between a rock and a hard place. The more advanced API, the form of which which has only been speculated at, will offload commonly needed retrace tasks like page flipping and pallette loading to code resident in the kernel. This might involve some sort of scheduler call to turn tasks on and off and set their running times. > > You didn't mention back-calibrating the cycle counter with the timer > > tick so you know the rate it increases while power saving, why? > > Does it vary? > > Um, I don't quite understand what you're referring to, but the clock > frequency varies in different power=saving modes, and the APM system > doesn't tell the kernel that it's changing the clock rate, or what it's > changing it to, or how many ms it'll take to change it. (The clock > rate is changed gradually, not stepped.) That answers my question. Yes, that I'd say is a "tough nut" problem. > This makes it more than a little bit difficult to deal with. > > > Also, we are in a bind with non-RT linux on 386s, as we need to make > > a periodic task possibly at a rather fast frequency if crummy video > > cards are being used. This screws with the scheduler like the PC > > speaker sound driver does. Wasteful, but you suffer if you use obselete > > equipment, I guess... there's no other way to do it that I can think of. > > Maybe if you describe the problem a little bit better, I could figure > something out. Older VGA cards have no readback of the ray position. They can only tell you when the video blanks and retraces horizontally or vertically through a grand total of three status bits. Some cannot even send an IRQ, and even those that do send it on vertical sync, not vertical blank. On 386's there is no cycle counter to calibrate with. A more thorough description is in the file ftp://syngery.caltech.edu/pub/ggi/doc/retrace.txt There may be worse cases where you cannot get status at all, on other acrchitectures. The worst-case bleak prospect for getting a ggiWaitRayPos() to work on these is if they allow the kernel to actually proactively syncronize the frames with a holdoff register. That's a very ugly prospect :( -- Brian S. Julin From ggi-develop-request@eskimo.com Thu Jun 4 09:51:57 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA25206; Thu, 4 Jun 1998 09:51:30 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA16710; Thu, 4 Jun 1998 09:51:48 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 09:51:48 -0700 (PDT) X-Authentication-Warning: sandra.lysator.liu.se: gz owned process doing -bs Date: Thu, 4 Jun 1998 18:49:27 +0200 (MET DST) From: Gernot Ziegler To: ggi-develop@eskimo.com Subject: Re: irc session, take 2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"TK4Yf3.0.r44.W2jTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2517 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 1 Jun 1998, Emmanuel Marty wrote: > Now that would be Andrew J. Apted who has to be up at 1 AM on the night of > sunday to monday, but hopefully he's in holidays and can do that :) > > Is that fine for everyone ? Yepp. Little Gernot ;) .... but I'm certainly not so important ;) ... Travelling back from Sweden to Austria in that time, and I dont have a Laptop & GSM & money yet to hook up during the journey ;) Servus, Gernot /-----------------------------W-E-L-C-O-M-E------------------------------\ T The Austria <=> Sweden connection..... T | E-Mail: gz@lysator.liu.se H O Homepage: http://www.lysator.liu.se/~gz E \------------------------------F-U-T-U-R-E-------------------------------/ From ggi-develop-request@eskimo.com Thu Jun 4 10:06:20 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA25214; Thu, 4 Jun 1998 10:04:20 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA12697; Thu, 4 Jun 1998 10:01:05 -0700 Resent-Date: Thu, 4 Jun 1998 10:01:05 -0700 From: Andrew Apted Message-ID: <19980605010212.44312@ajax.netspace.net.au> Date: Fri, 5 Jun 1998 01:02:12 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi: palettes Reply-To: ggi-develop@eskimo.com References: <199806040838.KAA23950@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806040838.KAA23950@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Thu, Jun 04, 1998 at 10:38:36AM +0200 Resent-Message-ID: <"GweW33.0.t53.CBjTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2518 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut writes: > One more in the API refining series: > The pallette (color lookup table, CLUT). > > There are several areas, where our specification is vague: > > 1) The only way to detect whether there is a platte or not is > to try to set it or to read the first value and check whether that fails. > Do we want to leave and document this this way? Say 'yes'. Yes. > One consequence is that the target that implements SetPalette > MUST implement GetPalette as well. Reasonable. But not the opposite -- i.e. ggiGetPalette() should be allowed to work even when ggiSetPalette() fails, such as being in a mode that only has a fixed palette (e.g. CGA 4-color graphics :-)). > Side note: if we document that ggi[PG]etPalette returns some > GGI_OK without doing anything for len==0, if a palette is present, > then this wouldn't even need dummy variables. I had the same idea myself just the other day -- if palette setting is not available, then ggiSetPalette() with any length *including zero* returns an error. Similiarly for ggiGetPalette() -- if palette getting isn't supported *at all*, then using len == 0 should also return an error. > 2) The size of the palette can be determined by the bits-per-pixel value > ONLY, which is only part of the directbuffer API. > The ggi_graphtype contains this information, 'cypted', too. > So we could document the macro in internal.h: This would be solved if we adopted the slighter better system for graphtypes like I proposed a while back -- where instead of "GT_8BIT" a program would use "GT_INDEXED | 8". In this case the bits-per-pixel is nice and visible, and not 'crypted'. > 3) The hardest part: Do we want to guarantee the palette to contain > anything on start? IMHO No. > 4) An idea popped into my mind, when collecting this: > Currently we specify the s parameter to define where to load values. > WHat about this: > If you specify s==GGI_AUTO, the target will itself choose a place > in the palette for you. Good idea ! That would solve the "X flashing" problem (something which annoys me too) for many applications. So long as we document that any program using this feature *must* use ggiMapColor() to get the pixel values (e.g. to create a look-up table), then it's a winner. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Thu Jun 4 10:38:39 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA25263; Thu, 4 Jun 1998 10:38:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA26462; Thu, 4 Jun 1998 10:34:56 -0700 Resent-Date: Thu, 4 Jun 1998 10:34:56 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Use of shared pages/SYSV SHMs To: ggi-develop@eskimo.com Date: Thu, 4 Jun 1998 19:16:15 +0200 (MET DST) In-Reply-To: <810CCC6435ADD1119E640060085BED6A15DD95@NT_FS1> from "Brian Hurt" at Jun 3, 98 03:42:10 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"RW0531.0.dS6.sgjTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2520 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > How does the use of SYSV SHMs or other shared page mechanisms > > for a kernel<->userspace interface shake out on various > > architectures/OSs? It strikes me that these are the most generic > > form of interface we have (and also the handiest in a lot of ways) > > since, barring the initial aquisition of the SHM, it's just a > > pointer to a page (or more) of memory. > > I'm not involved (currently) in active GGI development, but I do write > device drivers as my day job. The biggest problem with all the SYSV > IPCs are that they tend have extreme system-wide and per-processor > limitations. mmaps() work better. The best and most generic way to > share memory between two processes is to have both processes mmap > the same file. You can also share memory between a driver and a > process by mmaps. Yes. This is how it works now. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Thu Jun 4 10:38:45 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA25262; Thu, 4 Jun 1998 10:38:20 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA26497; Thu, 4 Jun 1998 10:35:04 -0700 Resent-Date: Thu, 4 Jun 1998 10:35:04 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Use of shared pages/SYSV SHMs To: ggi-develop@eskimo.com Date: Thu, 4 Jun 1998 19:20:12 +0200 (MET DST) In-Reply-To: from "Brian Julin" at Jun 3, 98 11:10:06 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"qj5lI.0.gS6.tgjTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2521 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > On Wed, 3 Jun 1998, Brian Hurt wrote: > > I'm not involved (currently) in active GGI development, but I do write > > device drivers as my day job. The biggest problem with all the SYSV > > IPCs are that they tend have extreme system-wide and per-processor > > limitations. mmaps() work better. The best and most generic way to > > share memory between two processes is to have both processes mmap > > the same file. You can also share memory between a driver and a > > process by mmaps. > > I'm only really attracted to SYSV SHMs over MMAPs because they > would be easily locatable through the SYSV IPC protocols. If they > are resource limited, MMAPs will do; they are just a little more > cumbersome to set up. ??? Why ??? >From LibGGI source : /* map the HW GC ! */ mygc=(ggi_gc *)mmap(NULL,/*PAGE_SIZE*/4096,PROT_READ|PROT_WRITE, MAP_SHARED,VIS_FD(visual),MMAP_TYPE_GC); CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Thu Jun 4 10:39:08 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA25276; Thu, 4 Jun 1998 10:38:53 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA26391; Thu, 4 Jun 1998 10:34:47 -0700 Resent-Date: Thu, 4 Jun 1998 10:34:47 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: mouse events in ggi To: ggi-develop@eskimo.com Date: Thu, 4 Jun 1998 19:14:20 +0200 (MET DST) In-Reply-To: from "Jan Kneschke" at Jun 3, 98 00:48:41 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"KpvXF2.0.zR6.ngjTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2519 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > i just started the port synaesthesia to ggi. right now i have the output > working (using DirectBuffer). now, i have to know how to get mouse events > from ggi without using evstack. is there such a possibility ?? There already is such a port : -rw-r--r-- 1 devel users 19146 Jan 25 17:22 ggisyna-0.8.tar.gz I think you got enough answers for your question - right ? If not ask back. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Thu Jun 4 10:59:13 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA25307; Thu, 4 Jun 1998 10:59:08 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA00769; Thu, 4 Jun 1998 10:56:03 -0700 Resent-Date: Thu, 4 Jun 1998 10:56:03 -0700 X-Authentication-Warning: mir.inazuma.dyn.ml.org: tetron owned process doing -bs Date: Thu, 4 Jun 1998 14:04:19 -0400 (EDT) From: Peter Amstutz X-Sender: amstpi@mir.inazuma.dyn.ml.org Reply-To: amstpi@freenet.tlh.fl.us To: ggi Mailingliste cc: Stefan Mars Subject: Re: libggi: palettes In-Reply-To: <199806041325.PAA29635@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"y4oPL2.0.qB.k-jTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2523 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 4 Jun 1998, Hartmut Niemann wrote: > Yes, to make it absolutely clear: ggi[SG]etPalette do return an error code > and always did. This was not my point, and I think I agree with you that this > is a good idea. The question was: "does this error code checking > suffice to detect the presence of a CLUT, or is there a need for some > other means?" Though we do have to differentiate error returns, for example what if an application trys to set a 8 bit palette with 257 values and gets an error, and assumes it's in a non-paletted mode? Whoops. Maybe a return of -1 means "no palette available" and -2 means "invalid range" ? > > > > In short, for consistency and a clean nice API, all the API calls should > > have a return value from which the status can be found. > Yes. I second that. Peter Amstutz /* E-mail: amstpi@freenet.tlh.fl.us Home Page: http://www.freenet.tlh.fl.us/~amstpi/ Geek Code: (see http://www.geekcode.com/ for decoding instructions) GCS d- s:+ a--- C++>$ UL++++>$ P+(++) L++>$ E W++ N+ !o K w-- !O M-() !V PS+(++) PE-(--) Y+ PGP t 5++ X+ R tv b+ DI+ D++ G e h */ From ggi-develop-request@eskimo.com Thu Jun 4 11:05:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA25328; Thu, 4 Jun 1998 11:05:05 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA28644; Thu, 4 Jun 1998 10:54:01 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 10:54:01 -0700 (PDT) Date: Thu, 4 Jun 1998 10:46:19 -0700 (PDT) From: KC5TJA To: andreas.beck@ggi-project.org cc: ggi-develop@eskimo.com Subject: Re: Use of shared pages/SYSV SHMs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"u6oZc1.0.P_6.syjTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2522 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > >From LibGGI source : > > /* map the HW GC ! */ > mygc=(ggi_gc *)mmap(NULL,/*PAGE_SIZE*/4096,PROT_READ|PROT_WRITE, > MAP_SHARED,VIS_FD(visual),MMAP_TYPE_GC); Now just think, folks. All mmap() needs is a parameter that specifies a call-back function that will handle page-faults in the specified region. In that way, GGI could install a custom "virtual memory" handler that handles page faults IN USER SPACE, allowing for customized virtual memory schemes (such as reading/writing from/to a compressed image file, but making it appear fully expanded in memory). But that's day-dreaming, and technically doesn't belong on this list. :-) ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Thu Jun 4 11:50:12 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA25368; Thu, 4 Jun 1998 11:50:08 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA11416; Thu, 4 Jun 1998 11:50:14 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 11:50:14 -0700 (PDT) X-Authentication-Warning: tingeling.lysator.liu.se: mars owned process doing -bs Date: Thu, 4 Jun 1998 15:46:54 +0200 (MET DST) From: Stefan Mars To: Hartmut Niemann cc: ggi Mailingliste Subject: Re: libggi: palettes In-Reply-To: <199806041325.PAA29635@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"6lJYj1.0.Eo2.OnkTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2525 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 4 Jun 1998, Hartmut Niemann wrote: > Yes, to make it absolutely clear: ggi[SG]etPalette do return an error code > and always did. This was not my point, and I think I agree with you that this > is a good idea. The question was: "does this error code checking > suffice to detect the presence of a CLUT, or is there a need for some > other means?" Ah, ok. Now that we both talk about the same thing.. :) I would actually prefer a specific errorcode, like GGI_NO_CLUT_AVAILABLE or something like that. Should that not be possible, then let's just document it as is and let the application programmers figure it out. You know, a way to solve this would be to add an API call that would report the capabilities of the drivers/targets loaded :) I rest my case, -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Thu Jun 4 11:52:26 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA25373; Thu, 4 Jun 1998 11:52:22 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA10935; Thu, 4 Jun 1998 11:47:58 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 11:47:58 -0700 (PDT) Date: Thu, 4 Jun 1998 10:06:34 -0400 (EDT) From: James A Simmons To: ggi-develop@eskimo.com Subject: Re: Use of shared pages/SYSV SHMs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"6qmCp.0.dg2.MlkTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2524 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Sorry for the rant, but when I hear talk of "setting KGI in stone" > I get bothered. libGGI can be set in stone without crippling it, > since the code underneath the API can change. KGI IS in some > part the code underneath the API, so if we set it in stone it > better be done right. It's a much more sensitive standard to > be setting. > > I'm done now :) > > -- > Brian S. Julin > No don't make KGI set in stone. Like Brain said KGI is one of the under lying codes to libggi. If we set KGI are hands will be tried. I am not aying going nuts and rewriting kgi all the time. What ever improvements that will incorporated will be the decision of the KGI guys and if they do change something that breaks the current drivers then what needs to be done to get the driver working should be posted to everyone. This way we can avoid the drivers don't compile with evstack from dali problem again. From ggi-develop-request@eskimo.com Thu Jun 4 12:31:23 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA25407; Thu, 4 Jun 1998 12:30:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA06218; Thu, 4 Jun 1998 12:26:22 -0700 Resent-Date: Thu, 4 Jun 1998 12:26:22 -0700 Date: Thu, 4 Jun 1998 15:31:18 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: SMP- and thread- safing (Was: Re: Using RDTSC for ggiGetRayPos()) In-Reply-To: <199806041915.PAA16395@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"KvsLv3.0.pW1.RJlTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2528 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998, Brian Julin wrote: > However, if the "protocol" were changed to simply use one area, > the app could write and simply check a counter in the area that says > the last location that the kernel has processed up to, so as not to > overwrite unused data. Every time the app writes, it increments a > second counter that tells the kernel how much new data is in the page. > Instead of segfaulting chunks the app can call an ioctl. You'd still need to protect those counters with some sort of synchronization mechanism. You can't assume that integer data types are read/written atomically, even though they more or less are on many architectures, or that you have an atomic test-and-set operation availble to you. This would (at a theoretical level) be a good application for sempahores. -=MenTaLguY=- From ggi-develop-request@eskimo.com Thu Jun 4 12:31:28 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA25408; Thu, 4 Jun 1998 12:31:04 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA29566; Thu, 4 Jun 1998 12:03:56 -0700 Resent-Date: Thu, 4 Jun 1998 12:03:56 -0700 To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: libggi: palettes Date: 4 Jun 1998 19:03:50 GMT Organization: OnTV Pittsburgh, L.P. Lines: 36 Sender: Jason McMullan Distribution: local Message-ID: <6l6r2m$99j$1@butter.visus.com> References: <6l6l0j$7ds$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"fkc0H2.0.YD7.M-kTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2526 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andrew Apted wrote with confidence: > This would be solved if we adopted the slighter better system for > graphtypes like I proposed a while back -- where instead of "GT_8BIT" a > program would use "GT_INDEXED | 8". In this case the bits-per-pixel is > nice and visible, and not 'crypted'. I like this - hmm - how about for EvStack using attributes on the mode - would help a lot in mode setting... #define GT_INDEXED 0x00000100 /* Indexed palette */ #define GT_PLANAR 0x00000200 /* Planar frame buffer (one per each bit of pixel) */ #define GT_TILED 0x00000400 /* `Tiled' display (ie TEXT or a Nintendo 8bit) */ ... #define GT_HAMM 0x00800000 /* Amiga HAMM mode */ ... /* And then you can define all sorts of wacky modes... */ #define GM_TEXT16 (GT_TILED|GT_INDEXED|16) #define GM_1BIT (1) #define GM_VGA_4BIT (GT_PLANAR|4) #define GM_AMIGA_8BIT (GT_PLANAR|8) #define GM_NINTENDO (GT_TILED|8) -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Thu Jun 4 12:37:44 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA25430; Thu, 4 Jun 1998 12:37:08 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA10913; Thu, 4 Jun 1998 12:40:16 -0700 Resent-Date: Thu, 4 Jun 1998 12:40:16 -0700 Date: Thu, 4 Jun 1998 15:44:44 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Nested Structure Declarations (Was: Re: Couple of naive questions) In-Reply-To: <199806041915.PAA16435@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"td6aP2.0.6g2.LWlTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2530 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > 2a) Can you somehow syntactically nest structure definitions e.g. > > I don't think so. You have to declare the nested structures first, then > you can use them inside other structures, I believe. No, it's legal to nest structure declarations in C. -=MenTaLguY=- From ggi-develop-request@eskimo.com Thu Jun 4 12:38:27 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA25435; Thu, 4 Jun 1998 12:38:24 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA20679; Thu, 4 Jun 1998 12:30:58 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 12:30:58 -0700 (PDT) Message-ID: <810CCC6435ADD1119E640060085BED6A15DD97@NT_FS1> From: Brian Hurt To: "'ggi-develop@eskimo.com'" Subject: RE: Use of shared pages/SYSV SHMs Date: Thu, 4 Jun 1998 11:04:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Resent-Message-ID: <"Kqlhy.0.t25.fNlTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2529 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wednesday, June 03, 1998 10:38 AM, Brian Julin [SMTP:bri@forcade.calyx.net] wrote: > Sorry for the rant, but when I hear talk of "setting KGI in stone" > I get bothered. libGGI can be set in stone without crippling it, > since the code underneath the API can change. KGI IS in some > part the code underneath the API, so if we set it in stone it > better be done right. It's a much more sensitive standard to > be setting. Final peice of advice: get it working _first_. Then run a profiler on the code to find where the bottle necks are. Then rengineer the API to work around the bottlenecks (if necessary). From ggi-develop-request@eskimo.com Thu Jun 4 13:30:33 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA25468; Thu, 4 Jun 1998 13:30:27 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA32030; Thu, 4 Jun 1998 13:32:26 -0700 Resent-Date: Thu, 4 Jun 1998 13:32:26 -0700 Date: Thu, 4 Jun 1998 13:26:08 -0700 (PDT) From: KC5TJA To: Jason McMullan cc: ggi-develop@eskimo.com Subject: Re: libggi: palettes In-Reply-To: <6l6r2m$99j$1@butter.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"1qmiQ.0.8q7.7HmTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2535 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > #define GT_HAMM 0x00800000 /* Amiga HAMM mode */ Actually, it should be HAM (Hold and Modify). Unless you're using the final M as 'Mode' (HAM Mode). :-) Just nitpicking for consistency, I guess... ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Thu Jun 4 13:52:42 1998 Return-Path: Received: from mx2.eskimo.com (root@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA25483; Thu, 4 Jun 1998 13:52:36 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA17686; Thu, 4 Jun 1998 12:19:37 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 12:19:37 -0700 (PDT) Date: Thu, 4 Jun 1998 12:52:56 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: separating subsystem modules (was: EvStack slight ...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"9lyiL2.0.6K4._ClTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2527 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 3 Jun 1998, James A Simmons wrote: > > Well, in general I think I'm about sold on the idea of ditching > > insmod parameters for a /proc/ interface if we can find a > > workable alternate on all potential KGI target OSes. > > As well as am I. The basic idea of loading all the needed drivers and have > them sleep until we wake them up with /proc. Well, it's about time I got around to learning how to actually program Evstacks, so I will look into implementing this, as I need a flexible infrastructure to gracefully integrate a new mode negotiation system. > What if we had a utility that > could alter the module data. Say if the module is loaded then its data is > in the kernel memory (/dev/kmem)? Then we could have a utility , has to be > run as root to use kmem, that seraches for this data and can alter it. Keep in mind a single module may need to be used for more than one head. If we can't have a /proc/evstack entry, perhaps the best would be to have a single file to which you echo: send monitor/1 ^D Anyway I'm most concerned with getting it to work under the development CVS tree for Linux/EvStacks for now. -- Brian S. Julin From ggi-develop-request@eskimo.com Thu Jun 4 13:55:20 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA25492; Thu, 4 Jun 1998 13:55:14 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA11762; Thu, 4 Jun 1998 13:57:37 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 13:57:37 -0700 (PDT) X-Authentication-Warning: eskimo.com: elladan owned process doing -bs Date: Thu, 4 Jun 1998 13:55:21 -0700 (PDT) From: Elladan To: "'ggi-develop@eskimo.com'" Subject: RE: Current Mode negotiation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"CkzoV3.0.dt2.xemTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2536 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Just a quick take on screen refresh... I think it should go a bit beyond simply being selectable. The system should favor standard refresh rates unless there's some specific reason to use something different. The problem is that, typically, modern monitors with digital controls like to be in the standard modes. You can set the size, position etc. for each standard mode, and it'll be recorded for you. But, when you go into psychotic modes with 120hz refresh and such, the monitor either thinks you're nuts and has trouble distinguishing modes, or it can only store a few settings. Beyond this problem, what you list in the monitor file isn't necessarily what you should be using. For instance, my monitor is certified to work at 1280x1024x60hz, right? It gets a 120Mhz pixel clock for that mode, and it can handle that, but it's not recommended if you can avoid it. But, unless you want 1280x1024, it's better to stay below an 80Mhz pixel clock. If I put in 120Mhz as the maximum, the driver is going to try to pound my monitor into the ground for every mode I select. If I set 80Mhz, I'll have to recompile it to switch to a mode above 1024x768. This is ridiculous. But, restricting it to a specific set of modes isn't a good solution either, since this is a fully capable multisync monitor. I think we want some sort of a table of standard modes, preferred modes, etc... Mode selection is something that happens very rarely, so we can afford to go wild with it computationally. On Tue, 2 Jun 1998, James A Simmons wrote: > On Tue, 2 Jun 1998, Paul Sargent wrote: > > > I agree. I don't want hardcoded frequency limits either. I'm just > > highlighting what a believe to be an oversight. > > > > Frequency of Screen refresh should be selectable. > I second this. But I believe root should be able to do this. It would be > bad if jane doe blows his monitor. This should be done threw evstack. > > -- ---------<*> I maintain there is much more wonder in science than in pseudoscience. And in addition, to whatever measure this term has any meaning, science has the additional virtue, and it is not an inconsiderable one, of being true. -Carl Sagan From ggi-develop-request@eskimo.com Thu Jun 4 14:09:17 1998 Return-Path: Received: from mx2.eskimo.com (root@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA25504; Thu, 4 Jun 1998 14:09:13 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA29399; Thu, 4 Jun 1998 13:12:43 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 13:12:43 -0700 (PDT) Date: Wed, 3 Jun 1998 04:44:45 +0200 (MEST) From: Jan Kneschke To: ggi-develop@eskimo.com Subject: Re: S3 864 anyone? In-Reply-To: <199806041035.MAA10624@sunserver1.rz.uni-duesseldorf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"B_k272.0.7B7.p-lTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2534 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 4 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > > > > Is anybody working on a driver for the 864? > > > Is it technically very different from the 96x series? > > > > vgadoc says it is exactly the same as a 964 but with max 4MB DRAM > > instead of 8MB. > > Beware. 9xx is VRAM, 8xx DRAM. This requires some changes in RAMDAC code > and timing setup. i have writen such a driver. i posted it to Joseph Morrison who is testin it, but he hasn't got a working clock/ramdac driver. please ask him for his current version. i have written the driver based on the 96x-driver but was never able to test it because only own a 96x and a virge. > > CU,Andy > > -- > Andreas Beck | Email : > > thats all Jan --- Project: GGI - S3-Vision-driver -- http://www.ggi-project.org/ -)= Jan (Weigon) Kneschke -- Kiel -- Northern Germany =(- From ggi-develop-request@eskimo.com Thu Jun 4 14:17:21 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA25509; Thu, 4 Jun 1998 14:17:13 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA13064; Thu, 4 Jun 1998 12:46:21 -0700 Resent-Date: Thu, 4 Jun 1998 12:46:21 -0700 Date: Thu, 4 Jun 1998 15:46:07 -0400 (EDT) From: Steve Cheng Sender: steve@maxt3m45.ipoline.com To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <19980604134841.30684@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"d9jiw2.0.yB3.9clTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2531 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 4 Jun 1998, Andrew Apted wrote: > > (modified if necessary to allow non-GPL plugins) > > Not necessary. The plugins are dynamically loaded, so there's no > problem. (Just like non-GPL modules can be used on Linux). The only > thing would be to distribute non-LGPL plugin code separately from the > main LibGGI code. Not so. RMS recently raised a ruckus by stating that GPL code cannot be linked to non-GPL modules, which is true, legally. Supposedly the law doesn't distinguish between statically-linked and dynamically-linked modules. But this point is moot of course, because this is LGPL and not GPL. (Non-GPL Linux kernel modules are possible even though Linux is GPL'd because of an exception.) // Steve e-mail: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Thu Jun 4 14:51:41 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA25514; Thu, 4 Jun 1998 14:51:37 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA01147; Thu, 4 Jun 1998 14:54:21 -0700 Resent-Date: Thu, 4 Jun 1998 14:54:21 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3576BE93.A8D8071E@ebc.ericsson.se> Date: Thu, 04 Jun 1998 17:34:43 +0200 From: Marcus Sundberg Reply-To: e94_msu@e.kth.se X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: EvStack - slight move... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"3mtKX3.0.BH.7UnTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2537 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com James A Simmons wrote: > > > Well, that's the bastard about the current KGI build scheme. > > What we really need is some sort of `monitor class' that > > you can insert first, then say for a system with a VGA > > monitor on a S3, a Samsung Syncmaster GLsi 17" on another > > S3 card, and another VGA monitor on a Matrix, you could: > Yes I have a idea. I have notice with the newer kernels that > you have to insmod the head module then hardware specific modules. > Such as sound we have to load sound.o then sb.o or adlib.o. Also we have > to consider if people want to compile this into the kernel instead of > as a module (you never know). So for the module we could have > # insmod ggidrv.o > # insmod timelist.o display = 0; > # insmod multisync.o display = 1; > # insmod S3.o display = 0; > # insmod millenium.o display = 1; > > If you have a card that supports two monitors (Matrox does). Then > > #insmod ggidrv.o > #insmod timelist.o display = 0; > #insmod multisync.o display = 1; > #insmod millenium.o display = 0,1; The idea of modularising stuff is good. But also note that every module takes at least one page of memory. If we can fit all the monitor drivers in 4KB there's no reason to split them up into separate modules. And why should it be neccesary to have different monitor modules at all? Why not make a generic one? Admitedly I'm no expert on monitor timings, but as far as I can tell a multisync driver that can handle several timing intervals and intervals where min == max would be a superset of both monosync and timelist drivers. If that's not true, please enlighten me on this. //Marcus From ggi-develop-request@eskimo.com Thu Jun 4 14:55:16 1998 Return-Path: Received: from mx2.eskimo.com (root@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA25520; Thu, 4 Jun 1998 14:54:47 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA28386; Thu, 4 Jun 1998 13:08:11 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 13:08:11 -0700 (PDT) Date: Thu, 4 Jun 1998 16:05:58 -0400 (EDT) From: Steve Cheng Sender: steve@maxt3m45.ipoline.com Reply-To: Steve Cheng To: ggi Mailingliste Subject: Re: libggi: palettes In-Reply-To: <199806040838.KAA23950@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Z04RR2.0.Lx6.ewlTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2532 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 4 Jun 1998, Hartmut Niemann wrote: > 2) The size of the palette can be determined by the bits-per-pixel value > ONLY, which is only part of the directbuffer API. > The ggi_graphtype contains this information, 'cypted', too. > So we could document the macro in internal.h: > > #define VIS_FB_BPP(vis) (vis->info.fb.bpp) > > as 'the' one option to determine the bpp value of the display, > or define some macro/function that returns the bpp from the graphtype. > > my favourite: unsigned int ggiVisualBpp(vis). > > IMHO an application should be able to find out whether it runs on > black-and-white, 16, 256 or >30000 colours. > Why does an non-DB[*] application want to use bits-per-pixel? It may not be the same as actual bits-per-pixels consumed. And be careful of weird modes... I think it's better to classify according to "truecolor" or 'palette', and number of palette entries/colors. [*] If applications need more information, then use the DB specification. It is vigorously verbose. Whether a mode uses a palette would be communicated like this and applications don't need to check GetPalette() == OK. > 3) The hardest part: Do we want to guarantee the palette to contain > anything on start? > On the one hand it would simplify some applications that don't care > too much, if one can assume that there is a reasonable default > that contains (e.g.) at least the 8 basic colours in two shades each. > > for X it would be best not to mess too much with the palette > (bad flicklering), but if you put a 2:2:2 color cube > (as opposed to the 3:3:2 cube used currently) into the last 64 elements > of the standard palette, this would improve things a lot because the main > colours of the display (background, borders ...) wouldn't change every > time you activate the GGI window. > > There were many voices that said: no default at all, > but I would like to propose that the palette is guaranteed to have > at least > white, black, green, blue, red, yellow, magenta, cyan > So that small applications don't need to set it, if all they do is a red > border around white text on black background. I don't think we should demand a default because it is somewhat dependent on the target (e.g. X should minimize flashing), and the target may have some good reasons[*] to provide some other colors. I think targets should try to provide these 'standard' colors, but it's not absolutely necessary. However, if the target (using the term loosely here) is in a palettized mode, then GetPalette should not give bogus values (it should really match what the palette is currently, without setting it first.) However, I'm told that X cannot get the current palette and implement this correctly; could someone clarify? [*] VNC has a fix-colormap message to allow the client to set its own colormap which the server will use. > 4) An idea popped into my mind, when collecting this: > Currently we specify the s parameter to define where to load values. > WHat about this: > If you specify s==GGI_AUTO, the target will itself choose a place > in the palette for you. > Reason: > If you know at program startup, that you will need n different colours, > you set these n colours in the palette and don't care where. > Only very few programs will set the palette more than once AND want > to retain old values. > For a windowing environment it could very well make sense to assign > positions 0 to 20 to the window manager, > 30 to 100 to app1, and 101 to 200 to app2. So if we > leave this assignment to the library, it *might* help. > And if someone doesnt want to implement fancy strategies, > if (s==GGI_AUTO) s=0; > is all enhancements necessary. Agree. Sorry if this has been said by the other replies, but I'm in a hurry now and want to make sure my voice is heard :) Otherwise treat it as a "me too" post or vote. // Steve e-mail: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Thu Jun 4 15:13:48 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA25544; Thu, 4 Jun 1998 15:13:46 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA20534; Thu, 4 Jun 1998 13:06:31 -0700 Resent-Date: Thu, 4 Jun 1998 13:06:31 -0700 Date: Thu, 4 Jun 1998 16:10:58 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase Reply-To: MenTaLguY To: ggi-develop@eskimo.com Subject: ggiPut[sc] and HW fonts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Id8JV1.0.d05.1vlTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2533 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com First off, I feel that it's necessary to point out that that ggi already has a ggi_font structure defined to parallel the kgi_font structure. See the following code from ggi/include/ggi/font.h: -- snip -- typedef uint32 isochar; typedef uint16 unicode; typedef struct { isochar sym; unsigned int pos; } ggi_cellinfo; struct kgi_fontinfo { ggi_uint positions; /* number of positions defined */ ggi_uint default_pos; /* fontpos to use as default */ ggi_uint map_direct[8]; void *cellinfo[256]; /* map info for iso -> fontpos */ isochar inversemap[256]; /* map info for fontpos -> iso */ }; struct kgi_font { ggi_uint height, width; /* distance between chars */ ggi_uint dx, dy; /* size of bitmap per char */ ggi_uint base; /* base line */ struct kgi_fontinfo *info; /* iso10646 <-> fontpos mapping */ void *data; /* bitmaps */ }; typedef struct kgi_fontinfo ggi_fontinfo; typedef struct kgi_font ggi_font; -- snip -- It seems to me that given that these structures already exist, it would probably be most appropriate to add a few calls: ggi_error ggiGetFixedFont(ggi_visual_t vis, ggi_font **fontpp); ggi_error ggiFreeFixedFont(ggi_font *fontp); ggi_error ggiSetFixedFont(ggi_visual_t vis, ggi_font *fontp); and a macro for use internally (i.e. by targets): VIS_FONT(vis) In response to what Hartmut said, it's not unreasonable to expect ggiPut[cs] to rely on any HW font support present, and doing so will not add too much complexity, as the targets will deal with any HW-specific complexities/emulation as they usually do. Since KGI already has a concept of HW font representation suited exactly for this purpose, and it's been declared for use with LibGGI as well, we may as well use it. Also keep in mind that, like it or not, ggiPut[cs] will be forced to use the HW font in text modes. Please note that I'm not suggesting that ggiPut[cs] should have to deal with mapping -- I'm not, and it shouldn't. But there should be mapping information stored with the font and retreivable with it so that it can be made availible to a higher-level API that could map the characters appropriately before calling ggiPut[cs] if it so desired. If we add text.x and text.y fields to the ggi_mode structure (measured in pixels), in conjunction with this it should cover all our needs for describing font weirdness for some time. (ggi_font measurements are, of course, in dots). Additionally, we'll be able to freeze the LibGGI API without having to worry about this. -=MenTaLguY=- From ggi-develop-request@eskimo.com Thu Jun 4 15:29:51 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA25576; Thu, 4 Jun 1998 15:29:49 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA18942; Thu, 4 Jun 1998 15:34:43 -0700 Resent-Date: Thu, 4 Jun 1998 15:34:43 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Use of shared pages/SYSV SHMs To: ggi-develop@eskimo.com Date: Thu, 4 Jun 1998 23:41:26 +0200 (MET DST) In-Reply-To: from "Brian Julin" at Jun 3, 98 11:37:38 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"1vRBV2.0.5d4.t3oTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2538 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > How does the use of SYSV SHMs or other shared page mechanisms > for a kernel<->userspace interface shake out on various > architectures/OSs? I ruled out SHM, because 1. It is SYSV specific. Enough for a religious war on the BSD platforms. 2. You need to enable it at kernel compile time. 3. Not all systems have it 4. You would need to patch the kernel in a third place, while mmap() comes naturally with the fs stuff. MMAP does the same, and is much less bothersome. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Thu Jun 4 15:38:36 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA25590; Thu, 4 Jun 1998 15:37:52 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA00640; Mon, 1 Jun 1998 08:49:18 -0700 Resent-Date: Mon, 1 Jun 1998 08:49:18 -0700 Message-Id: <199806011549.LAA02684@pepsi.visus.com> Subject: Re: offtopic/rant/rant/linux expo To: core@mirus.fr Date: Mon, 1 Jun 1998 11:49:11 -0400 (EDT) Cc: ggi-develop@eskimo.com, jmcc@ontv.com Reply-To: jmcc@ontv.com In-Reply-To: from "Emmanuel Marty" at Jun 1, 98 04:05:42 pm From: Jason McMullan Content-Type: text Resent-Message-ID: <"ELY3J2.0.j9.yriSr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2419 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com 'Emmanuel Marty wrote with particular insight...' > As for knowing where the linear framebuffer is, that's not a problem, VBE > 1.2 and up (so that includes 2.0) provide a physical pointer to the lfb, > when present on a board. I remember using it a LONG time ago, when I was > writing an S3 driver (the chip 80% of the gamers PCs used at the time :) > under DOS/4G for some famous game.. Had the framebuffer mapped and all :) Yep - I have the interrupt listing from VGADOC in hand... > > How hard is it to modify to handle multi-head? That's what most > > people that were interested in EvStack were looking for... > > Well, the abstract console works exactly like the regular one (except for > the removed vga code) i.e it renders fg_console. I still think it would be > easier to modify the abstract console to do multihead and work with > EvStack scrollers, than rewriting a console driver from scratch.. Well, we've already done that.... the console driver is _already_ completely rewritten in the current EvStack code. The work is done. > Note that fbcon/abstract consoles don't prevent you from doing graphics > multihead, just console multihead. Which is quite annoying and one of the > big EvStack advantages still, I agree.. And _text_ multihead is what a lot of the EvStack-interested people want.... > Oh - don't bother then. It was to get it to run on 2.1.101 or so (based on > my changes to get it to run on 2.1.92 - did the changes I did to > /dev/graphics to come with kernel changes, work fine for you, by the way > ?). If you got it to run on 2.1.103, that's all we need. There's some changes to the mmap() subsustem (ie, that the file struct is propery associated with the vme entries - finally!) but other than that it's pretty much the same... I need to run my mmap() test programs over it to be sure I got it right... > > > I hope it helps you to start over again ? First thing to do is to make > > > sure it runs on 2.1.103 with, say, the VGA driver, I guess. Then we know > > > we have some platform to start moving the drivers. > > > > Already got that on my personal machine's tree... > > Hmm, I never got the VGA driver to run on my GGI guinea pig machine at > home after you had done the necessary rewrite of most of the code :) Can > you prepare a working tree (for 2.1.103 and all) ? The CVS server will be > back up early this week, as soon as Andreas came back home from the > expo and I have news from him. Sure. If the CVS tree isn't up by Wednesday, I'll have my own CVS tree up on coke.visus.com. We can't hold out on this. > > And the SEMANTICS of the mode setting functions - there are > > now VERY strict rules you have to follow w/respect to memory allocation > > so that I can cleanly remove drivers & do multi-head. The changes I > > make to the driver subsystem weren't just aestetic - they're meant > > for cleaner driver code, too. > > Oh - sorry if it sounded like that. I didn't mean that - just that there > should really be a mininum changes to the drivers, as they are already > buggy enough :) But of course, changes that allow for smaller/cleaner > code, are welcome. The tm and textop changes are necessary for damned-simple `did this mode change' tests - a memcmp() will do it. The textop stuff is so that you can memcpy() a struct and get it up. > > Not a problem - and your vm86() code would also be useful for > > VESA 1.0 support with banked VGA cards. > > Yup, I was thinking about that too. Quite slower, but at least it will get > XGGI to work on any x86 board in the universe. We already have > the banked memory manager, we just need the bios calls. Yep. I was thinking that is you `held onto' the first 64K of memory on boot-up (need to modify setup.S) and used that and the BIOS area at C000 in your vm86() calls, the BIOS would work without too much hassle. > Good idea! I like it, because it doesn't try to second-guess the > programmer, and you can add as many interrupt sources and actions > performed then, and combine them as much as you like. Sort of a small > programming language, like the code the copper understands :) > > Oh - I can't believe I forgot to ask : how did the Expo go ? :-) I > haven't heard of Andy yet, and I'm very impatient to know :) How did > Andy and your talk go ? Tell us all :) The expo went very well. Our talks were well-received, and we got a lot of response from people. The PowerPC maintainer is shipping me a machine to do the PowerPC port, free of charge. He is _very_ intrested in multihead and ADB support. Linus (I believe) is waiting for us to have a user-base. As he said in his keynote, what he really dislikes is when people add stuff to the kernel, then don't maintain it - it then falls into his lap. Case in point - the UMSDOS patches. Nifty idea, lot of people liked it, it got into the kernel, then wham - no maintainer. It was _really_ obvious during the dentry development.... -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Thu Jun 4 17:05:20 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA25726; Thu, 4 Jun 1998 17:05:18 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA18179; Thu, 4 Jun 1998 17:09:03 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 17:09:03 -0700 (PDT) Date: Fri, 5 Jun 1998 00:57:19 +0200 (CEST) From: Emmanuel Marty X-Sender: core@gate.local To: ggi-develop@eskimo.com Subject: New e-mail address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"FHQKt3.0.xR4.USpTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2539 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello all, This is just to inform you that my main email address will be core@suntech.fr from now on (replacing mirus); of course if you write to the list, or to the ggi-project.org alias, it will be sent to the new place automatically, but just wanted to inform you in case you write to me private mail and use the fr one by habit :) -- Emmanuel From ggi-develop-request@eskimo.com Thu Jun 4 17:22:59 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA25740; Thu, 4 Jun 1998 17:22:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id RAA04549; Thu, 4 Jun 1998 17:23:12 -0700 Resent-Date: Thu, 4 Jun 1998 17:23:12 -0700 Message-Id: <199806050025.CAA05904@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 05 Jun 1998 02:20:34 +0200 To: "Todd T. Fries" From: Emmanuel Marty Subject: CVS issues (was: Re: Unidentified subject!) Cc: ggi-develop@eskimo.com In-Reply-To: <19980604191032.46822@fries.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"vEuCJ2.0.x61.jfpTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2540 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello, >But the whole point behind having a cvs 'Repository' aka code safe is to >be able to go back to an earlier revision of what once was. If we are >starting all over this totally defeats the purpose of a cvs repository. >If files need to be moved, simply: > mv filename filename.new; cvs rm filename; cvs commit Look, I have known about CVS administration side for about 24 hours. I'm spending some of my time and bandwidth to set one up as we need one right now. >If you want 'two versions' of the code tree, sounds like we want to do >what FreeBSD is doing and have a stable and a development branch and merge >things between the two using cvs to do it's thing instead of manually >hand-merging patches from 9 different directions at once. I will have >nightmares if we really do have 2 trees. I would be seriously pleased, if you could explain in detail and rather urgently, what has to be done to use CVS properly, so that we can have a stable and development branch. >Vger already has this. I know - Geert commited numerous fbcon patches for me there. The question was, should we do yet another kernel devel tree for evstack ? I hope not. >> I think you should ditch from the files you commit to CVS, all drivers >> besides the VGA one, as they all are outdated and aren't ported anyway >> (better start over from the Dali ones). > >*sigh* I'm almost glad I don't know enough about the video driver aspects >to write a driver. My brother's been spending the better part of a year >just getting to textmode and now he'll have to start over again? I sincerely >hope that this is the last major overhaul ggi has that is not an organized >'ok change this function name to that, or this structure to that' that is >simple and easy to implement. Requiring re-enginerring and re-work of >previously spent efforts only tires people and de-spirits the population. You haven't read the above paragraph correctly. I'm not suggesting that we re-write drivers, and I am the one who has been defending that we keep the changes to a minimum when moving to degas, because I do care about all developers who have put tremendous efforts into our project. What I was talking about, is that Jason has very outdated drivers in his source tree, because EvStack forked from Dali a long, long while ago. I only suggested that he ditches his old versions, which are just old Dali ones, and takes the newer from the current Dali tree, as the sentences say above. Fair enough? -- Emmanuel From ggi-develop-request@eskimo.com Thu Jun 4 18:25:25 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA25790; Thu, 4 Jun 1998 18:25:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA20757; Thu, 4 Jun 1998 18:23:55 -0700 Resent-Date: Thu, 4 Jun 1998 18:23:55 -0700 To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: EvStack drivers: Proposal Date: 5 Jun 1998 01:24:14 GMT Organization: OnTV Pittsburgh, L.P. Lines: 38 Sender: Jason McMullan Message-ID: <6l7hbu$irr$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"L8Tgl2.0.845.fYqTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2541 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Ok, here's the concepts for the migration of drivers to EvStack/Degas. Please note that the concepts of class/instance monitors, the proposed new GT_* bitflags, etc. will wait for EvStack 1.0 (~2-3 months) - right now we need to port the current Dali drivers. Option 1: If your driver already works: ------------------------------ You can either a) port it yourself (with the EvStack Driver Guide I'm writing up) or b) sit back and let me do the inital port. You can then test the driver and make bugfixes. Option 2: If your driver is still under development: ------------------------------------------- You should probably continue getting it to work under the Dali (GGI 0.0.9) release. No need to have `false bugs' from porting a non-working driver. When the time comes, go to Option (1) Option 3: If your driver is basically skeleton code: ------------------------------------------- Follow the EvStack Driver Guide to complete your port. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Thu Jun 4 18:35:44 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA25797; Thu, 4 Jun 1998 18:35:42 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA23716; Thu, 4 Jun 1998 18:39:26 -0700 Resent-Date: Thu, 4 Jun 1998 18:39:26 -0700 Message-ID: <19980604193757.60947@fries.net> Date: Thu, 4 Jun 1998 19:37:57 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: KGI license? References: <199806031115.NAA27189@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199806031115.NAA27189@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Wed, Jun 03, 1998 at 01:15:50PM +0200 Resent-Message-ID: <"H-9XP1.0.Qn5.2nqTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2542 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, Jun 03, 1998 at 01:15:50PM +0200, Hartmut Niemann wrote: > I am not in charge, and my opinion is in no way 'official', > but if I recall correctly, this was resolved the following way: > > - drivers and software that is shipped together with some OS > like the kernel interfaces, will have the same license the > kernel has, i.e. GPL for Linux, BSD for *BSD. > (My conclusion: for proprietary OSs, this must read: a > license compatible with the OS license. Think BeOS.) > This can mean that the basic VGA driver is under BSD > license in the BSD tree and under GPL in the Linux tree, > but this is seen as no problem. > - add-ons that are distributed separately (like Permedia driver...) > can have any license the author wants. > - I am not sure about the kernel-independent parts (libggi*). GPL? > Andy? It is quite an interesting statement. I made many contributions to libggi, infact, the makefile system currently in place! And nowhere did I ever put the GPL license. Somehow, though, in Makefiles all over sprung up a GPL license. This is a problem because I had hoped that libggi would be freely available under a BSD or something compatible license because otherwise it would remain a 'port' (for those non-bsd'ers it is a set of makefiles that allows compiling libs and apps that are not in the native tree) ... and severely hinder the kernel interface's popularity .. perhaps even encourage a re-engineered libggi with a less restrictive license. That, IMHO would be an utter waste of time. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Thu Jun 4 18:37:32 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA25802; Thu, 4 Jun 1998 18:37:30 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA24672; Thu, 4 Jun 1998 18:41:47 -0700 Resent-Date: Thu, 4 Jun 1998 18:41:47 -0700 Message-ID: <19980604202043.41652@fries.net> Date: Thu, 4 Jun 1998 20:20:43 -0500 From: "Todd T. Fries" To: Emmanuel Marty Cc: ggi-develop@eskimo.com Subject: Re: CVS issues (was: Re: Unidentified subject!) References: <19980604191032.46822@fries.net> <199806050025.CAA05904@orb.suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199806050025.CAA05904@orb.suntech.fr>; from Emmanuel Marty on Fri, Jun 05, 1998 at 02:20:34AM +0200 Resent-Message-ID: <"ZC-de.0.N16.OpqTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2543 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, Jun 05, 1998 at 02:20:34AM +0200, Emmanuel Marty wrote: > Look, I have known about CVS administration side for about 24 hours. > I'm spending some of my time and bandwidth to set one up as we need one > right now. Thanka! Now that I know what is going on .. I was wondering why this was happening! > >If you want 'two versions' of the code tree, sounds like we want to do > >what FreeBSD is doing and have a stable and a development branch and merge > >things between the two using cvs to do it's thing instead of manually > >hand-merging patches from 9 different directions at once. I will have > >nightmares if we really do have 2 trees. > > I would be seriously pleased, if you could explain in detail and rather > urgently, what has to be done to use CVS properly, so that we can have > a stable and development branch. Okey. I am fries on any irc network you wanna pick, save DAlnet (I am fr1es there) .. including the ggi-project server. Feel free to irc with me .. > I know - Geert commited numerous fbcon patches for me there. The question > was, should we do yet another kernel devel tree for evstack ? I hope not. So do I. As long as we have sufficient pipelines to the vger repository (since the ggi repository is having a core development team anyway, might as well have a core ggi developer in charge of the 'gateway' to vger as well). > >> I think you should ditch from the files you commit to CVS, all drivers > >> besides the VGA one, as they all are outdated and aren't ported anyway > >> (better start over from the Dali ones). > > > >*sigh* I'm almost glad I don't know enough about the video driver aspects > >to write a driver. My brother's been spending the better part of a year > >just getting to textmode and now he'll have to start over again? I sincerely > >hope that this is the last major overhaul ggi has that is not an organized > >'ok change this function name to that, or this structure to that' that is > >simple and easy to implement. Requiring re-enginerring and re-work of > >previously spent efforts only tires people and de-spirits the population. > > You haven't read the above paragraph correctly. I'm not suggesting that > we re-write drivers, and I am the one who has been defending that we keep > the changes to a minimum when moving to degas, because I do care about > all developers who have put tremendous efforts into our project. What I > was talking about, is that Jason has very outdated drivers in his source > tree, because EvStack forked from Dali a long, long while ago. I only > suggested that he ditches his old versions, which are just old Dali > ones, and takes the newer from the current Dali tree, as the sentences > say above. > > Fair enough? Ooops sorry. You're right. I definately misread! -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Thu Jun 4 19:04:49 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA25824; Thu, 4 Jun 1998 19:04:45 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA07812; Thu, 4 Jun 1998 19:09:25 -0700 (PDT) Resent-Date: Thu, 4 Jun 1998 19:09:25 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Current Mode negotiation To: ggi-develop@eskimo.com Date: Fri, 5 Jun 1998 00:22:32 +0200 (MET DST) In-Reply-To: from "Elladan" at Jun 4, 98 01:55:21 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"b_bZT2.0.uv1.IDrTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2544 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I think it should go a bit beyond simply being selectable. The system > should favor standard refresh rates unless there's some specific reason to > use something different. This is handled by the monitor driver. Use monosync for those sick digital control beasties. (I have one, too, now ... whine ::-( ) CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Thu Jun 4 21:17:04 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA25881; Thu, 4 Jun 1998 21:17:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id VAA19929; Thu, 4 Jun 1998 21:18:15 -0700 Resent-Date: Thu, 4 Jun 1998 21:18:15 -0700 To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: First pass at KGI docs... Date: 5 Jun 1998 04:18:11 GMT Organization: OnTV Pittsburgh, L.P. Lines: 32 Sender: Jason McMullan Message-ID: <6l7ri3$mp5$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"GcpYx2.0.ds4.06tTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2545 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I've put my first pass at the new EvStack - KGI documentation on the cvs.ggi-project.org CVS repository (degas/kgi/doc/*) Primary develpers, take a look at it. I should have it fully fleshed out and publicly availible by Friday night. Also - what about changing the name of EvStack to GGI Console - it's easier to say, integrates well into the ``thought namespace'' of our project, and doesn't confuse people (``here's a nickle, son - don't reimplement STREAMS...'') Andreas: Here's my final ideas for how to put my code on the repo: EvStack/drivers -> degas/kgi/drivers EvStack/patches/Linux -> degas/console/Linux EvStack/utils/EvTest -> degas/console/Test EvStack/drivers/input -> degas/console/input (EvStack filters) -> degas/console/filters EvStack includes -> degas/include/ggi/console KGI Includes -> degas/include/ggi/kgi How's that? -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Thu Jun 4 21:32:06 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA25935; Thu, 4 Jun 1998 21:32:04 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id VAA25577; Thu, 4 Jun 1998 21:35:46 -0700 Resent-Date: Thu, 4 Jun 1998 21:35:46 -0700 Date: Thu, 4 Jun 1998 23:33:17 -0500 (CDT) From: "Edward S. Marshall" To: "Todd T. Fries" Cc: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <19980604193757.60947@fries.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"CEfXn2.0.7F6.UMtTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2546 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 4 Jun 1998, Todd T. Fries wrote: > It is quite an interesting statement. I made many contributions to > libggi, infact, the makefile system currently in place! And nowhere did > I ever put the GPL license. Somehow, though, in Makefiles all over sprung > up a GPL license. This is -really- something that needs to get cleared up ASAP before more cooks enter the picture. May I suggest that during the IRC session, the developers hammer out something regarding a licensing scheme that pleases everyone in the core development team? A licensing problem will follow GGI forever. Normally, I'm an advocate of GPL/LGPL, but in the case of KGI, it -really- should be under the BSD license. libggi, being in userspace, would probably be good for LGPL (or BSD as well). Libraries shouldn't be GPL, or you'll almost immediately lose commercial application support. -- -------------------. emarshal at logic.net .--------------------------------- Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/ Linux labyrinth 2.1.101 #2 SMP Sun May 10 22:34:20 GMT 1998 i586 unknown 11:25pm up 7 days, 45 min, 2 users, load average: 0.00, 0.00, 0.00 From ggi-develop-request@eskimo.com Fri Jun 5 00:48:09 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA26104; Fri, 5 Jun 1998 00:48:07 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA01898; Fri, 5 Jun 1998 00:45:19 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 00:45:19 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806050742.JAA24233@cip8.e-technik.uni-erlangen.de> Subject: libggi API: frames, z-Buffers and so on To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Fri, 5 Jun 1998 09:42:59 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"YkxDZ3.0.XT.D8wTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2547 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! One more in the libggi API refining series (I want to send all out today, to have some discussion and thoughts possible before the big IRC.) Currently SetMode specifies one frame buffer. For double-and triple-buffering we need several buffers, which is currently implemented with larger virtual.y and setOrigin. This is (a) VGA-centric (not everybody supports setOrigin) and (b) even where it works not necessarily optimal. We don't have a possibility to allocate additional buffers on the graphics board ram (and, for the archive, in main memory - - think AGP cards with textures in main memory). Andy suggested that he will chnange the libggi *implementation* to allow to override the setmode calls, so I propose to - not deal at all with Z-Buffers, texture buffers and so on in libggi. Double-buffering OTOH is quite basic and affects ALL graphics primitives. so i propose to - add support for multiple frame buffers (of equal size and organisation) into libggi. As accessing the ggi_mode struct is documented and a frames element defined, I propose - not to change the ggi_mode struct and document to use the frames field to indicate the number of frames needed, and - not to change the current set*Mode calls. This means you can access this feature only thru the setMode call, not thru the simplified setTextMode... calls, but it minimizes OTOH API changes that have to be backported to existing applications. As Andy said there will be the possibility to write enhanced checkMode calls in other libraries, we don't have to stuff everything into the base library right now. I propose that the frames are numbered 0..(num-1). I propose that after mode setting number 0 is the current screen for display and writing/reading. I propose the following four calls for switching the frame: - ggi_error ggiSetDisplayFrame(vis, int frameno) - ggi_error ggiSetDrawingFrame(vis, int frameno) - int ggiGetDisplayFrame(vis) - int ggiGetDrawingFrame(vis) The latter two will probably be seldom used, but are really easy to implement and make the API somewhat orthogonal. And for subroutines it might come *very* handy to be able to read out the current frame. I suggest that Nathan's proposed ggiSetBuffMode will move to some advanced mode setting library. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Fri Jun 5 01:10:41 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA26169; Fri, 5 Jun 1998 01:10:39 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA23947; Fri, 5 Jun 1998 01:05:27 -0700 Resent-Date: Fri, 5 Jun 1998 01:05:27 -0700 From: Hartmut Niemann Message-Id: <199806050805.KAA24564@cip8.e-technik.uni-erlangen.de> Subject: libggi API: ggiInit/extensionInit To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Fri, 5 Jun 1998 10:05:13 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"gMYJl3.0.-q5.xQwTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2548 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Just to get this off my desk: There was some discussion about nested ggiInit() calls. - Will the first ggiExit terminate the library, or need they be nested *properly*, - will a secong ggiInit() be allowed?, will it have an effect? - If we nest them, should we give ggiExit a return value, and you can do (in an emergency exit routine) while (ggiExit() == 0) {} These questions are closely related to the way the libggi extension and init-exit code is done, so this should be decided on a technical level *only*. IMHO the user can live with either option, it only has to be documented properly. The most general solution would be, (most complicated, but leaves room for all possibilities, I hope) - multiple ggiInit() are allowed. - you need to pair them up with ggiExit(). For each ggiInit there must be one ggiExit. - ggiExit() returns 0 if a matching ggiInit existed, it returns -1 if it was superfluous. This allows the emergency exit above. - Currently only the first ggiInit would actually do something, all others will just increment some ggiINit count. - only the last (matched) ggiExit will do something, all the previos will just decrement the usage count. Do we need this? The alternative would be: allow exactly one init-exit pair. Wouldn't it? Technical reasons please. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Fri Jun 5 01:48:18 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA26218; Fri, 5 Jun 1998 01:48:16 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA15882; Fri, 5 Jun 1998 01:47:04 -0700 Resent-Date: Fri, 5 Jun 1998 01:47:04 -0700 From: Hartmut Niemann Message-Id: <199806050847.KAA25331@cip8.e-technik.uni-erlangen.de> Subject: libggi: Alpha values To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Fri, 5 Jun 1998 10:47:11 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"l00an2.0.1u3.72xTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2550 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! > There was the suggestion to enhance ggi_color, which currently holds > three shorts for r,g, and b, with an additional alpha value > (transparency). Chris Meadors asked this recently again. The discussion seems not to be whether or not to support alpha values, but where and how. Some people argued that it would be necessary to change ggi_color, some others support moving a ggi_rgba_color and alpha-aware drawing functions to some libggi2d. My concern is that having (software) Alpha support in each and every graphics routine will slow that down. Most applications won't need Alpha support, like graphical desktops or CAD. I would like not to include alpha support in our base library. The discussion is open, the decision won't be made in Erlangen anyway ... Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Fri Jun 5 01:48:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA26223; Fri, 5 Jun 1998 01:48:39 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA11887; Fri, 5 Jun 1998 01:46:32 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 01:46:32 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806050839.KAA25119@cip8.e-technik.uni-erlangen.de> Subject: libggi API: switch-away and switch-back To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Fri, 5 Jun 1998 10:39:18 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"kNmjN3.0.dv2.b1xTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2549 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! The question was: > What has to be done when a program is switched away (either the window > (in X) becomes inactive, or the VT is switched), and on re-activation? > This is currently not defined at all. > What are the options for each case? What are pros/cons? How can this > be implemented? > Is the application notified? How? Does it get a chance to save screen > content, does it need to? Time limit for that? I propose the following as default behaviour: - when a program is deactivated, *EVERYTHING* ( i mean: at least the complete screen content, the palette, the graphics context, z-Buffers, if any. everything) is saved _by_the_libggi_. - when the program is activated again, everything is resored. - All drawing requests are blocked while not active, so if the program does calculations, fine, if it draws: stop. Yes, this can mean storing 16 megs of screen content. But for most applications it is more reasonable to assume that the lib takes care of this, than that the application writer handles it right. The pausing of the program gives me some headaches, but it is surely complicated to allow drawing into the backside memory. Side note: We can't save screen content in Kernel, because it is (AFAIK) not possible to allocate *pageable* (and I think swapping out the screen content of a stopped application is not bad) from there. But we can trust the library, that it will react on a signal (sigwinch) in the intended way, i.e. malloc some memory, copy some stuff, then return. So this is a job for the hardware- depended libggi target implementations. --------------------------- For later we can enlarge the API by some means of telling the library: don't save the content, or don't restore anything. I think about something along the signal stuff: We define two Events (yes, exactly like mouse events. Actually ina windowing environment topping a window is nothing else) EventSwitchaway, gives you 100 ms for saving everything. EventSwitchawayFinal EventSwichBack The default handlers will be: Switchaway: save everything Switchawayfinal (that is the emergency in timeout cases, when the application doesn't return after 100ms of saving time) either kill or save yourself SwitchBack: restore. You can ggiEvAction(Switchaway,mysavehandler) or ggiEvAction(Switchaway,EvIGNORE) if you can repaint everything easily, you can't catch the SwitchawayFinal, you can ggiEvAction(Switchback,myscreenrestore), and maybe ggiEvAction(Switchaway,mysavehandler,DONTSTOP) But the default behaviour I proposed will allow a safe start, and these enhancements have to be implemented in a test version and tried and proven working, before we put them into the libggi or another API. --------------------- So can we agree on the default behaviour to be that the application can assume that everything is taken care of by the library? Hartmut. One more point. If this doesn't _work_ right now, no problem. Simply declare current behaviour as wrong and a bug, and then fix it. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Fri Jun 5 02:14:16 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA26263; Fri, 5 Jun 1998 02:14:14 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA19302; Fri, 5 Jun 1998 01:59:46 -0700 Resent-Date: Fri, 5 Jun 1998 01:59:46 -0700 From: Hartmut Niemann Message-Id: <199806050859.KAA25417@cip8.e-technik.uni-erlangen.de> Subject: libggi API: the display- prefix To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Fri, 5 Jun 1998 10:59:21 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_0t-C2.0.2j4.wDxTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2551 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! 1.12. Removing the "display-" prefix It was suggested to drop the "display-" prefix from all LIBGGI_DISPLAY parameters. There was a very easy solution suggested (editing libggi.conf), so it's the political question: with the prefix or not, allow both and recommend one, then which? Please read the comments on the web site: http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/ libggi/libggi-issues.html I don't know enough about the implementation to tell the technical differences, but from the user standpoint setenv LIBGGI_DISPLAY=KGI makes more sense to me. Remember: the libggi.conf is not exactly part of the API, but of the implementation. The display strings in the environment, ggiOpen and on possible command lines are part of the API. Applications will never (hopefully) access individual vendor- or helper- libraries, they will never issue such strings, and printing does not have to be really different from screen display. Why not LIBGGI_DISPLAY=postscript? Name one good name clash and I am convinced :-) Actually, some ggiOpen("printer",...) might be a good idea ?? Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Fri Jun 5 02:30:51 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA26276; Fri, 5 Jun 1998 02:30:50 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA15512; Fri, 5 Jun 1998 02:18:29 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 02:18:29 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806050916.LAA25754@cip8.e-technik.uni-erlangen.de> Subject: libggi: graphtypes To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Fri, 5 Jun 1998 11:16:05 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7urcD3.0.Fo3.ZVxTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2552 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com And here is he again ... graphtypes. The current scheme covers VGA and friends pretty well, but nothing else. There is a suggestion on the web site (long!) that would change the system more than a bit. I think the question is not whether to change the system we have. I think we all agree that it does not describe some modes we want to support. There is no easy solution. Currently we need (sometimes) the textual "GT_TEXT32" representations and have a macro for this. We could drop that (breaks testpattern, but who except me cares :-), then we can say - we will change the system and make it more flexible in the future. - we guarantee that GT_AUTO (we should separate it from GGI_AUTO IMHO) will work as before. - we guarantee that the current GT_xxxx will work as they did -- they will probably be some #defined values in some integral ggi_graphtype with a bitmap meaning, like Andrew suggested. This would mean a recompile of the application for the enhanced API, and a loss of binary compatibility. I'd pay the price. Or we do the hard work of defining a new scheme now. IMHO we need a more flexible system *in*libggi*, the question is when and how. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Fri Jun 5 03:03:13 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA26297; Fri, 5 Jun 1998 03:03:12 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id CAA00994; Fri, 5 Jun 1998 02:53:39 -0700 Resent-Date: Fri, 5 Jun 1998 02:53:39 -0700 From: Hartmut Niemann Message-Id: <199806050953.LAA26215@cip8.e-technik.uni-erlangen.de> Subject: libggi: (Memory) visual memory layout To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Fri, 5 Jun 1998 11:53:20 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"VduQ42.0.JF.Y0yTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2554 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Uuuuuii, this was a heated discussion too. This is the 'about' line. A memory visual will typically be used to draw in-memory and then transfer to some 'real' visual. If the memory layout (byte order ...) of this memory visual is exactly like the layout of the frame buffer, copying will be far faster than otherwise. There are about seven pages of comments, and I pick the idea I like most, from Peter Amstutz (shortened): We seem to be drawing towards a conclusion (at least in my mind) - I think we should add another entry to the ggi_mode structure for pixel layout. This layout is negotiated via ggiCheckMode() just like screen size and bit depth are now. Applications can ask for a specific pixel layout (RGB, or RGBA, or CMY, or YUV, or whatever else we think of) if it wants to, or just use GGI_AUTO, in which case it will have to somehow find out what pixel layout it actually got before using ggiPut/GetBox() and DirectBuffer. In fact DirectBuffer already sort of implements this - we just need to take it one step further and integrate it completly with the API. This is mainly for memory visuals, where the bit order or colour representation doesn't really make a difference (except that ggiMapColor needs heavy bit-shifting not only for one bit layout, but for several). But it might be handy for cards that have options, like rgb or grb sequence (don't know whether this exists). This is ONLY about how the bits in the ggi_pixel represent the color, not how the pixels are stored in memory. If we do add pixel_layout field to the mode struct, we can, when mode setting, specify a layout we want. So you can try to open a memory visual with the same layout the hardware display visual has, which will maximise crossblit speed. I propose: We add a ggi_pixel_layout type, (or do we have one already that fits?), add a pixel_layout field of this type to the mode struct. We do not change the mode functions now, so this feature will be accessible only thru the set/checkMode. For my reasons please read my proposal on the frames issue. I have no proposal on how this can be specified, and I doubt we can agree on one in June, so I propose further: - we do guarantee that pixel_layout is an integral type. - we propose that GGI_AUTO will work. Everything else must (IMHO) be postponed until we have some example implementation. NOTE: If we allow this for memory visuals, we can at least catch the cases where the graphics card (for a 16 bit more) is e.g. rrrrrrgggggbbbbb and the standard memory visual would be gggggrrrrrbbbbba instead, which would make crossblits a bitshifting nightmare, whereas it would not change much for the memory tagret if it said 'hey, I can do your format as easily, just put some more work into mapColor to speed up crossblits tremendously.' For now all targets would only accept GGI_AUTO as allowed value, and wouldn't change it, I suppose. What do you think? Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Fri Jun 5 03:22:51 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA26309; Fri, 5 Jun 1998 03:22:45 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id CAA27987; Fri, 5 Jun 1998 02:29:53 -0700 Resent-Date: Fri, 5 Jun 1998 02:29:53 -0700 Date: Fri, 5 Jun 1998 11:30:47 +0200 (DFT) From: Massimiliano Ghilardi To: ggi Mailingliste Subject: Re: libggi API: switch-away and switch-back In-Reply-To: <199806050839.KAA25119@cip8.e-technik.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"d1vYe3.0.Mq6.DgxTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2553 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Hartmut Niemann wrote: > Hi! > The question was: > > What has to be done when a program is switched away (either the window > > (in X) becomes inactive, or the VT is switched), and on re-activation? > > > This is currently not defined at all. I (and other people too) already wrote a lot of messages on this topic. I think there is enough agree that while it is fine to SIGTSTP some apps when they are switched away (games for example) other apps must keep running (X servers, computational apps like povray...). In the latter case two possibilities are available: 1) discard any drawing request when not focused 2) draw on a memory buffer when not focused and blit it back to graphic card when re-focused another thing is that you cannot rely on a program (or on libGGI) to react to a switch-away signal, save the screen contents by its own and have the kernel delay the switch-away till the app confirms it, or the switch-away could be deadlocked if the app misbehaves. My proposal was: libGGI mallocs() some memory and gives the pointer to kernel saying "save screen contents here on VC switch" so the memory is USER-allocated (pageable) but the copy is done by the kernel, not to have to wait for the application's collaboration. Massimiliano Ghilardi From ggi-develop-request@eskimo.com Fri Jun 5 03:45:51 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA26325; Fri, 5 Jun 1998 03:45:49 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA21056; Fri, 5 Jun 1998 03:37:20 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 03:37:20 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3577C9DC.95CACDE2@ebc.ericsson.se> Date: Fri, 05 Jun 1998 12:35:08 +0200 From: Marcus Sundberg Reply-To: e94_msu@e.kth.se X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: libggi: Alpha values References: <199806050847.KAA25331@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"TEZJb2.0.u85.UfyTr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2555 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > > Hi! > > There was the suggestion to enhance ggi_color, which currently holds > > three shorts for r,g, and b, with an additional alpha value > > (transparency). Chris Meadors asked this recently again. > > The discussion seems not to be whether or not to support alpha > values, but where and how. > Some people argued that it would be necessary to change ggi_color, > some others support moving a ggi_rgba_color and alpha-aware > drawing functions to some libggi2d. > > My concern is that having (software) Alpha support in each and every > graphics routine will slow that down. > Most applications won't need Alpha support, like graphical > desktops or CAD. > I would like not to include alpha support in our base library. > > The discussion is open, the decision won't be made in Erlangen anyway ... Of course the base libggi routines should not use Alpha values! But I don't see how that prevents us from adding a "short alpha" to the ggi_color struct. Then we have all options open to add alpha support where needed. (And we also end up with a properly aligned struct...) //Marcus From ggi-develop-request@eskimo.com Fri Jun 5 03:46:20 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA26333; Fri, 5 Jun 1998 03:46:18 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA21720; Fri, 5 Jun 1998 03:44:37 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 03:44:37 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806051041.MAA25585@sunserver1.rz.uni-duesseldorf.de> Subject: Re: libggi: Alpha values In-Reply-To: <199806050847.KAA25331@cip8.e-technik.uni-erlangen.de> from Hartmut Niemann at "Jun 5, 98 10:47:11 am" To: ggi-develop@eskimo.com Date: Fri, 5 Jun 1998 12:41:55 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"F1XpV2.0.GJ5.KmyTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2556 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > The discussion seems not to be whether or not to support alpha > values, but where and how. > Some people argued that it would be necessary to change ggi_color, > some others support moving a ggi_rgba_color and alpha-aware > drawing functions to some libggi2d. > > My concern is that having (software) Alpha support in each and every > graphics routine will slow that down. > Most applications won't need Alpha support, like graphical > desktops or CAD. > I would like not to include alpha support in our base library. Yes. I second that. It doesn't have mixing, so why should it have Alpha. Leave that to LibGGI2D. CU,ANdy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Fri Jun 5 03:48:35 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA26344; Fri, 5 Jun 1998 03:48:34 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id DAA06378; Fri, 5 Jun 1998 03:47:26 -0700 Resent-Date: Fri, 5 Jun 1998 03:47:26 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806051047.MAA25774@sunserver1.rz.uni-duesseldorf.de> Subject: Re: libggi API: ggiInit/extensionInit In-Reply-To: <199806050805.KAA24564@cip8.e-technik.uni-erlangen.de> from Hartmut Niemann at "Jun 5, 98 10:05:13 am" To: ggi-develop@eskimo.com Date: Fri, 5 Jun 1998 12:47:04 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"VIBLf.0.WZ1.zoyTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2557 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Just to get this off my desk: > > There was some discussion about nested ggiInit() > calls. > > - Will the first ggiExit terminate the library, or need they > be nested *properly*, They need proper nesting. This is needed for programs that load "helper modules". they will be using the same copy of LibGGI not knowing if it is already initialized. Thus they need to Init it and Exit it. If These funxctions were not nested, the exit would kill the calling applications access to LibGGI. > - will a secong ggiInit() be allowed?, will it have an effect? Yes. No effect but counting the number of invocations. > - If we nest them, should we give ggiExit a return value, and > you can do (in an emergency exit routine) > > while (ggiExit() == 0) > {} Yes. probably. > These questions are closely related to the way the libggi extension > and init-exit code is done, so this should be decided on a > technical level *only*. > IMHO the user can live with either option, it only has to be > documented properly. I have changed Extension semantic to conform to the same scheme. It is in the new repository. > Do we need this? Yes. See above. It help greatly with nested extensions, too. Check the example code in the newest LibGGI snapshot. CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Fri Jun 5 04:02:50 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA26362; Fri, 5 Jun 1998 04:02:49 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id DAA08045; Fri, 5 Jun 1998 03:53:48 -0700 Resent-Date: Fri, 5 Jun 1998 03:53:48 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3577CDEF.A0AD3229@ebc.ericsson.se> Date: Fri, 05 Jun 1998 12:52:31 +0200 From: Marcus Sundberg Reply-To: e94_msu@e.kth.se X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: libggi API: switch-away and switch-back References: <199806050839.KAA25119@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"76w5k3.0.Wz1.wuyTr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2558 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > > Hi! > The question was: > > What has to be done when a program is switched away (either the window > > (in X) becomes inactive, or the VT is switched), and on re-activation? > > > This is currently not defined at all. > > > What are the options for each case? What are pros/cons? How can this > > be implemented? > > > Is the application notified? How? Does it get a chance to save screen > > content, does it need to? Time limit for that? > > I propose the following as default behaviour: > > - when a program is deactivated, *EVERYTHING* ( i mean: at least > the complete screen content, the palette, the graphics context, > z-Buffers, if any. everything) is saved _by_the_libggi_. Argh! No! This should _not_ be the default. The default should be to save nothing. This is beacause every braindead application will not bother to change the default, and thus running a bunch of gfx apps will quickly fill up RAM. And this will cause swapping, which will cause the 100ms to be exceeded - and thus we'll have a lot of swapping for nothing... //Marcus From ggi-develop-request@eskimo.com Fri Jun 5 04:47:43 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA26409; Fri, 5 Jun 1998 04:47:42 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA26331; Fri, 5 Jun 1998 04:42:17 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 04:42:17 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806051139.NAA27732@cip8.e-technik.uni-erlangen.de> Subject: libggi: get/put-buffers To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Fri, 5 Jun 1998 13:39:38 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"bUrMV2.0.JR6.NczTr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2559 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This stirred most ... The basic question was: ggiGet/PutHLine and friends have no documented buffer layout. The only guarantee is that the size of the buffer is width*height*sizeof (ggi_pixel). This is bad because one can't prepare a buffer 'offline' and then blit onto the screen. It looks like (from many posts I read) that we have to - make the buffer layout as similar as possible to the main visual layout, for maximum speed. - not provide any conversion routines in the base libggi API. - give some access to the buffers. So we need to disclose the buffer layout to the program. --------------- Question: can we safely assume that the buffer is pixelwise linear, that means that pixels are stored with increasing x next to each other, and that first the lines with lower y , then those with higher y are stored, i.e. a rectangle with a width of three and a height of two will be stored pixel (0,0) (1,0) (2,0) (0,1) (1,1), (2,1) in that order? This is reasonable for all bufferlayouts I have seen so far, including the Apple ][, because the interlacing that is done sometimes for the screen memory can not be used for this type of buffer. If we guarantee that, only the pixel format has to be defined, and this has far less posibilities than the direct-buffer struct can hold, and using a directbuffer struct for communicating this information is overkill. There are two possibilities: - The pixel layout used for Get/PutHline and friends is guaranteed to be the same as for the frame buffer [1]. Then either the direct buffer or the enhanced mode struct, see my mail about the (memory) visual memory layout, carry this information. - The pixel layout differs from the frame buffer pixel layout, and then we need some means for querying the buffer layout. Maybe we would define some buffer structure to pass. I have no idea how to do that. All buffer layouts I know are either 2**n bits per pixel (with little/big-endian differences) or k bytes per pixel (with k usually 3*2**i) for packed true color mode. In all of these cases we can use the frame buffer pixel layout for the buffers too. Some shifting might occur, but IMHO can't be avoided (e.g. a line from a 4bpp (packed) display starting at an odd X coordinate). For other 'strange' modes (did somebody recently talk about 5-bit planar modes on Amiga?) we would probably pad the internal pixel representation to full bytes anyway, wouldn't we? ----------------- I propose - we guarantee that one pixel consumes either k bytes (packed true colour) or 2**n bits (covering 1,2,4-bpp modes). If the hardware has other sizes (like 30 bits), they will be padded. (This is IMHO needed to reduce bit-shifting) - we guarantee that the pixels are stored linearly on all targets. - the exact pixel layout will define - how many bits per pixel - what colour model - what bits are where (rrrrgggg as oposed to ggggrrrr) and will be part of the mode struct. - Convenience routines that pack/unpack complete buffers from/to ggi_colors and/or ggi_pixels are written. I don't make a proposal whether they should go into libggi or somewhere else. [1] Of course if a target doen's have a frame buffer this whole discussion does not apply, and the implementor is free to pick one pixel layout he likes. Comments? Hartmut. Puuh. This was the last open item in my issues list. I hope we can sort out everything to at least most people's satisfaction. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Fri Jun 5 04:59:18 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA26422; Fri, 5 Jun 1998 04:59:16 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA15955; Fri, 5 Jun 1998 04:45:15 -0700 Resent-Date: Fri, 5 Jun 1998 04:45:15 -0700 Message-ID: <002d01bd907f$ba1ab240$0c0a0a0a@MASSACRE> From: "David Waite" To: Subject: Re: libggi API: switch-away and switch-back Date: Fri, 5 Jun 1998 07:42:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0305.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0305.0 Resent-Message-ID: <"QqQVB1.0.Bv3.AfzTr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2560 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com -----Original Message----- From: Massimiliano Ghilardi > >I (and other people too) already wrote a lot of messages on this topic. >I think there is enough agree that while it is fine to SIGTSTP some apps >when they are switched away (games for example) other apps must keep >running (X servers, computational apps like povray...). In the latter case >two possibilities are available: >1) discard any drawing request when not focused >2) draw on a memory buffer when not focused and blit it back to graphic card > when re-focused > Ohhh no.. All modern graphical servers (MacOS,X,Windows 2.0 onwards?) have the idea of a 'paint' message telling the program to redraw itself. I normally keep four consoles up and running, imagining that I had graphical software running on each of them (a cd player, top /w a pie chart, a program I am working on and XGGI) I would definately need to double the amount of memory in my computer to get this working at all. There is really no way to know better than the author of the program how the state needs to be saved when there is a switchaway. The program may be smart enough to redraw itself (I can imagine 98% of programs easily being made this smart), therefore not needing a memory swap. The program may not be smart enough to be abel to redraw its state, but doesn't care that its former state was lost. (ie screen savers). Or, the program could need its data and have no way to recover it.. (umm.. I'm thinking.. a 2 second fractal viewer?) >another thing is that you cannot rely on a program (or on libGGI) >to react to a switch-away signal, save the screen contents by its own >and have the kernel delay the switch-away till the app confirms it, >or the switch-away could be deadlocked if the app misbehaves. >My proposal was: libGGI mallocs() some memory and gives the pointer to kernel >saying "save screen contents here on VC switch" so the memory is USER-allocated >(pageable) but the copy is done by the kernel, not to have to wait for the >application's collaboration. Pretty good, actually. However, keep in mind that except for SVGALIB ports (and these never saved video memory on context switches for me anyways), 99% of programs won't need this, simply because they can be written to not need it. -David Waite From ggi-develop-request@eskimo.com Fri Jun 5 05:58:24 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA26466; Fri, 5 Jun 1998 05:58:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA27425; Fri, 5 Jun 1998 05:50:15 -0700 Resent-Date: Fri, 5 Jun 1998 05:50:15 -0700 X-Authentication-Warning: acc7.ac.cc.md.us: acom192.ac.cc.md.us [208.214.13.192] didn't use HELO protocol Message-ID: <357817CF.306B@stu.ac.cc.md.us> Date: Fri, 05 Jun 1998 09:07:43 -0700 From: Chris Meadors X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: libggi: Alpha values References: <199806050847.KAA25331@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"mFcSz1.0.Di6.3c-Tr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2561 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > > The discussion seems not to be whether or not to support alpha > values, but where and how. > Some people argued that it would be necessary to change ggi_color, > some others support moving a ggi_rgba_color and alpha-aware > drawing functions to some libggi2d. After I posted my orginal question I thought about it a bit, and created my own rgba struct. And pretty much convinced myself that I don't want to see ggi_color modified (see my thinking below). I would like to see the rgba struct defined in libggi (to keep everything standard), but you are probally right in thinking the functions that make use of it should be placed in libggi2d. Also, the alpha value needs to be 16 bit just like the rgb values also, right now 'alpha' is 8 bit. > My concern is that having (software) Alpha support in each and every > graphics routine will slow that down. Agreed, plus an extra uint16 tacked onto ggi_color would mean 2 extra bytes per pixel, which becomes at lot of extra garbage to be moving around if it isn't being used by the current application. > Most applications won't need Alpha support, like graphical > desktops or CAD. I am an alpha channel nut and I think it should be used everywhere, but most people don't agree. :) > I would like not to include alpha support in our base library. Again, I think the definations for the alpha channel should be in the base library, but the actual funtions to deal with it in libggi2d (and 3d). Right now the code I'm playing with has its own defination, a struct of 4 uint16's. Then I have some (slow, poorly written) routines that combine layers of bit planes with alpha channels into a single bit plane of ggi_color pixels, then this single layer is rendered to the screen. If libggi2d is going to include alpha blending only in special functions that are "alpha enabled", there will probally need to be alpha version of just about every draw fuction. If sprite based funtions get added to the lib, I definatly want to see alpha aware versions of them too. So a sprite with alpha values can be rendered on a background with alpha values. > The discussion is open, the decision won't be made in Erlangen anyway ... Well now I have a reason to be at the IRC conference just in case this topic comes up. :) From ggi-develop-request@eskimo.com Fri Jun 5 06:13:57 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA26478; Fri, 5 Jun 1998 06:13:55 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA03927; Fri, 5 Jun 1998 06:15:37 -0700 Resent-Date: Fri, 5 Jun 1998 06:15:37 -0700 Date: Fri, 5 Jun 1998 15:16:26 +0200 (DFT) From: Massimiliano Ghilardi To: ggi-develop@eskimo.com Subject: Re: libggi API: switch-away and switch-back In-Reply-To: <002d01bd907f$ba1ab240$0c0a0a0a@MASSACRE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"DqWku1.0.9z.uz-Tr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2562 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, David Waite wrote: > >In the latter case two possibilities are available: > >1) discard any drawing request when not focused > >2) draw on a memory buffer when not focused and blit it back to graphic > > card when re-focused > > > > Ohhh no.. All modern graphical servers (MacOS,X,Windows 2.0 onwards?) have > the idea of a 'paint' message telling the program to redraw itself. I > normally keep four consoles up and running, imagining that I had graphical > software running on each of them (a cd player, top /w a pie chart, a program > I am working on and XGGI) I would definately need to double the amount of > memory in my computer to get this working at all. Infact I said there are two possibilities. 1) also means the program will have to redraw the screen by themselves which is exactly what you say. 2) is just the other possibility: for raytracers, fractal viewers etc. you can either backbuffer or use this, letting libGGI backbuffer for you. I was not implying 2) should be the default, rather it must NOT be the default because it eats tons of RAM :) > There is really no way to know better than the author of the program how the > state needs to be saved when there is a switchaway. The program may be smart > enough to redraw itself (I can imagine 98% of programs easily being made > this smart), therefore not needing a memory swap. The program may not be > smart enough to be abel to redraw its state, but doesn't care that its > former state was lost. (ie screen savers). Or, the program could need its > data and have no way to recover it.. (umm.. I'm thinking.. a 2 second > fractal viewer?) Infact it is the app that decides what behaviour it wants using libGGI calls... Massimiliano Ghilardi From ggi-develop-request@eskimo.com Fri Jun 5 08:42:43 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA26546; Fri, 5 Jun 1998 08:42:40 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA02723; Fri, 5 Jun 1998 08:44:46 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 08:44:46 -0700 (PDT) Date: Fri, 5 Jun 1998 11:47:01 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <199806051512.LAA05292@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"3FjXS.0.Ng.d91Ur"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2563 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 4 Jun 1998, Todd T. Fries wrote: > It is quite an interesting statement. I made many contributions to > libggi, infact, the makefile system currently in place! And nowhere did > I ever put the GPL license. Somehow, though, in Makefiles all over sprung > up a GPL license. That's bad. If you had the copyright to the code, you should have been asked. Of course, it's also your responsibility to put appropriate copyright notices in the code you write. > This is a problem because I had hoped that libggi would be freely > available under a BSD or something compatible license because otherwise it > would remain a 'port' (for those non-bsd'ers it is a set of makefiles that > allows compiling libs and apps that are not in the native tree) ... and > severely hinder the kernel interface's popularity .. perhaps even > encourage a re-engineered libggi with a less restrictive license. That, > IMHO would be an utter waste of time. Explain in more detail, please ... few of us are native BSDers ... if you look carefully, LGPL2 is what is used in libggi, not GPL2. And LGPL2 isn't especially restrictive. If LGPL2 hinders _libggi_ on BSD, then I'd say it'd be BSD's licensing that's overly restrictive. You have actually read and understood the LGPL2, and how it's different from GPL2 and GPL1, right? GPL1 was heinously restrictive, and I'm afraid a lot of people haven't bothered to (seriously) look at the newer versions. I'm probably not giving you enough credit, though. Explain this ports thing some more. Now, I can certainly see how GPL would be an issue for _KGI_ (as distinct from libggi) -- KGI actually gets linked with the BSD-licensed kernel. As far as KGI goes, I think a dual GPL/BSD licensing scheme would be appropriate to be compatible with BSD kernel licenses. And I think that's what was decided on ... wasn't it? -=MenTaLguY=- From ggi-develop-request@eskimo.com Fri Jun 5 09:13:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA26603; Fri, 5 Jun 1998 09:13:27 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA08547; Fri, 5 Jun 1998 09:05:53 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 09:05:53 -0700 (PDT) From: Andrew Apted Message-ID: <19980605233708.24557@ajax.netspace.net.au> Date: Fri, 5 Jun 1998 23:37:08 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi API: the display- prefix Reply-To: ggi-develop@eskimo.com References: <199806050859.KAA25417@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806050859.KAA25417@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Fri, Jun 05, 1998 at 10:59:21AM +0200 Resent-Message-ID: <"3WjVZ2.0.O52.UT1Ur"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2564 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut writes: > 1.12. Removing the "display-" prefix > > It was suggested to drop the "display-" prefix from all LIBGGI_DISPLAY > parameters. There was a very easy solution suggested (editing > libggi.conf), so it's the political question: with the prefix or not, > allow both and recommend one, then which? > > Please read the comments on the web site: > http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/ > libggi/libggi-issues.html > > I don't know enough about the implementation to tell the technical > differences, but from the user standpoint > setenv LIBGGI_DISPLAY=KGI > makes more sense to me. Yes. I think we should just allow both, by having both combinations in the libggi.conf file (as was suggested). The "preferred" version would be the one with the "display-" prefix, but they should be interchangeable. So long as we stick to the convention that all non-display sub-libraries start with "xxxx-" (note the hyphen), there won't be any clashes. > Applications will never (hopefully) access individual vendor- or > helper- libraries, they will never issue such strings, and printing > does not have to be really different from screen display. > Why not LIBGGI_DISPLAY=postscript? > Name one good name clash and I am convinced :-) > Actually, some ggiOpen("printer",...) might be a good idea ?? Adding support for printers in LibGGI would be crazy IMHO. We've got a big enough job already just supporting and maintaining all the various display targets that are out there, let alone chucking in all the printers in the world too. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 5 09:34:38 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA26642; Fri, 5 Jun 1998 09:34:34 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA03442; Fri, 5 Jun 1998 09:24:48 -0700 Resent-Date: Fri, 5 Jun 1998 09:24:48 -0700 Date: Fri, 5 Jun 1998 12:29:17 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi Mailingliste Subject: Re: libggi API: switch-away and switch-back In-Reply-To: <199806051512.LAA05347@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"H43di2.0.Sr.Dl1Ur"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2567 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Hartmut Niemann wrote: > Hi! > The question was: > > What has to be done when a program is switched away (either the window > > (in X) becomes inactive, or the VT is switched), and on re-activation? > > > This is currently not defined at all. > > > What are the options for each case? What are pros/cons? How can this > > be implemented? > > > Is the application notified? How? Does it get a chance to save screen > > content, does it need to? Time limit for that? > > I propose the following as default behaviour: > > - when a program is deactivated, *EVERYTHING* ( i mean: at least > the complete screen content, the palette, the graphics context, > z-Buffers, if any. everything) is saved _by_the_libggi_. > - when the program is activated again, everything is resored. > - All drawing requests are blocked while not active, so if the > program does calculations, fine, if it draws: stop. > > Yes, this can mean storing 16 megs of screen content. But for most > applications it is more reasonable to assume that the lib takes > care of this, than that the application writer handles it right. It would be good if this were included in libggi, but there are some applications that really DON'T need to save the screen at all (i.e. because they redraw every second anyhow -- fullscreen games come to mind). There should, IMO, be two selectable behaviors: 1. the program gets SIGTSTP on switchaway, and SIGCONT+SIGWINCH on switchback -- libggi doesn't save the screen. (a lot of games would be just fine with this) 2. libggi saves the screen, but the application also gets the above signals 3. libggi saves the screen, and switches to a backing bitmap while switched away -- the application doesn't notice the difference and can keep drawing on the backing bitmap. The target would temporarily overload its own stubs as necessary to accomplish the switch to drawing on the backing store. (like synchronous mode, it's the least efficient, but is probably the best default in terms of 'dumb' usage -- and hey, if you're just prototyping something real quick, it's very convenient) Not all targets have a concept of a destructive switching away/back, but for those that don't, it'd just be safe to imagine that they never switch away. I'd say this would be an excellent item for some more GGIFLAGs for use with ggiSetInfoFlags. Say, GGIFLAG_AUTOSAVE. Actually, there are really two behaviors that need to be defined. One would be saving on destructive switchaway (or window hidden or whatever), and the other would be stopping on lost focus. Maybe GGIFLAG_WAITFOCUS for stopping until focus is regained, by the aforementioned signals? One question is: should GGIFLAG_AUTOSAVE and GGIFLAG_WAITFOCUS be allowed to both be unset, and if so, what behavior should it indicate when they are both off? > The pausing of the program gives me some headaches, but it is > surely complicated to allow drawing into the backside memory. > > Side note: > We can't save screen content in Kernel, because it is (AFAIK) not > possible to allocate *pageable* (and I think swapping out the > screen content of a stopped application is not bad) from there. > But we can trust the library, that it will react on a signal > (sigwinch) in the intended way, i.e. malloc some memory, copy > some stuff, then return. So this is a job for the hardware- > depended libggi target implementations. Yeah, you're definitely right. > --------------------------- > For later we can enlarge the API by some means of telling > the library: don't save the content, or don't restore > anything. I think about something along the signal stuff: > > We define two Events (yes, exactly like mouse events. Actually > ina windowing environment topping a window is nothing else) > EventSwitchaway, gives you 100 ms for saving everything. 100ms is probably (almost always) long enough, but it's just a race condition waiting to happen, even so... dunno any ways around imposing a limit like that, though. > EventSwitchawayFinal > EventSwichBack > The default handlers will be: > Switchaway: save everything > Switchawayfinal (that is the emergency in timeout cases, when > the application doesn't return after 100ms of saving time) > either kill or save yourself > SwitchBack: restore. > > You can ggiEvAction(Switchaway,mysavehandler) > or ggiEvAction(Switchaway,EvIGNORE) if you can repaint everything easily, > you can't catch the SwitchawayFinal, you can > ggiEvAction(Switchback,myscreenrestore), > and maybe > ggiEvAction(Switchaway,mysavehandler,DONTSTOP) EvAction? wouldn't that be more appropriate in LibGII? But yes, the notification would have to be asynchronous _somehow_... hence the signals I was thinking earlier. -=MenTaLguY=- From ggi-develop-request@eskimo.com Fri Jun 5 09:35:39 1998 Return-Path: Received: from mx2.eskimo.com (root@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA26647; Fri, 5 Jun 1998 09:35:34 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA08703; Fri, 5 Jun 1998 09:06:38 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 09:06:38 -0700 (PDT) From: Andrew Apted Message-ID: <19980606012806.36456@ajax.netspace.net.au> Date: Sat, 6 Jun 1998 01:28:06 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi: (Memory) visual memory layout Reply-To: ggi-develop@eskimo.com References: <199806050953.LAA26215@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806050953.LAA26215@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Fri, Jun 05, 1998 at 11:53:20AM +0200 Resent-Message-ID: <"cauYp.0.n72.5U1Ur"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2566 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut writes: > Uuuuuii, this was a heated discussion too. > > This is the 'about' line. > A memory visual will typically be used to draw in-memory and then > transfer to some 'real' visual. If the memory layout (byte order ...) > of this memory visual is exactly like the layout of the frame buffer, > copying will be far faster than otherwise. On my machine, FWIW, the cost of the conversion is about 2x the cost of doing a memcpy (I posted some benchmarks a while ago that showed this). The coversions were rgb555 -> bgr555, and rgb555 -> byte swapped. I reckon this figure comes about because writing to the PCI bus is quite slow compared to the processor speed, and there is time 'left over' to do the simple shifting, anding, and oring. Just speculation though... > I propose: We add a ggi_pixel_layout type, (or do we have one > already that fits?), add a pixel_layout field of this type to the mode > struct. This sounds good to me. We have something that already fits the bill (perfectly IMHO) : "ggi_common_plb_setup" in the DirectBuffer headers. > NOTE: > If we allow this for memory visuals, we can at least catch the > cases where the graphics card (for a 16 bit more) is e.g. > rrrrrrgggggbbbbb and the standard memory visual would be > gggggrrrrrbbbbba instead, which would make crossblits a What about aaaarrrrgggghhhh mode ? Oh yes, I forgot that is already a get/put buffer format. :-)) Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 5 09:47:31 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA26652; Fri, 5 Jun 1998 09:47:26 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA13790; Fri, 5 Jun 1998 09:38:14 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 09:38:14 -0700 (PDT) From: Andrew Apted Message-ID: <19980606011047.45578@ajax.netspace.net.au> Date: Sat, 6 Jun 1998 01:10:47 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi API: switch-away and switch-back Reply-To: ggi-develop@eskimo.com References: <199806050839.KAA25119@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806050839.KAA25119@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Fri, Jun 05, 1998 at 10:39:18AM +0200 Resent-Message-ID: <"qgkWq.0.9N3.mx1Ur"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2568 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut writes: > The question was: > > What has to be done when a program is switched away (either the window > > (in X) becomes inactive, or the VT is switched), and on re-activation? > > > This is currently not defined at all. > > > What are the options for each case? What are pros/cons? How can this > > be implemented? > > > Is the application notified? How? Does it get a chance to save screen > > content, does it need to? Time limit for that? > > I propose the following as default behaviour: > > - when a program is deactivated, *EVERYTHING* ( i mean: at least > the complete screen content, the palette, the graphics context, > z-Buffers, if any. everything) is saved _by_the_libggi_. IMHO, No. The graphics context (I'm talking VIS_GC(vis)) doesn't need saving, also LibGGI should probably keep a local copy of the palette (many targets already do) so that wouldn't need saving either. But the screen contents (including auxiliary buffers) shouldn't be saved, *only* if specifically requested by the application. The request mechanism could be: ggiSetInfoFlags(vis, GGIFLAG_SAVESCREEN); but I agree that most programs either don't care (games) or can just redraw themselves. > - All drawing requests are blocked while not active, so if the > program does calculations, fine, if it draws: stop. This can't be done. The kernel could switch away the console (and thus invalidate the mmapping) while the program was in the middle of the ggiDrawBox() function (for example), or doing it's own thang using DirectBuffer access. Thus the program must always block. > For later we can enlarge the API by some means of telling > the library: don't save the content, or don't restore > anything. I think about something along the signal stuff: > > We define two Events (yes, exactly like mouse events. Actually > ina windowing environment topping a window is nothing else) The best way IMHO is to just send something like a "cmdSwitchedBack" command event when the console is switched back. This tells programs to redraw the screen contents, and also that any state about input devices that the program had calculated (e.g. what modifier keys are currently pressed) is now invalid and the program should resort to it's startup assumptions (e.g. no modifier keys pressed). Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 5 09:50:00 1998 Return-Path: Received: from mx2.eskimo.com (root@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA26657; Fri, 5 Jun 1998 09:49:56 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA08652; Fri, 5 Jun 1998 09:06:25 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 09:06:25 -0700 (PDT) From: Andrew Apted Message-ID: <19980606002937.29151@ajax.netspace.net.au> Date: Sat, 6 Jun 1998 00:29:37 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi: graphtypes Reply-To: ggi-develop@eskimo.com References: <199806050916.LAA25754@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806050916.LAA25754@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Fri, Jun 05, 1998 at 11:16:05AM +0200 Resent-Message-ID: <"qErmG1.0.x62.uT1Ur"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2565 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut writes: > And here is he again ... > > graphtypes. > The current scheme covers VGA and friends pretty well, but nothing > else. > > There is a suggestion on the web site (long!) that would change the > system more than a bit. > > I think the question is not whether to change the system we have. > I think we all agree that it does not describe some modes we want > to support. And here is my previous proposal again :-). It is still very simple. Others have suggested much more complicated versions which specify things like Z buffer info, Alpha channels, planar modes, the exact number of bits for red, green and blue, etc.... I think all this either (a) doesn't belong in LibGGI, or (b) belongs as separate functionality from the ggiSetGraphMode() call. Very few programs really want something that specific, so it's OK by me if there is another more complicated scheme to keep these rare birds happy. Anyway, it works like this : the graphtype is the addtion of the depth value (e.g. 16) and a type value (e.g. GT_RGB), as follows: #define GT_DEPTH_MASK 0x00ff #define GT_TYPE_MASK 0xff00 #define GT_INDEXED 0x0100 #define GT_RGB 0x0200 #define GT_GREYSCALE 0x0400 #define GT_TEXT 0x0300 For compatibility, we define the following : #define GT_1BIT (GT_INDEXED + 1) #define GT_4BIT (GT_INDEXED + 4) #define GT_8BIT (GT_INDEXED + 8) #define GT_15BIT (GT_RGB + 16) /* yup, that's 16 */ #define GT_16BIT (GT_RGB + 16) #define GT_24BIT (GT_RGB + 24) #define GT_32BIT (GT_RGB + 32) #define GT_TEXT16 (GT_TEXT + 16) #define GT_TEXT32 (GT_TEXT + 32) This allows some nice things : GT_GREYSCALE + N : an N bit greyscale mode. Can easily be emulated by a target by actually using GT_INDEXED + N, and setting the palette accordingly. GT_RGB + 8 : an RGB 3:3:2 mode. Can easily be emulated by a target by actually using GT_INDEXED + 8, and setting the palette accordingly. GT_TEXT + 8 : a simple 8 bit text mode, like a terminal that doesn't support color attributes. Some notes: - The GT_* values above are still mutually exclusive. It doesn't make sense to me to combine any of them. I know some cards can use a CLUT when in 24 bit modes -- but this doesn't make it an INDEXED mode. [Such a feature could be detected (if not through DirectBuffer) by trying ggiSetPaletteVec() and see if it fails]. - It would be nice to be able to say "give me GT_RGB+16 or higher", but the same thing can be accomplished in the slightly harder way: trying each of 16, 24, and 32 bit modes until one succeeds. > This would mean a recompile of the application for the > enhanced API, and a loss of binary compatibility. I'd pay the price. IMHO binary compatibility is _not_ an issue right now. Everything (LibGGI, KGI drivers, ...) is still a moving target. When we reach version 1.0.0 :-), that's when we should start worrying about maintaining binary compatibility. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 5 10:23:57 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA26665; Fri, 5 Jun 1998 10:23:51 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA00808; Fri, 5 Jun 1998 10:22:52 -0700 Resent-Date: Fri, 5 Jun 1998 10:22:52 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: KGI license? To: ggi-develop@eskimo.com Date: Fri, 5 Jun 1998 19:16:28 +0200 (MET DST) In-Reply-To: from "Edward S. Marshall" at Jun 4, 98 11:33:17 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Jl54_3.0.TB.ab2Ur"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2572 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > [ Licensing ] > This is -really- something that needs to get cleared up ASAP before more > cooks enter the picture. May I suggest that during the IRC session, the > developers hammer out something regarding a licensing scheme that pleases > everyone in the core development team? O.K. - Can we all agree on the following : 1. All parts of GGI, that are to be patched into, linked to, or somehow otherwise incorporated into another piece of software should use the licensing policy of the appropriate piece of software, or a compatible one which is likely to be accepted by the authors of the modified software. This means GPL for Linux kernel patches, new files and such, BSD for BSD-patches etc., evteually commercial licenses on SUNOS patches or something like this. 2. All parts, for which there seems no technical reason for not doing so, we should use BSD licensing in the version that says "give credits in the program _or_ accompanying documentation", to avoid that "having to flush messages over the screen" problem. 3. I'd like some parts, especially "stub" drivers and example code to be really "freeware". I.e. "do with that as you wish". I'd really like to move over to *BSD style licensing, because it gives me much less headaches regarding commercial drivers/apps/... I do not think that we will gain more drivers using GPL, so I think BSD licensing should do a better job. It still protects our intellectual property by requesting credit (see Eric S. Raymond, "Homesteading in the noosphere"), while getting us best possible driver support. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 5 11:11:07 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA26721; Fri, 5 Jun 1998 11:10:45 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA22873; Fri, 5 Jun 1998 11:12:01 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 11:12:01 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Tilman Vogel Newsgroups: local.ggi.develop Subject: Re: S3 864 anyone? Date: Fri, 05 Jun 1998 19:33:43 +0200 Organization: Tilmans Linux-Box Lines: 8 Message-ID: <35782BF7.B22266DA@altavista.net> References: NNTP-Posting-Host: bird.local.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 5 Jun 1998 17:33:43 GMT X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) Resent-Message-ID: <"Qnnqo.0.Hb5.iJ3Ur"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2573 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello, I have an Elsa Winner 1000 PRO (S3 Vision 864-P (rev 0)) board. I would test the driver if I got the code. Thank you! Tilman From ggi-develop-request@eskimo.com Fri Jun 5 12:08:32 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA26789; Fri, 5 Jun 1998 12:08:27 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA02504; Fri, 5 Jun 1998 12:04:30 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 12:04:30 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: libggi API: switch-away and switch-back Date: 5 Jun 1998 19:02:01 GMT Organization: OnTV Pittsburgh, L.P. Lines: 61 Sender: Jason McMullan Distribution: local Message-ID: <6l9fb9$bb9$1@butter.visus.com> References: <6l8bpr$t44$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"Q_Jkk3.0.wc.w44Ur"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2574 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote with confidence: > I propose the following as default behaviour: > - when a program is deactivated, *EVERYTHING* ( i mean: at least > the complete screen content, the palette, the graphics context, > z-Buffers, if any. everything) is saved _by_the_libggi_. > - when the program is activated again, everything is resored. > - All drawing requests are blocked while not active, so if the > program does calculations, fine, if it draws: stop. > Yes, this can mean storing 16 megs of screen content. But for most > applications it is more reasonable to assume that the lib takes > care of this, than that the application writer handles it right. Uhh, not quite. Under KGI VT switching is _immediate_: Here's how it should be done (and is implemented in EvStack (now to be called GGI Console)) : 1) VT switch request make by user 2) App gets SIGTSTP 3) All of the App's mmap() regions are now invalid - if the app want to use "display-memory" as a backbuffer, fine, otherwise any access to the visual will result in a SIGBUS ... ... 4) VT is switched make 5) Mode is restored by KGI/GGI Console 6) mmap() regions are restored 7) App gets SIGCONT, SIGWINCH 8) App restores it's CLUT 9) App redraws it's display Note that (8) and (9) can easily be handled by libGGI. > We define two Events (yes, exactly like mouse events. Actually > ina windowing environment topping a window is nothing else) > EventSwitchaway, gives you 100 ms for saving everything. > EventSwitchawayFinal > EventSwichBack > The default handlers will be: > Switchaway: save everything > Switchawayfinal (that is the emergency in timeout cases, when > the application doesn't return after 100ms of saving time) > either kill or save yourself > SwitchBack: restore. Nope - just redraw. No need to define extra events. Almost all games and a goodly percent of the applications that would want to use libGGI can handle their own repainting. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Fri Jun 5 12:35:30 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA26831; Fri, 5 Jun 1998 12:35:24 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA10280; Fri, 5 Jun 1998 12:32:32 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 12:32:32 -0700 (PDT) Date: Fri, 5 Jun 1998 15:30:00 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: libggi: (Memory) visual memory layout In-Reply-To: <199806050953.LAA26215@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"wX9H8.0.RW2.7V4Ur"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2575 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Hartmut Niemann wrote: > What do you think? This might be important enough to do now, as you said. Just please if we add a graphtype make it a ggi_u64 not anything smaller. Lotta info needs to go in there. -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 5 12:43:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA26843; Fri, 5 Jun 1998 12:43:46 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA14202; Fri, 5 Jun 1998 12:47:06 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 12:47:06 -0700 (PDT) Date: Fri, 5 Jun 1998 15:44:27 -0400 (EDT) From: Brian Julin To: e94_msu@e.kth.se cc: ggi-develop@eskimo.com Subject: Re: libggi API: switch-away and switch-back In-Reply-To: <3577CDEF.A0AD3229@ebc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"rEBi63.0.lT3.si4Ur"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2576 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Marcus Sundberg wrote: > Argh! No! > This should _not_ be the default. The default should be to save nothing. > This is beacause every braindead application will not bother to change > the default, and thus running a bunch of gfx apps will quickly fill up > RAM. And this will cause swapping, which will cause the 100ms to be > exceeded - and thus we'll have a lot of swapping for nothing... Perhaps not the default, but if not there should be a way to set this behavior in the _libGGI_ API. It is an intrinsically important feature, as we all can see by losing our pallette with Dali. This is the only API relevant point brought up so far IMO, thanks. -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 5 12:52:02 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA26849; Fri, 5 Jun 1998 12:51:47 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA22538; Fri, 5 Jun 1998 12:56:05 -0700 Resent-Date: Fri, 5 Jun 1998 12:56:05 -0700 From: wlfshmn@ramses.ml.org Date: Fri, 5 Jun 1998 21:55:40 +0200 (CEST) To: m.grimrath@tu-bs.de, jonas@ggi-project.org, ggi-develop@eskimo.com Subject: MGA Impression Chipsets. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"c_0FR2.0.aV5.Dr4Ur"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2577 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Greetings, As I have been following the ggi project at a distance for a while, I have come to realize it is the right thing to do (TM) and for that reason I have been been wading through a rather large collection of older graphics cards to see if there was any which did not yet possess any drivers, among these is my old favorite, the Matrox MGA Impression/Pro card. And as I would like to learn the art of coding a graphics driver, these seemed a good place to start. I'm now contacting you, since the card uses the IS-ATLAS chipset, wich is quite a bit like the Mystique and The Milleniums (And so are the IS-HELENA, IS-TITAN and IS-DUBIC I guess) so I just want to make sure none of you are already writing a driver for this card. If not, I would like a chance at writing such a thing. Johan Karlberg, No longer studying, unemployed and generally with too much spare time. From ggi-develop-request@eskimo.com Fri Jun 5 12:56:13 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA26856; Fri, 5 Jun 1998 12:56:10 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA24397; Fri, 5 Jun 1998 13:00:01 -0700 Resent-Date: Fri, 5 Jun 1998 13:00:01 -0700 Date: Fri, 5 Jun 1998 15:59:48 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: libggi: graphtypes In-Reply-To: <19980606002937.29151@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"FFdhI1.0.hy5.uu4Ur"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2578 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Andrew Apted wrote: > And here is my previous proposal again :-). It is still very simple. > Others have suggested much more complicated versions which specify > things like Z buffer info, Alpha channels, planar modes, the exact > number of bits for red, green and blue, etc.... I think all this either > (a) doesn't belong in LibGGI, or (b) belongs as separate functionality > from the ggiSetGraphMode() call. OK, to clarify on things since I was one of those people, I only wanted the field to be big enough so the calls from the stuff that "doesn't belong in libGGI" would fit without any footwork when libGGI2D and libGGI3D and other helper libs are written. So my system was meant to be spread over many libraries, with the #defines for the field values spread over their header files. Regardless of the end format, we need to agree on the LIBGGI #defines, nothing more; any changes in the values need only be resolved before a major release of a binary-only driver. So I'm happy limit discussion to the #define macros and not get into the format underneath right now, as long as we can agree to choose a large data size for the field, and only talk of the libGGI macros. You bring up some good points about manipulating macro values conveniently. What features should the libGGI macros have and how should they be called? -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 5 13:09:38 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26878; Fri, 5 Jun 1998 13:09:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA29362; Fri, 5 Jun 1998 13:13:03 -0700 Resent-Date: Fri, 5 Jun 1998 13:13:03 -0700 Sender: torgeir@eskimo.com Message-ID: <35782A98.E5E6E606@vertech.no> Date: Fri, 05 Jun 1998 17:27:52 +0000 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: KGI license? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"SVOyO2.0.j97._45Ur"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2581 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Edward S. Marshall wrote: > > but in the case of KGI, it -really- should be under the BSD license. Please remember that RMS himself advocates an X-style license instead of a BSD license, if things can't be under (L)GPL. This is because the BSD license requires some form of copyright notice be present and displayed when initializing/using the BSD-covered code. This is very annoying when there are 20+ copyright lines due to additions made by several authors. There was an article on slashdot if I remember correctly. -- Torgeir Veimo, Vertech AS, email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 From ggi-develop-request@eskimo.com Fri Jun 5 13:14:25 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26889; Fri, 5 Jun 1998 13:14:21 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA21307; Fri, 5 Jun 1998 13:12:09 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 13:12:09 -0700 (PDT) Date: Fri, 5 Jun 1998 15:40:49 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: libggi API: switch-away and switch-back In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"EwKvi2.0.hC5.F45Ur"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2580 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Massimiliano Ghilardi wrote: > My proposal was: libGGI mallocs() some memory and gives the pointer to kernel > saying "save screen contents here on VC switch" so the memory is USER-allocated > (pageable) but the copy is done by the kernel, not to have to wait for the > application's collaboration. We can't trust that the app is actually running libGGI -- it may be malicious and looking to exploit. We really need someone experienced to think the security aspects through. It may turn out that we can get away with allowing a sequence of libGGI<->kernel interactions by scheduling a cut-off IRQ that will return control to the kernel when time is up for the restore. The issues are: 1) We need this to be as fast as possible, so as few kernel<->user transitions as possible 2) We need this to be secure, so what are the implications of kernel<->user transitions? 3) But -- we don't want to bloat the drivers. 4) Kernel/libGGI need to ensure no data or status loss/corruption/ transfer to unauthorized. This includes SMP/threaded considerations. Things will probably weigh mostly in your proposed direction despite 3). However despite the solution/implementation, I think Hartmut is right in that it need not effect the API. LibGGI and/or KGI will "take care" of state saving. -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 5 13:15:06 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26894; Fri, 5 Jun 1998 13:15:02 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA23071; Fri, 5 Jun 1998 13:17:24 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 13:17:24 -0700 (PDT) Date: Fri, 5 Jun 1998 15:24:05 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: libggi API: switch-away and switch-back In-Reply-To: <199806050839.KAA25119@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"r-3Oy3.0.Be5.995Ur"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2583 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Hartmut Niemann wrote: > Yes, this can mean storing 16 megs of screen content. But for most > applications it is more reasonable to assume that the lib takes > care of this, than that the application writer handles it right. But not to assume a benevolent application, I'd tender. > We define two Events (yes, exactly like mouse events. Actually > ina windowing environment topping a window is nothing else) > EventSwitchaway, gives you 100 ms for saving everything. Make the 100ms configurable by root and I'm happy. Apps should check the mode during switchback, in case it has changed (e.g. docking station monitor removed or application somehow switched to another head.) If they aren't built to handle that, they should hang and wait for another switchaway cycle in hopes that it may become compatible again. Well written GGI apps will be able to handle resizes as they may be in an X window. But all that's not pertainant to the API face (is it?). KGI should clear all user data from the adaptor in-kernel, of course, for security reasons. > But the default behaviour I proposed will allow a safe start, and these > enhancements have to be implemented in a test version and tried > and proven working, before we put them into the libggi or another API. Yes, can anyone with experience post a customized tutorial on feasability/implementation of secure DMA transfers to userspace e.g. verifying pointers, swapping in physical memory, etc. for this? > So can we agree on the default behaviour to be that the application > can assume that everything is taken care of by the library? I'd agree. This easily sidesteps adding API for it, the only downside is that we are kind of promising to take care of even cases where apps want to store strange things unforseen. But worst case result of that is the driver libs end up with extra code. > One more point. If this doesn't _work_ right now, no problem. Simply > declare current behaviour as wrong and a bug, and then fix it. Yes, it will have to be a very well thought out/implemented design, and will probably take us some time. Sounds good (other posts I've read so far in this series sound perfectly reasonable as well.) -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 5 13:17:21 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26902; Fri, 5 Jun 1998 13:17:17 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA21018; Fri, 5 Jun 1998 13:11:12 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 13:11:12 -0700 (PDT) Date: Fri, 5 Jun 1998 16:03:06 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: libggi: (Memory) visual memory layout In-Reply-To: <19980606012806.36456@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"1M7S33.0.A85.O35Ur"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2579 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Andrew Apted wrote: > > NOTE: > > If we allow this for memory visuals, we can at least catch the > > cases where the graphics card (for a 16 bit more) is e.g. > > rrrrrrgggggbbbbb and the standard memory visual would be > > gggggrrrrrbbbbba instead, which would make crossblits a > > What about aaaarrrrgggghhhh mode ? Oh yes, I forgot that is already a > get/put buffer format. :-)) Oooh, Oooh -- Andy, put that on your humor page. ROTFL. -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 5 13:40:02 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26911; Fri, 5 Jun 1998 13:39:59 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA03575; Fri, 5 Jun 1998 13:41:16 -0700 Resent-Date: Fri, 5 Jun 1998 13:41:16 -0700 Date: Fri, 5 Jun 1998 16:41:14 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: WWW pages -- tester "application" form? In-Reply-To: <35782BF7.B22266DA@altavista.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Zws5f1.0.Zt.fV5Ur"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2584 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Tilman Vogel wrote: > Hello, > > I have an Elsa Winner 1000 PRO (S3 Vision 864-P (rev 0)) board. I would > test the driver if I got the code. Can we have a volunteer to log requests like this into a file of "potential testers"? The file should not be made publicly available since the people requesting may not want their e-mail address farmed out to just anyone (not that I'm suggesting hording testers so they don't get their attention drawn by competing graphics projects :-P ) GGI driver authors would be given the list of all potential testers when they feel ready to test. Also a form on the WWW pages for people wanting to test: 1) (Form entries for Contact info) 2) Decription of hardware/firmware/software/OS targets you would like to test (please see for a description of targets, for info on potentential hardware drivers, and concerning OSes being developed for.) 3) Is it OK for your contact information to be publicly available on our WWW pages? You may get solicitations from graphics projects/programmers/junk mailers not affiliated with GGI if we do. Check the fields that can be made public (checkbox for contact info fields). If you want your contact information treated rather confidentially, check the confidential fields here []. ...with the results mailed to said volunteer, and the volunteer remails them to appropriate developers if the requested code is being worked on already. Confidential info should only be mailed to developers considered "trusted" by the core team. This is a good (and helpful) job for any non-technical persons interested. A form like this might get us more testers as some people may have something against posting their contact info to the list, especially since junk mail spiders can get it from our archives, or they might be skating some legal thin ice. Anyway, now that I'm caught up on the list I'm going back to studying EvStacks. Hopefully if it's gentle to my virgin ass I'll see many of you on IRC tomorrow. -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 5 13:46:19 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26916; Fri, 5 Jun 1998 13:46:16 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA06192; Fri, 5 Jun 1998 13:47:48 -0700 Resent-Date: Fri, 5 Jun 1998 13:47:48 -0700 Date: Fri, 5 Jun 1998 16:14:59 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: libggi API: switch-away and switch-back In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Wxtt03.0.hV1.hb5Ur"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2585 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, MenTaLguY wrote: > It would be good if this were included in libggi, but there are some > applications that really DON'T need to save the screen at all. (i.e. because > they redraw every second anyhow -- fullscreen games come to mind). There > should, IMO, be two selectable behaviors: > > 1. the program gets SIGTSTP on switchaway, and SIGCONT+SIGWINCH on > switchback -- libggi doesn't save the screen. (a lot of games > would be just fine with this) > 2. libggi saves the screen, but the application also gets the above > signals > 3. libggi saves the screen, and switches to a backing bitmap while > switched away -- the application doesn't notice the difference > and can keep drawing on the backing bitmap. The target would > temporarily overload its own stubs as necessary to accomplish the > switch to drawing on the backing store. > (like synchronous mode, it's the least efficient, but is probably > the best default in terms of 'dumb' usage -- and hey, if you're > just prototyping something real quick, it's very convenient) 3) Might be promising a lot, when you have cards with things like STREAMS that are processing sent data in HW on the fly. The implementation could involve a full implementation of emulation of the hardware features :( Practical considerations might merit not promising 3) in the base libGGI. I think it would be a damn nifty feature and am all for it, but let's not lead app developers on with a promise that requires so much to deliver on. Attempting to set 3), if it is in the base libGGI API, should be a failable action if hardware/software does not permit. In fact, making 2) failable might be a subtle way to encourage people to write apps that can refresh their displays when possible. IMO it should go in but not be guaranteed, even with a "this is a bug and we'll fix it". P.S. Aren't there some systems with write-only framebuffers? -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 5 14:10:06 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA26977; Fri, 5 Jun 1998 14:10:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA14813; Fri, 5 Jun 1998 14:07:14 -0700 Resent-Date: Fri, 5 Jun 1998 14:07:14 -0700 Date: Fri, 5 Jun 1998 16:46:21 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: IRC thinko Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"3TSVo1.0.bc3.tt5Ur"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2587 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I meant Sunday. See you Sunday. Sorry. -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 5 14:15:32 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA26982; Fri, 5 Jun 1998 14:15:29 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA04077; Fri, 5 Jun 1998 13:58:05 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 13:58:05 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35780791.78F0933D@ebc.ericsson.se> Date: Fri, 05 Jun 1998 16:58:25 +0200 From: Marcus Sundberg Reply-To: e94_msu@e.kth.se X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: libggi: get/put-buffers References: <199806051139.NAA27732@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"LjQ6z2.0.b_.Kl5Ur"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2586 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > All buffer layouts I know are either 2**n bits per pixel (with > little/big-endian differences) or k bytes per pixel (with k > usually 3*2**i) for packed true color mode. In all of these cases > we can use the frame buffer pixel layout for the buffers too. > Some shifting might occur, but IMHO can't be avoided > (e.g. a line from a 4bpp (packed) display starting at an > odd X coordinate). Hmm, does anyone know of hardware that has a 2 or 4 bit chunky pixel layout? If not we should probably make every pixel use a whole byte for those modes too. > For other 'strange' modes (did somebody recently talk about > 5-bit planar modes on Amiga?) we would probably pad the internal > pixel representation to full bytes anyway, wouldn't we? Yes, old Amigas have 1,2,3,4,5 and 6 bpp planar modes. (Where 6 bpp may other be HAM or HalfBrite mode (a 32 color indexed mode with the 6th bit saying "this pixel should only be half as bright as normal" - thus doubling the colors to 64) New Amigas with the AGA chipset also support 7 and 8 bit planar modes. libggi should have a "planar" extension library which has all those functions that only makes sense on planar modes. > ----------------- > I propose > - we guarantee that one pixel consumes either k bytes (packed > true colour) or 2**n bits (covering 1,2,4-bpp modes). > If the hardware has other sizes (like 30 bits), they will be > padded. (This is IMHO needed to reduce bit-shifting) > - we guarantee that the pixels are stored linearly on all targets. > - the exact pixel layout will define > - how many bits per pixel > - what colour model > - what bits are where (rrrrgggg as oposed to ggggrrrr) > and will be part of the mode struct. Sounds reasonable. > - Convenience routines that pack/unpack complete buffers from/to > ggi_colors and/or ggi_pixels are written. > I don't make a proposal whether they should go into libggi > or somewhere else. We already have such functions: ggiPackColors and ggiUnpackPixels //Marcus From ggi-develop-request@eskimo.com Fri Jun 5 14:17:10 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA26987; Fri, 5 Jun 1998 14:17:07 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA29362; Fri, 5 Jun 1998 13:13:03 -0700 Resent-Date: Fri, 5 Jun 1998 13:13:03 -0700 Sender: torgeir@eskimo.com Message-ID: <35782A98.E5E6E606@vertech.no> Date: Fri, 05 Jun 1998 17:27:52 +0000 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: KGI license? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"SVOyO2.0.j97._45Ur"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2581 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Edward S. Marshall wrote: > > but in the case of KGI, it -really- should be under the BSD license. Please remember that RMS himself advocates an X-style license instead of a BSD license, if things can't be under (L)GPL. This is because the BSD license requires some form of copyright notice be present and displayed when initializing/using the BSD-covered code. This is very annoying when there are 20+ copyright lines due to additions made by several authors. There was an article on slashdot if I remember correctly. -- Torgeir Veimo, Vertech AS, email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 From ggi-develop-request@eskimo.com Fri Jun 5 14:44:56 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA27012; Fri, 5 Jun 1998 14:44:52 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA29973; Fri, 5 Jun 1998 13:14:21 -0700 Resent-Date: Fri, 5 Jun 1998 13:14:21 -0700 From: Hartmut Niemann Message-Id: <199806051520.RAA01506@cip8.e-technik.uni-erlangen.de> Subject: Re: libggi API: switch-away and switch-back To: ggi-develop@eskimo.com Date: Fri, 5 Jun 1998 17:20:30 +0200 (MESZ) In-Reply-To: <002d01bd907f$ba1ab240$0c0a0a0a@MASSACRE> from "David Waite" at Jun 5, 98 07:42:39 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9TLI71.0.TJ7.L65Ur"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2582 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Oh I love getting beaten up ... Hey, if you think that a repaint signal/event is the right default behaviour, then please, please suggest an API for it. You don't have to code it this weekend. I promise. Re: applications that need to work on back buffer. Applications that can not quickly repaint the screen will be so computing intensive, that we could argue they have to putpixel to the visual and at the same time to their own memory visual, thus ggiPutPixel(vis,x,y,ggiMapColor(vis,mycalculatedcolor)); ggiPutPixel(memvis,x,y,ggiMapColor(memvis,mycalculatedcolor)); They simply have to crossblit on a repaint request, and the additional computing time in normal operation will be neglegible compared to the overall computing time such an app will have. So: either drawing is fast, then redo it, or it's slow, then keep your own copy. Then the choice an application has is reduced to - stop on switchaway or - ignore drawing events on switchaway Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Fri Jun 5 14:56:16 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA27017; Fri, 5 Jun 1998 14:56:12 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA27581; Fri, 5 Jun 1998 14:50:31 -0700 Resent-Date: Fri, 5 Jun 1998 14:50:31 -0700 Sender: thomas@eskimo.com Message-ID: <357866CC.7ABD7EEF@gmx.de> Date: Fri, 05 Jun 1998 23:44:45 +0200 From: Thomas Tanner X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: libggi: Alpha values References: <199806050847.KAA25331@cip8.e-technik.uni-erlangen.de> <357817CF.306B@stu.ac.cc.md.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Rfvrt2.0.bk6.YW6Ur"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2588 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Chris Meadors wrote: > > I would like not to include alpha support in our base library. > Again, I think the definations for the alpha channel should be in the > base library, but the actual funtions to deal with it in libggi2d (and > 3d). Right now the code I'm playing with has its own defination, a > struct of 4 uint16's. Then I have some (slow, poorly written) routines > that combine layers of bit planes with alpha channels into a single bit > plane of ggi_color pixels, then this single layer is rendered to the > screen. There should be some alpha support in libggi. But not by adding an alpha channel to ggi_color but maybe by directbuffer and fallback functions like int ggiSetAlpha(ggi_visual_t vis, int x, int y, ggi_alpha alpha) int ggiGetAlpha(ggi_visual_t vis, int x, int y, ggi_alpha *alpha) The same applies for z-values. > If libggi2d is going to include alpha blending only in special functions > that are "alpha enabled", there will probally need to be alpha version > of just about every draw fuction. If sprite based funtions get added to > the lib, I definatly want to see alpha aware versions of them too. So a > sprite with alpha values can be rendered on a background with alpha > values. _Every_ drawing function of libggi2d supports alpha blending. Only the very necessary blitting functions are not implemented yet, and this will probably only happen after we have a more decent extension scheme and framebuffer interface. -- Thomas Tanner ----------------------------- email: tanner@gmx.de tanner@ggi-project.org web: http://home.pages.de/~tanner GGI: http://www.ggi-project.org From ggi-develop-request@eskimo.com Fri Jun 5 16:52:37 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA27192; Fri, 5 Jun 1998 16:52:34 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA10423; Fri, 5 Jun 1998 16:55:19 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 16:55:19 -0700 (PDT) Date: Fri, 5 Jun 1998 19:52:49 +0000 (GMT) From: Michael Funk X-Sender: mwfunk@foo.bar.com Reply-To: mwfunk@uncc.campus.mci.net To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <35782A98.E5E6E606@vertech.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"aXZNI2.0.eY2.ZL8Ur"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2589 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Torgeir Veimo wrote: > Edward S. Marshall wrote: > > > > but in the case of KGI, it -really- should be under the BSD license. > > Please remember that RMS himself advocates an X-style license instead of > a BSD license, RMS is no doubt somewhat biased when it comes to BSDL. :) But he did make a valid point in the article you reference... > if things can't be under (L)GPL. This is because the BSD > license requires some form of copyright notice be present and displayed > when initializing/using the BSD-covered code. This is very annoying when > there are 20+ copyright lines due to additions made by several authors. > > There was an article on slashdot if I remember correctly. The article was just a pointer to one of RMS' recent pronouncements regarding BSDL, in which he actually made a pretty valid point about it. For those who aren't familiar with it, BSDL consists of 3 things: (1) A copyright notice (2) 4 conditions for modification and redistribution (3) A disclaimer, denying legal liabilty The first two of the four conditions are: if you redistribute the package in source form, you must include the license, and if you redistribute in binary form, you must include the license. Another condition is, the names of the contributors can't be used to endorse derived products without written permission from those contributors. Pretty straight- forward stuff. The remaining condition is the point of contention. It's kind of silly... it states that any advertising that mentions "features or use of this software" must display an acknowledgement to the contributors. RMS' point was that if you have (as an extreme example) an OS containing BSDL code from hundreds of people, a company that takes out a print ad for said OS would have to include hundreds of lines of fine print in their ad, acknowledging each contributor. It's a silly clause, which could be easily removed. Once you eliminate the advertising clause, it's about as simple and unencumbering a license as one could want, short of (perhaps) public domain. I like it quite a bit, myself...minimal and very easy to understand. Mike From ggi-develop-request@eskimo.com Fri Jun 5 21:35:05 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA27370; Fri, 5 Jun 1998 21:35:04 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id VAA28008; Fri, 5 Jun 1998 21:37:55 -0700 Resent-Date: Fri, 5 Jun 1998 21:37:55 -0700 Date: Sat, 6 Jun 1998 00:36:46 +0000 (GMT) From: Michael Funk X-Sender: mwfunk@foo.bar.com Reply-To: mwfunk@uncc.campus.mci.net To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"L4LHl.0.Vr6.YUCUr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2590 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, MenTaLguY wrote: > Explain in more detail, please ... few of us are native BSDers ... if you > look carefully, LGPL2 is what is used in libggi, not GPL2. And LGPL2 isn't > especially restrictive. If LGPL2 hinders _libggi_ on BSD, then I'd say it'd > be BSD's licensing that's overly restrictive. LGPL doesn't hinder libggi on *BSD...most of the BSDers take an attitude towards GPL stuff that many Linuxers take towards proprietary software; it's OK as long as it's not in the kernel, or absolutely essential to the functioning of the OS. It can be tolerated as long as it's something way out there in userland, like a library or an application. They would certainly feel better about it if it were under a less restrictive license (BSDL, XC, or PD, even...), but as long as it's not going in the kernel or their libc or whatever, then LGPL'd code is fine. It's the kernel code where the licensing becomes really significant: KGI and the drivers. I should point out that I don't speak for any of them; I'm just an observer, and someone who's recently become interested in free software licenses and their rationales. It should be stated that any issue the *BSD people would have over the licensing is *not* a BSDL vs. (L)GPL thing; rather, copyleft vs. noncopyleft. They really don't like restrictive and complicated licenses, regardless of how well-intentioned they might be. Also, the GPL carries a lot of ideological baggage that they don't necessarily agree with. I could see how someone might feel that releasing something under the GPL implicitly contributes to the spreading of FSF ideology ("We must destroy the evil software-hoarders", "No one has a right to ownership of source code", etc. etc. etc.). It's pretty extremist stuff, and while the GPL doesn't explicitly state these beliefs (they can be found in the GNU Manifesto and elsewhere), the GPL was very carefully designed to spread RMS' beliefs and further his goals. Once the ideology is taken out of the picture, it makes much less sense (IMHO) to use such a complicated license. > You have actually read and understood the LGPL2, and how it's different > from GPL2 and GPL1, right? GPL1 was heinously restrictive, and I'm afraid a > lot of people haven't bothered to (seriously) look at the newer versions. Indeed, I've only seen one library that was actually written under GPL rather than LGPL. It's my understanding that linking against a straight GPL library makes one's program GPL as well. This is what led to the creation of the LGPL, and is at the root of much of the paranoia and FUD surrounding the GPL's ability to 'taint' software and its viral nature. This issue is similar to the more recent one regarding 'modules' (plugins, drivers, etc.), and whether using a proprietary 'module' for a GPL'd package renders the module GPL'd as well. GPL3 is supposed to contain provisions for this, to prevent such 'tainting', at least according to RMS at Linux Expo this year. > Now, I can certainly see how GPL would be an issue for _KGI_ (as distinct > from libggi) -- KGI actually gets linked with the BSD-licensed kernel. As > far as KGI goes, I think a dual GPL/BSD licensing scheme would be > appropriate to be compatible with BSD kernel licenses. And I think that's > what was decided on ... wasn't it? I kept up with that discussion a while back...that seemed to be the consensus, but it never seemed to get 100% resolved or set in stone. That's why I asked about it; I just wanted to make sure, and hoped that everyone hadn't forgotten about it. I think GGI is the coolest project around, and would love to see it running on FreeBSD someday, hence my concern. :) In any event, yes, I was asking specifically about KGI rather than libggi. Mike From ggi-develop-request@eskimo.com Fri Jun 5 21:58:19 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA27377; Fri, 5 Jun 1998 21:58:16 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA31901; Fri, 5 Jun 1998 22:01:56 -0700 Resent-Date: Fri, 5 Jun 1998 22:01:56 -0700 From: Andrew Apted Message-ID: <19980606132545.15774@ajax.netspace.net.au> Date: Sat, 6 Jun 1998 13:25:45 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi API: switch-away and switch-back Reply-To: ggi-develop@eskimo.com References: <6l8bpr$t44$1@butter.visus.com> <6l9fb9$bb9$1@butter.visus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <6l9fb9$bb9$1@butter.visus.com>; from Jason McMullan on Fri, Jun 05, 1998 at 07:02:01PM +0000 Resent-Message-ID: <"V1YzP.0.Lo7.2rCUr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2591 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jason writes: > Uhh, not quite. Under KGI VT switching is _immediate_: > Here's how it should be done (and is implemented in EvStack > (now to be called GGI Console)) : > > 1) VT switch request make by user > 2) App gets SIGTSTP > 3) All of the App's mmap() regions are now invalid - > if the app want to use "display-memory" as a backbuffer, > fine, otherwise any access to the visual will > result in a SIGBUS > ..... > > ..... > 4) VT is switched make > 5) Mode is restored by KGI/GGI Console > 6) mmap() regions are restored > 7) App gets SIGCONT, SIGWINCH > 8) App restores it's CLUT > 9) App redraws it's display > > Note that (8) and (9) can easily be handled by libGGI. Agreed 100%. > Nope - just redraw. No need to define extra events. Well, one extra event (from libggi -> app) : "Hey, Redraw!". Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 5 21:58:24 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA27382; Fri, 5 Jun 1998 21:58:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA31938; Fri, 5 Jun 1998 22:02:01 -0700 Resent-Date: Fri, 5 Jun 1998 22:02:01 -0700 From: Andrew Apted Message-ID: <19980606131808.64998@ajax.netspace.net.au> Date: Sat, 6 Jun 1998 13:18:08 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi: graphtypes Reply-To: ggi-develop@eskimo.com References: <19980606002937.29151@ajax.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Brian Julin on Fri, Jun 05, 1998 at 03:59:48PM -0400 Resent-Message-ID: <"rmrAZ1.0.ro7.7rCUr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2592 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Brian writes: > > Others have suggested much more complicated versions which specify > > things like Z buffer info, Alpha channels, planar modes, the exact > > number of bits for red, green and blue, etc.... I think all this either > > (a) doesn't belong in LibGGI, or (b) belongs as separate functionality > > from the ggiSetGraphMode() call. > > OK, to clarify on things since I was one of those people, I only > wanted the field to be big enough so the calls from the stuff that > "doesn't belong in libGGI" would fit without any footwork when > libGGI2D and libGGI3D and other helper libs are written. So my > system was meant to be spread over many libraries, with the > #defines for the field values spread over their header files. I'm not sure that stuffing all these things into one big "graphtype" value is the right way to go. Seems we could easily run out of space, even in a ggi_u64. IMHO there should be a structure with various fields containing all the gory details -- maybe this structure belongs in the DirectBuffer headers ? Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 5 23:31:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA27431; Fri, 5 Jun 1998 23:31:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA12671; Fri, 5 Jun 1998 23:35:11 -0700 Resent-Date: Fri, 5 Jun 1998 23:35:11 -0700 From: Andrew Apted Message-ID: <19980606163345.52507@ajax.netspace.net.au> Date: Sat, 6 Jun 1998 16:33:45 +1000 To: ggi-develop@eskimo.com Subject: Re: KGI license? Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from becka@rz.uni-duesseldorf.de on Fri, Jun 05, 1998 at 07:16:28PM +0200 Resent-Message-ID: <"IaXeX3.0.t53.UCEUr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2593 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andy writes: > O.K. - Can we all agree on the following : > > 1. All parts of GGI, that are to be patched into, linked to, or somehow > otherwise incorporated into another piece of software should use the > licensing policy of the appropriate piece of software, or a compatible > one which is likely to be accepted by the authors of the modified > software. > > This means GPL for Linux kernel patches, new files and such, > BSD for BSD-patches etc., evteually commercial licenses on SUNOS patches > or something like this. > > 2. All parts, for which there seems no technical reason for not doing so, > we should use BSD licensing in the version that says "give credits in the > program _or_ accompanying documentation", to avoid that "having to flush > messages over the screen" problem. I have no problems with the kernel stuff: KGI, EvStack, and the drivers being under a BSD-style license, but I __REALLY__ want LibGGI to stay LGPL. I see absolutely *no* reason why we should change the license to something other than the LGPL. In my opinion, the LGPL is good enough, and I am strongly opposed to the idea of dropping it. > 3. I'd like some parts, especially "stub" drivers and example code to be > really "freeware". I.e. "do with that as you wish". Just make them "Public Domain". Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 5 23:32:25 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA27436; Fri, 5 Jun 1998 23:32:23 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA12932; Fri, 5 Jun 1998 23:37:45 -0700 Resent-Date: Fri, 5 Jun 1998 23:37:45 -0700 Message-ID: <19980606013506.14815@fries.net> Date: Sat, 6 Jun 1998 01:35:06 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: KGI license? References: <199806051512.LAA05292@mentalnet.dyn.ml.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from MenTaLguY on Fri, Jun 05, 1998 at 11:47:01AM -0400 Resent-Message-ID: <"MWw341.0.t93.uEEUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2594 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, Jun 05, 1998 at 11:47:01AM -0400, MenTaLguY wrote: > On Thu, 4 Jun 1998, Todd T. Fries wrote: > > It is quite an interesting statement. I made many contributions to > > libggi, infact, the makefile system currently in place! And nowhere did > > I ever put the GPL license. Somehow, though, in Makefiles all over sprung > > up a GPL license. > > That's bad. If you had the copyright to the code, you should have been > asked. Of course, it's also your responsibility to put appropriate copyright > notices in the code you write. *sigh*. I must always learn the hard way. I am now very interested in getting access to the old cvs repository to see exactly what it was that I did commit originally. Not that I'm going to make any issue out of it but just for idle curiousity. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Fri Jun 5 23:36:22 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA27441; Fri, 5 Jun 1998 23:36:20 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id XAA10261; Fri, 5 Jun 1998 23:42:25 -0700 (PDT) Resent-Date: Fri, 5 Jun 1998 23:42:25 -0700 (PDT) Message-ID: <19980606013727.20037@fries.net> Date: Sat, 6 Jun 1998 01:37:27 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: KGI license? References: <19980606163345.52507@ajax.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19980606163345.52507@ajax.netspace.net.au>; from Andrew Apted on Sat, Jun 06, 1998 at 04:33:45PM +1000 Resent-Message-ID: <"mZjJi1.0.CW2.EJEUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2595 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, Jun 06, 1998 at 04:33:45PM +1000, Andrew Apted wrote: > Andy writes: > > > O.K. - Can we all agree on the following : > > > > 1. All parts of GGI, that are to be patched into, linked to, or somehow > > otherwise incorporated into another piece of software should use the > > licensing policy of the appropriate piece of software, or a compatible > > one which is likely to be accepted by the authors of the modified > > software. > > > > This means GPL for Linux kernel patches, new files and such, > > BSD for BSD-patches etc., evteually commercial licenses on SUNOS patches > > or something like this. > > > > 2. All parts, for which there seems no technical reason for not doing so, > > we should use BSD licensing in the version that says "give credits in the > > program _or_ accompanying documentation", to avoid that "having to flush > > messages over the screen" problem. > > I have no problems with the kernel stuff: KGI, EvStack, and the drivers > being under a BSD-style license, but I __REALLY__ want LibGGI to stay > LGPL. I see absolutely *no* reason why we should change the license to > something other than the LGPL. In my opinion, the LGPL is good enough, > and I am strongly opposed to the idea of dropping it. Please back your opinion with reasons. You simply site your lack of desire to change as a reason. Not a good reason, IMHO. LGPL forces the sources to remain available and nobody can modify the lib without releasing their modifications. This prohibits vendors from incorporating libggi in their software trees if they think it is a good thing. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Fri Jun 5 23:42:28 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA27446; Fri, 5 Jun 1998 23:42:27 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA13871; Fri, 5 Jun 1998 23:47:51 -0700 Resent-Date: Fri, 5 Jun 1998 23:47:51 -0700 Date: Sat, 6 Jun 1998 02:48:56 +0000 (GMT) From: Michael Funk X-Sender: mwfunk@foo.bar.com Reply-To: mwfunk@uncc.campus.mci.net To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <19980606011126.62533@fries.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"oErDY3.0.dO3.MOEUr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2596 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Todd T. Fries wrote: > Perhaps you don't even want to have some of that stuff in there. Like > for instance, I seriously doubt there is any connection with UCB > in the ggi project specifically... Yes. I've seen many people use BSDL verbatim, with the UCB references (copyright and advertising clause) changed to whomever wrote the code; AFAIK this is still considered BSDL. > The suggestion is to use a BSD style license. That doesn't mean quote it > verbatum but have a similar 'non-limiting' effect. Yep, this is what I meant to say...BSDL-style, not necessarily pure BSDL. > So (according to what you suggested) we could have something like: Beautiful! Copyright, legal disclaimer, and conditions: must distribute the license with the source and/or bins, and no one can use the authors' names' to promote the software without their consent. Heck, I wonder if that one is even necessary. I have a feeling it was just in there to prevent anyone from using UCB's name to sell stuff. And no silly advertising clause. Excellent license: simple, easily understood, with an absolute minimum of content and restrictions. Statement of copyright, "you can't sue us", and you have to include the license when redistri- buting. It doesn't get much more straightforward than that. Mike From ggi-develop-request@eskimo.com Sat Jun 6 01:18:25 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA27559; Sat, 6 Jun 1998 01:18:23 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA26767; Sat, 6 Jun 1998 01:23:31 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 01:23:31 -0700 (PDT) Date: Sat, 6 Jun 1998 04:20:31 +0000 (GMT) From: Michael Funk X-Sender: mwfunk@foo.bar.com Reply-To: mwfunk@uncc.campus.mci.net To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <19980606013225.59764@fries.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"2EIfE3.0.7Y6.0oFUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2597 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Todd T. Fries wrote: > The problem with GPL and even LGPL in the GGI Project is that you are limiting > the audience that will be able to use the library and the code. If you ever > want libggi to be on Solaris, for example, you had better not even think once > about LGPL. BSD style, on the other hand, allows 'here, if you want to use > what we have done, have at, you can make it work w/out having to re-invent > the wheel'. The FSF response to this would be (I'm honestly not trying to set up a strawman here), Sun is a 'software-hoarder', and as such is The Enemy. If they want to "share the software" and benefit from a GPL'd KGI, they've got to GPL their kernel. To some degree this illustrates what I said earlier about the GPL being designed to further a particular agenda and belief system, despite the license itself being devoid of propaganda and manifestos and such. I agree with you 100%, it just gets in the way, and causes headaches and much confusion, at least if you don't believe the ideology. I guess to someone who does buy into it, it's the greatest thing since sliced bread, but I can't believe that all of the tens (or hundreds) of thousands of people who've written GPL'd software really share RMS' views on intellectual property, which are pretty way the heck out there, IMHO. A lot of people just go with the flow. > But why does one have to use GPL/LGPL specifically? I believe that the members > of the GGI Project have simply placed GPL licenses on the code/Makefiles/etc > because that is what they are accustomed to, it is free software as they are > used to it, etc. In my experience most people aren't all that interested in legal niceties and tend to go with whatever licensing is predominant on the platform they're developing for. This is a very broad (and probably slightly exaggerated) statement, but I've frequently been suprised at how few people who participate in licensing flamewars have actually read (and understand) the licenses in question. I'm guilty of this myself... I used free software for years before I ever even bothered to read any of the licenses, or think about what they really meant, or who wrote them and why. > Dual license? How can you allow the same code to have 2 licenses? You > either require it to always releaseed in source form or you allow a vendor > to borrow to get their os supported if they can't/don't want to release > their modifications. You can't have both. This was also brought up in the discussion with RMS, who explained it thusly: GPL applies to a particular release of a particular chunk of code. It is apparently more closely associated with a release of a package than it is the individual lines of code. For example, say I have the source code to a program I've written sitting on my hard drive. I throw it together into a tarball, foo-gnu-1.0.tar.gz, along with a copy of the GPL, and stick it on my home page. I have just made a GPL'd release of my program. Now, say I take the exact same source code, PD it, throw it all together into pdfoo-1.0.tar.gz, and put *that* up on my home page as well. They're two different releases of the same software package, under two different licenses. Despite the fact that it's the exact same code, the fact that the sources in foo-gnu are GPL'd does not mean that the stuff in pdfoo becomes GPL'd as well, and neither do the original sources, which are still sitting on my hard drive. Eric Raymond characterized this as, the GPL applies to an instantiation (a particular release) of a given software package. What's the licensing on the (unlicensed) sources on my hard drive? Who knows...IANAL (I Am Not A Lawyer). If someone downloads the GPL'd release of my program, and makes modifications and wants to redistribute them, she is bound by the terms of the GPL, as it is a derived work of a GPL'd package. On the other hand, if she downloads the PD version of the same package, no such restrictions apply, despite the fact that the files contained within the tarball (except for the licenses) are identical. As far as the licenses are concerned, the two packages are completely different things. It's all pretty vague and fuzzy and open to much interpretation. This is why I like non-copyleft licenses: if you have to call out the lawyers anytime someone is thinking about doing something with a piece of free software, then the goal of sharing and openess has been hindered. :( The only reason I don't advocate straight PD is, it seems like a good idea to include the legal disclaimers (and a copyright, I suppose), just to be on the safe side. I don't know enough about PD to really comment on it. Mike From ggi-develop-request@eskimo.com Sat Jun 6 03:15:33 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA27683; Sat, 6 Jun 1998 03:15:30 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id DAA04513; Sat, 6 Jun 1998 03:14:31 -0700 Resent-Date: Sat, 6 Jun 1998 03:14:31 -0700 Message-Id: <199806061006.MAA10807@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 06 Jun 1998 12:01:32 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: CVS passwords Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"pUkRU.0.K61.6QHUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2598 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello, Could the persons listed below, send me by _private_ email, a crypted-passwd for "development branch" CVS access ? Thanks :) Andrew Apted Jonas Borgstrom Massimiliano Ghilardi Willie Daniel Martin Eli Erhardsen David Fries Todd T. Fries Brian S. Julin Jan Kneschke Stefan Mars Stephan Meyer Rodolphe Ortalo Teunis Peters Marcus Sundberg Thomas Tanner Jon M. Taylor James F. Ursetto Andreas Vogler Gernot Ziegler And of course anyone I forgot.. -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 6 04:19:48 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA27735; Sat, 6 Jun 1998 04:19:45 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA14476; Sat, 6 Jun 1998 04:23:25 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 04:23:25 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Rendition Drivers (fwd) To: ggi-develop@eskimo.com (mailing list GGI) Date: Sat, 6 Jun 1998 13:13:28 +0200 (MET DST) Cc: anarchy@bright.net Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"WLPcG1.0.4Y3.hQIUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2599 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com O.K. - I'll forward to the list, to see if someone is working on it ... Forwarded message: > From anarchy@bright.net Fri Jun 5 20:34:03 1998 > Delivery-Date: Fri, 5 Jun 1998 20:34:03 +0200 > From: anarchy@bright.net > Date: Fri, 5 Jun 1998 14:30:17 -0400 > Message-Id: <199806051830.OAA00167@anarchy.thehideout.org> > Subject: Rendition Drivers > > The specs for the rendition chips have been released. They have been out for a few months now. www.rendition.com XFree has started working on support for it and I would really love to see support from ggi soon so I can run svgalib proggrams with my rendition based card. > > Thanks, > Aaron Ray > P.S. Reply's are greatly appreciated CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 6 04:37:40 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA27749; Sat, 6 Jun 1998 04:37:39 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA07096; Sat, 6 Jun 1998 04:31:44 -0700 Resent-Date: Sat, 6 Jun 1998 04:31:44 -0700 X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Sat, 6 Jun 1998 13:30:40 +0200 (MET DST) From: Stefan Mars To: Emmanuel Marty cc: ggi-develop@eskimo.com Subject: Re: CVS passwords In-Reply-To: <199806061006.MAA10807@orb.suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"wUEiA2.0.mk1.WYIUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2600 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Emmanuel Marty wrote: > Hello, > > Could the persons listed below, send me by _private_ email, > a crypted-passwd for "development branch" CVS access ? Thanks :) Are the login-names the same, or are you changing them to match the ggi-project.org email addresses? -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Sat Jun 6 05:50:20 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA27793; Sat, 6 Jun 1998 05:50:17 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA27015; Sat, 6 Jun 1998 05:50:29 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 05:50:29 -0700 (PDT) From: Andrew Apted Message-ID: <19980606220207.36839@ajax.netspace.net.au> Date: Sat, 6 Jun 1998 22:02:07 +1000 To: ggi-develop@eskimo.com Subject: Re: KGI license? Reply-To: ggi-develop@eskimo.com References: <19980606163345.52507@ajax.netspace.net.au> <19980606013727.20037@fries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <19980606013727.20037@fries.net>; from Todd T. Fries on Sat, Jun 06, 1998 at 01:37:27AM -0500 Resent-Message-ID: <"0xIkc3.0.zb6.JiJUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2601 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Todd T. Fries writes: > > I have no problems with the kernel stuff: KGI, EvStack, and the drivers > > being under a BSD-style license, but I __REALLY__ want LibGGI to stay > > LGPL. I see absolutely *no* reason why we should change the license to > > something other than the LGPL. In my opinion, the LGPL is good enough, > > and I am strongly opposed to the idea of dropping it. > > Please back your opinion with reasons. You simply site your lack of desire > to change as a reason. Not a good reason, IMHO. It is not the change per se, but the change to a non-copyleft license that I am against. It makes LibGGI "less free" than it was before. > LGPL forces the sources to remain available and nobody can modify the > lib without releasing their modifications. This prohibits vendors > from incorporating libggi in their software trees if they think it is > a good thing. In other words, it prohibits vendors from taking my code, making a few modifications, and then selling it. Great, with a non-copyleft license a company can just take the work *I* do and make a nice profit from it. The company gets the money, and the free software community (and me) gets back nothing. Wow, what a win. This is looking like a religious issue, copyleft vs non-copyleft, and thus prone to a big useless debate/flamewar which gets us nowhere. I'll just say this: I am a fan of copyleft (GPL and LGPL), and of the philosophy behind it, and if LibGGI changes to a non-copyleft license then my desire to work on it will be greatly diminished. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Sat Jun 6 06:50:16 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA27832; Sat, 6 Jun 1998 06:50:14 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA12436; Sat, 6 Jun 1998 06:47:58 -0700 Resent-Date: Sat, 6 Jun 1998 06:47:58 -0700 Sender: wouter@cistron.nl Message-ID: <35794830.5FE80123@cistron.nl> Date: Sat, 06 Jun 1998 15:46:24 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: KGI license? References: <19980606163345.52507@ajax.netspace.net.au> <19980606013727.20037@fries.net> <19980606220207.36839@ajax.netspace.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FY2Pc3.0.723.EYKUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2602 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andrew Apted wrote: > > Todd T. Fries writes: > > > > I have no problems with the kernel stuff: KGI, EvStack, and the drivers > > > being under a BSD-style license, but I __REALLY__ want LibGGI to stay > > > LGPL. I see absolutely *no* reason why we should change the license to > > > something other than the LGPL. In my opinion, the LGPL is good enough, > > > and I am strongly opposed to the idea of dropping it. > > > > Please back your opinion with reasons. You simply site your lack of desire > > to change as a reason. Not a good reason, IMHO. > > It is not the change per se, but the change to a non-copyleft license > that I am against. It makes LibGGI "less free" than it was before. More free. Free=freedom. PD is the most free license, BSD a bit less, GPL still less. > > LGPL forces the sources to remain available and nobody can modify the > > lib without releasing their modifications. This prohibits vendors > > from incorporating libggi in their software trees if they think it is > > a good thing. > > In other words, it prohibits vendors from taking my code, making a few > modifications, and then selling it. Great, with a non-copyleft license > a company can just take the work *I* do and make a nice profit from it. > The company gets the money, and the free software community (and me) > gets back nothing. Wow, what a win. No. That's not the point at all. For applications like a word processor I would agree. For low level stuff (drivers and libraries) this is irrelevant. Also, you may want to ask RedHat for some money which they are making off of you, selling GPL'ed software. Btw, you perpetuate the myth that companies using BSD style licensed software give nothing back. Think again. FreeBSD gets a lot of input (bug fixes and improvements) from companies which use that software in a variety of ways. The same applies for libraries like libjpeg which has gotten improvements from companies which under LGPL would not have happened. A problem with the LGPL in some cases is also the need to supply source upon request (i.e. this makes it not worth the bother to supply single floppy network server systems, which you can do nicely with *BSD. After all, the source is availabel on the net) Another example: BSD would allow you to compile statically linked apps (posssibly containing only the needed code) which is not possible with LGPL. This may be a plus to make programs less dependant on library variations, or inline their (i.e. whoever wants to do this) own code with the library instead of make lib calls inside their code (for speed). Wouter From ggi-develop-request@eskimo.com Sat Jun 6 06:57:07 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA27837; Sat, 6 Jun 1998 06:57:05 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA03223; Sat, 6 Jun 1998 06:56:14 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 06:56:14 -0700 (PDT) X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Sat, 6 Jun 1998 15:48:31 +0200 (MET DST) From: Stefan Mars To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <19980606220207.36839@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"h0Xxf1.0.Do.yfKUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2603 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Andrew Apted wrote: > In other words, it prohibits vendors from taking my code, making a few > modifications, and then selling it. Great, with a non-copyleft license > a company can just take the work *I* do and make a nice profit from it. > The company gets the money, and the free software community (and me) > gets back nothing. Wow, what a win. > > This is looking like a religious issue, copyleft vs non-copyleft, and > thus prone to a big useless debate/flamewar which gets us nowhere. > I'll just say this: I am a fan of copyleft (GPL and LGPL), and of the > philosophy behind it, and if LibGGI changes to a non-copyleft license > then my desire to work on it will be greatly diminished. I have to side with Andrew here, and for the same reasons. It might be that parts of GGI must be licensed under non-GPL, but in my mind as much as possible should stay (L)GPL. Why? Because it protects us, the developers, from having our work "stolen", and it protects the free software community since they will always have access to the sources. I code for fun, because I like it, and because hopefully others can make it use of what I do. That doesn't mean that I would like someone else to make a profit from my code. -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Sat Jun 6 06:58:14 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA27842; Sat, 6 Jun 1998 06:58:12 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA04349; Sat, 6 Jun 1998 07:05:25 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 07:05:25 -0700 (PDT) Message-Id: <199806061400.QAA11168@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 06 Jun 1998 15:55:09 +0200 To: Stefan Mars From: Emmanuel Marty Subject: Re: CVS passwords Cc: ggi-develop@eskimo.com In-Reply-To: References: <199806061006.MAA10807@orb.suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"VoMrj.0.p31.YoKUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2604 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Stefan Mars wrote: >Are the login-names the same, or are you changing them to match the >ggi-project.org email addresses? I am rearranging them a little so that they match email and we immediately know who it is yes ("ezrec" didn't say much to me :) .. I'll post the logins list tonight when the CVS reopens for everyone. You didn't send me your password btw :) -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 6 08:55:58 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA27917; Sat, 6 Jun 1998 08:55:51 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA24524; Sat, 6 Jun 1998 09:02:24 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 09:02:24 -0700 (PDT) Date: Sat, 6 Jun 1998 11:55:09 -0400 (EDT) From: Steve Cheng Sender: steve@maxt3m46.ipoline.com To: Michael Funk cc: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"YBMFr.0.0_5.BWMUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2605 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Michael Funk wrote: > package than it is the individual lines of code. For example, say I > have the source code to a program I've written sitting on my hard > drive. I throw it together into a tarball, foo-gnu-1.0.tar.gz, along > with a copy of the GPL, and stick it on my home page. I have just > made a GPL'd release of my program. Now, say I take the exact same > source code, PD it, throw it all together into pdfoo-1.0.tar.gz, and put > *that* up on my home page as well. They're two different releases of the > same software package, under two different licenses. Despite the fact Just a word of warning: Public Domain is not a license. If you put something into public domain, then you disown ALL copyrights on the code. Consequently, you cannot apply any other licenses on your code since it is not copyrighted by you any more. > What's the licensing on the (unlicensed) sources on my hard drive? Who > knows...IANAL (I Am Not A Lawyer). Yes, it's unlicensed, but if you are the sole copyright holder, you can use the code for whatever purpose you want. You do not have to license your work back to yourself. Ditto IANAL. Personally, I think offering multiple licensing is the way to go. E.g. leave main libggi as LGPL'd, but we could leave open an option for a vendor who wants to bundle the binaries only with their system. On the other hand, I don't think the GGI Project is in the position to advocate "we must use only free software" (think 'commercial' games), so the whole thing should be on X-style license (yes, none of that obnoxious advertising stuff). If I am wrong above, please correct me, but please don't start a flamewar on copyleft vs. non-copyleft... // Steve e-mail: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Sat Jun 6 09:06:54 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA27933; Sat, 6 Jun 1998 09:06:52 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA20074; Sat, 6 Jun 1998 09:04:52 -0700 Resent-Date: Sat, 6 Jun 1998 09:04:52 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: New Extension scheme To: ggi-develop@eskimo.com (mailing list GGI) Date: Sat, 6 Jun 1998 18:03:16 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"mSjtq.0.Xv4.ZYMUr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2606 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi folks ! In order to allow for more complicated extensions and thus better extensibility for LibGGI in the future, I have changed the extension scheme a bit. The new API looks like that : ggi_extid ggiExtensionRegister(char *name, int size, int (*paramchange)(ggi_visual_t,int whatchanged)); int ggiExtensionUnregister(ggi_extid id); int ggiExtensionAttach(ggi_visual_t vis,ggi_extid id); int ggiExtensionDetach(ggi_visual_t vis,ggi_extid id); These should normally be wrapped by the extension library to library native calls. The main differences between the old and the new scheme are: 1. Extensions are attached to individual visuals, thus conserving memory when you are using multiple visuals with different extensions. 2. Initialization and attachment work in the same fashion as ggiInit/Exit, thus allowing nested invocation to make "plugin-modules" for programs easier to do. 3. The libraries are now loaded in "blocks". I.e. first _all_ LibGGI native libs, then all 2D libs, then all 3D libs. This results in better fallback behaviour. 4. There are no longer a load and a release call, but a single "change" callback, that will get notified, if things change that should be noticed by the extensions. For now I only have GGI_CHG_APILIST, the next candidate is probably GGI_CHG_GEOMETRY. 5. Extensions (as well as normal apps) can now query the List of APIs. for this, there is a new call int ggiGetAPI(ggi_visual_t vis, int num, char *apiname, char *arguments); It will (at num=0) also return the "display-*" it is running on. This will allow extension libs to take advantage of the particular backend they are running on. The LibGGI3D could e.g. make use of GLX or PEX, when it detects "display-Xlib" being used. Implementation is in the new repository. I'll have to update all display-* directories, but that should be done by tomorrow. Any obvious shortcomings in that scheme ? CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 6 10:32:22 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA27962; Sat, 6 Jun 1998 10:32:19 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA25434; Sat, 6 Jun 1998 10:30:49 -0700 Resent-Date: Sat, 6 Jun 1998 10:30:49 -0700 Date: Sat, 6 Jun 1998 13:27:07 +0000 (GMT) From: Michael Funk X-Sender: mwfunk@foo.bar.com Reply-To: mwfunk@uncc.campus.mci.net To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"K9Uc12.0.ID6.8pNUr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2607 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Steve Cheng wrote: > On the other hand, I don't think the GGI Project is in the position to > advocate "we must use only free software" (think 'commercial' games), so the > whole thing should be on X-style license (yes, none of that obnoxious > advertising stuff). I tend to like non-copyleft because it just makes things simpler...it seems like on GPL'd projects, there's inevitably much confusion and debate over the intricacies of the licensing, and time spent hypothesizing about whether or not this or that feature of the GPL might prevent certain forms of commercial support (like drivers, in this case), or to what degree the code could be used in free software projects under other licenses. It's just a big and complicated license is all, and IMO doesn't buy anyone much for all the complication (freedom from commercial/proprietary exploitation?...is this really a big concern?). > If I am wrong above, please correct me, but please don't start a flamewar on > copyleft vs. non-copyleft... Yes, sorry, I didn't mean to put anything in inflammatory terms... I'm not even a GGI developer, and don't really have a right to tell you guys what you should do with your own work. My big interest in all of this is someday perhaps seeing KGI working under FreeBSD, and if the KGI code was copylefted this would never happen. Copyleft pretty much restricts KGI to Linux and the Hurd, whereas noncopyleft means everyone gets it (including, potentially, commercial OS's). Again, I'm really specifically talking about KGI, and am not so concerned about the userland libs (LGPL libs aren't going to scare anyone off, as they're pretty much self-contained). KGI is important because it has to coexist with a bunch of other code in the same 'package' (a kernel), and is not a self-contained work. I just wanted to make sure that the people who were responsible for KGI were aware of the issues involved, and how it might make a big difference further down the road, even if it doesn't seem like such a big deal now. Mike From ggi-develop-request@eskimo.com Sat Jun 6 11:04:11 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA27975; Sat, 6 Jun 1998 11:04:09 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA28491; Sat, 6 Jun 1998 11:01:09 -0700 Resent-Date: Sat, 6 Jun 1998 11:01:09 -0700 Message-Id: <199806061800.LAA17775@nova.botz.org> X-Mailer: exmh version 2.0.2 To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Your message of "Fri, 05 Jun 1998 19:52:49 -0000." Date: Sat, 06 Jun 1998 11:00:52 -0700 From: Jurgen Botz Resent-Message-ID: <"YXMH21.0.-y6.aFOUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2608 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Somebody wrote: > > Please remember that RMS himself advocates an X-style license instead of > > a BSD license, Yes. And the recent debacle with the Open Group's taking X out of the open software arena and releasing bugfixes for critical security bugs only to paying members shows just why the GPL is such a good idea. Take the following scenario: o We use X-style license for GGI/KGI o A company "DisplayWorks"* contributes some really cool code that makes KGI work better o GGI/KGI is wildly successful, gets ported to many workstation platforms o Lots of Graphics board makers start writing KGI drivers o Suddenly DisplayWorks takes their code private again and releases critical bugfixes only to Graphics board vendors who pay them a license fee (* fictional name for example; no resemblance to any real company intended.) Ok, we can still fix bugs ourselves too, but to a large extend DisplayWorks has taken control of GGI/KGI now. The Graphics board vendors may chose to deal with them rather than us, simply because they are used to making deals with software companies. At best we now have two forks of the work, at worst DisplayWorks may start to make incompatible changes, locking the rest of us out. The GPL does have an ideology attached to it, but I don't think that it's "destroy the evil software hoarders". The ideology is: We want to have the choice to use /only/ free/open source software. For this to work we need lots of it, and we need Free/Open Source software to keep growing to keep up with the technology. To accomplish this we need to make sure that free software /stays/ free and that people who want to benefit from it have to contribute to it. The viral properties of the GPL assure that. Without the GPL we have a very lose community of people sometimes writing free software, resulting in a lot of good but isolated and disconnected free/open source software projects. Some of the best of this software has an initial free version which later goes commercial and only the commercial version improves significantly. With the GPL we have an ever growing, mountain of interconnected free/open source software that results in ever more code re-use and steadily improving quality overall. The mountain can only grow; it can't get smaller. The result is that many of us now can chose to run only open source applications on an open source OS without ever having to submit to the frustrations of paying money for restrictive licenses to closed software that we're not allowed to modify or fix when it doesn't do exactly what we want (which it never does.) That's my take on it, and that's why I prefer the GPL to other open source licenses. -- ~~/ /~) /.. /-< \_/ u r g e n /_ _) o t z From ggi-develop-request@eskimo.com Sat Jun 6 11:27:47 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA28004; Sat, 6 Jun 1998 11:27:45 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA30678; Sat, 6 Jun 1998 11:25:18 -0700 Resent-Date: Sat, 6 Jun 1998 11:25:18 -0700 Message-Id: From: andy@shu-wood.demon.co.uk (Andrew Shuttlewood) Subject: Re: KGI license? In-Reply-To: <199806061800.LAA17775@nova.botz.org> from Jurgen Botz at "Jun 6, 98 11:00:52 am" To: ggi-develop@eskimo.com Date: Sat, 6 Jun 1998 19:32:12 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"z9-Hc1.0.DV7.DcOUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2609 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I don't work on GGI, I've just read a lot of these licensing debates > Ok, we can still fix bugs ourselves too, but to a large extend > DisplayWorks has taken control of GGI/KGI now. The Graphics board > vendors may chose to deal with them rather than us, simply because > they are used to making deals with software companies. At best > we now have two forks of the work, at worst DisplayWorks may start > to make incompatible changes, locking the rest of us out. Is it impossible to make a license which prohibits people from making API changes without consent from the internet community, but allowing them to alter the code as they see fit? Then any company could use the KGI/GGI code as they saw fit, not necessarily needing to release the changes necessary to work with their "proprietary" hardware, but they would be prevented from changing the core API and thus forking development and leaving free software high and dry Is this totally unrealistic? Or is possible to some degree? It seems to be the best workaround to the problem in the long run... -- Andrew Shuttlewood From ggi-develop-request@eskimo.com Sat Jun 6 12:31:29 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA28049; Sat, 6 Jun 1998 12:31:27 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA03173; Sat, 6 Jun 1998 12:30:01 -0700 Resent-Date: Sat, 6 Jun 1998 12:30:01 -0700 Date: Sat, 6 Jun 1998 15:34:21 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <199806061821.OAA09936@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"_OtHV2.0.Tn.vYPUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2610 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Jurgen Botz wrote: > Somebody wrote: > > > Please remember that RMS himself advocates an X-style license instead of > > > a BSD license, > > Yes. And the recent debacle with the Open Group's taking X out of > the open software arena and releasing bugfixes for critical security > bugs only to paying members shows just why the GPL is such a good > idea. > > Take the following scenario: > > - very appropriate example scenario omitted - > > The GPL does have an ideology attached to it, but I don't think > that it's "destroy the evil software hoarders". The ideology is: > > We want to have the choice to use /only/ free/open source software. > For this to work we need lots of it, and we need Free/Open Source > software to keep growing to keep up with the technology. To > accomplish this we need to make sure that free software /stays/ > free and that people who want to benefit from it have to contribute > to it. Exactly. We have no other way to ensure that our work will _not_ get folded into a proprietary product and resold, potentially in competition with us. GPL will not prevent us from cooperating from companies like Sun, say, if they want KGI, since we, the copyright holders, will still be free to make an exception and give them code under a license compatible with linking into their kernel. > The viral properties of the GPL assure that. Without the GPL we > have a very lose community of people sometimes writing free software, > resulting in a lot of good but isolated and disconnected free/open > source software projects. Some of the best of this software has > an initial free version which later goes commercial and only the > commercial version improves significantly. Precisely. GPL can serve to keep GGI from being co-opted either deliberately or inadvertantly to become tied to proprietary software in some fashion. BSD or X-style licenses can't do that. Both of the latter two have been abused at one time or another, and the only thing that has protected BSD licensed code as much as it has been is an incredible amount of goodwill towards BSD -- not something that we can expect from a company trying to produce a commercial alternative to GGI that they want to profit directly from. I can't and won't insist that it will happen, but there's a very real possibility that it _could_ happen. Granted, for some parts of GGI, GPL is most certainly not appropriate. Any part that would get linked to the BSD kernel would have to be either pure BSD or dual GPL/BSD (probably the latter for code used by both the Linux and BSD patches). LibGGI and related libraries ought to be LGPL (of course), and the example code and possibly the generic stubs should probably be PD, or maybe just freeware. The main thing is, the GPL is a "freer" license not because it allows people to use the code in more ways, it is "freer" because it better protects _our_ freedom as users and programmers to preserve _our_ ability to use and benefit from _our_ code. When I say "us", I don't just mean the developers on this list, nor all the people who have contributed code to GGI so far, but in a very real sense all the people who are using and will ever use our code in any sense, be it Joe GGI Hacker, or some kid playing Quake VI with his friends on a multiheaded Linux 2.4.12 gaming station. At the same time, the developers and contributers still have ownership of the code they have written. GPL allows anyone to benefit from the code -- except in cases where it would be at the expense of everyone else. That's something X-style and BSD licenses don't accomplish. -=MenTaLguY=- From ggi-develop-request@eskimo.com Sat Jun 6 14:47:13 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA28125; Sat, 6 Jun 1998 14:47:11 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA21448; Sat, 6 Jun 1998 14:47:02 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 14:47:02 -0700 (PDT) Date: Sat, 6 Jun 1998 17:44:46 -0400 (EDT) From: Steve Cheng Sender: steve@elmert Reply-To: Steve Cheng To: GGI Mailing List Subject: Duplicate mails? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"dvj9D2.0._E5.KZRUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2611 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Problem with mailing list? Or may be I'm the only one? I sometimes get duplicate messages (no particular person) on the list. // Steve e-mail: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Sat Jun 6 16:13:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA28160; Sat, 6 Jun 1998 16:13:40 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA04885; Sat, 6 Jun 1998 16:14:08 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 16:14:08 -0700 (PDT) Message-Id: <199806062309.BAA14189@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 07 Jun 1998 01:04:09 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: ANNOUNCE: CVS is open ! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"d9DMi1.0.AC1.zqSUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2612 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello all, Here we go, the CVS repository is open. You will find Andy's new libggi scheme already in there, but not yet the new KGI as we are waiting for Steffen to return from holidays. Soon, everything will come into place. The developer repository is available at the following CVSROOT: :pserver:mylogin@cvs.ggi-project.org:/projects/ggi/cvsdevel Developer: login: Andrew J. Apted ajapted Andreas Beck becka Jonas Borgstrom jonas Steve Cheng steve Willie Daniel willie Stefan Mars mars Emmanuel Marty emarty Jason McMullan jmcc Hartmut Niemann hniemann Marcus Sundberg marcus Thomas Tanner tanner Andreas Vogler asvogler Guest read-only access is available for both repositories: stable :pserver:guest@cvs.ggi-project.org:/projects/ggi/cvs devel :pserver:guest@cvs.ggi-project.org:/projects/ggi/cvsdevel For both the password is "guest". As I write this, both repositories are identical. All developers will from now on work on the 'devel' one.. On a regular basis, completed work will make it into the stable one. An anonymous read-only repository in the USA will be setup by Todd T. Fries very soon - we are working on it as I write this, but didn't want to delay this post. He will post the details when it's up. BACK AT LAST! -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 6 16:17:28 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA28165; Sat, 6 Jun 1998 16:17:26 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA06593; Sat, 6 Jun 1998 16:24:24 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 16:24:24 -0700 (PDT) Message-Id: <199806062319.BAA14210@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 07 Jun 1998 01:14:18 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: REMINDER: irc session Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"5tPGe3.0.cc1.X-SUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2613 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello again, This is just to remind you that we are all attending an IRC session tomorrow (sunday, maybe it's already "today" for you :), at 3 PM GMT - see the IRC information on the website for time translation. Server is still irc.ggi-project.org, ports 6660-6679, and discussion will take place in channel #ggi. Note that there is another session planned next week, same day, same time, same place, but that the Berlin team has been invited, so be there too! :) We'll discuss issues common to both teams, and there are many. See you tomorrow then! -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 6 16:27:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA28170; Sat, 6 Jun 1998 16:27:09 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA08633; Sat, 6 Jun 1998 16:34:19 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 16:34:19 -0700 (PDT) Message-Id: <199806062329.BAA14226@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 07 Jun 1998 01:24:29 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: Re: ANNOUNCE: CVS is open ! In-Reply-To: <199806062309.BAA14189@orb.suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"bF2D91.0.j62.v7TUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2614 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >Guest read-only access is available for both repositories: > >stable :pserver:guest@cvs.ggi-project.org:/projects/ggi/cvs >devel :pserver:guest@cvs.ggi-project.org:/projects/ggi/cvsdevel > >For both the password is "guest". Maybe I should mention that you have to "checkout degas" *duck* -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 6 18:17:12 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA28277; Sat, 6 Jun 1998 18:17:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA27048; Sat, 6 Jun 1998 18:24:04 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 18:24:04 -0700 (PDT) Sender: injector@clubneon.dyn.ml.org Message-ID: <3579EAF6.DF08EA53@stu.ac.cc.md.us> Date: Sat, 06 Jun 1998 21:20:54 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: ANNOUNCE: CVS is open ! References: <199806062309.BAA14189@orb.suntech.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"YFT4j.0.Nc6.okUUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2615 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I have updated the CVS webpage, http://www.ggi-project.org/docs/cvs.html . Could some people that know what they are doing have a look at it to make sure everything appears correct. I have never used CVS so I don't know if I got the information right. So go over it closely and e-mail me if you see anything wrong. Thanks, Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Sat Jun 6 18:23:13 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA28291; Sat, 6 Jun 1998 18:23:12 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA27493; Sat, 6 Jun 1998 18:30:21 -0700 (PDT) Resent-Date: Sat, 6 Jun 1998 18:30:21 -0700 (PDT) Date: Sat, 6 Jun 1998 19:58:43 -0500 (CDT) From: "Edward S. Marshall" To: Andrew Shuttlewood Cc: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ODTKi1.0.Tj6.hqUUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2616 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Andrew Shuttlewood wrote: > Is it impossible to make a license which prohibits people from making > API changes without consent from the internet community, but allowing > them to alter the code as they see fit? As soon as you can defined "internet community", you can make a license which does so. If you can't define it, then the license means nothing, unfortunately. Licenses aren't completely about rules, they're also about definitions. > Is this totally unrealistic? Or is possible to some degree? It seems > to be the best workaround to the problem in the long run... You need a way of having a definable organization to answer questions like "can we make this API change?" before you can write a license like that. (Not that I think a registered "GGI Project, Inc." type of orgaization is a good idea, for various other reasons, but it would fix this particular problem easily.) -- -------------------. emarshal at logic.net .--------------------------------- Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/ Linux labyrinth 2.1.101 #2 SMP Sun May 10 22:34:20 GMT 1998 i586 unknown 7:50pm up 8 days, 21:10, 5 users, load average: 0.48, 0.46, 0.41 From ggi-develop-request@eskimo.com Sat Jun 6 18:32:06 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA28299; Sat, 6 Jun 1998 18:32:05 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA24243; Sat, 6 Jun 1998 18:28:39 -0700 Resent-Date: Sat, 6 Jun 1998 18:28:39 -0700 Date: Sat, 6 Jun 1998 19:51:25 -0500 (CDT) From: "Edward S. Marshall" To: MenTaLguY Cc: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"974OM1.0.gw5.7pUUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2617 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, MenTaLguY wrote: > GPL will not prevent us from cooperating from companies like Sun, say, if > they want KGI, since we, the copyright holders, will still be free to make > an exception and give them code under a license compatible with linking into > their kernel. "we, the copyright holders" That statement is huge. Consider what that meant in the scope of the Linux kernel, back in its infancy. Consider the magnitude of it now. "we, the copyright holders" can grow infinitely large. All you need is -one- dissenting opinion, and a license change is impossible. At this point, most of those involved in the project are available, and can be brought in on a licensing discussion. In a year, what are the chances taht you'll find -everyone- who has contributed code to the project, with a copyright of their own on that piece of code? Welcome to open source. :-) Just like proprietary software, there are problems here too. > GPL allows anyone to benefit from the code -- except in cases where it would > be at the expense of everyone else. That's something X-style and BSD > licenses don't accomplish. I agree completely with that viewpoint...when discussing applications. Core tools that are meant to be used in conjunction with a wide variety of licenses by necessity must take the lowest common denominator in terms of restrictions, or you'll lose the cross-platform attractiveness that GGI craves. GPL v2 on libggi (and the other libraries) prevents the use of it by commercial (closed-source) application developers. How many of the game developers you're hoping to attract to using GGI as a base will do so when they realize that to do so means releasing the source to their projects? GPL v2 on KGI/evstack (and any other kernel pieces) prevents the use of it by any non-GPL kernel, including *BSD and every commercial UNIX available today. In fact, I believe you'll restrict use to TWO kernels: Linux and Hurd. I can't comment on LGPL. I haven't read that license in ages. But for something like this, that many applications will be built on, the license must be chosen -very- carefully. As much as I think the NPL/MPL are inappropriate for Netscape's software, they might be surprisingly appropriate for GGI, and give an air of credibility to the license. Has anyone considered them for use? -- -------------------. emarshal at logic.net .--------------------------------- Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/ Linux labyrinth 2.1.101 #2 SMP Sun May 10 22:34:20 GMT 1998 i586 unknown 7:35pm up 8 days, 20:55, 5 users, load average: 0.50, 0.50, 0.37 From ggi-develop-request@eskimo.com Sat Jun 6 22:41:30 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA28359; Sat, 6 Jun 1998 22:41:27 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA07999; Sat, 6 Jun 1998 22:38:22 -0700 Resent-Date: Sat, 6 Jun 1998 22:38:22 -0700 From: Andrew Apted Message-ID: <19980607153557.24087@ajax.netspace.net.au> Date: Sun, 7 Jun 1998 15:35:57 +1000 To: ggi-develop@eskimo.com Subject: Re: Duplicate mails? Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Steve Cheng on Sat, Jun 06, 1998 at 05:44:46PM -0400 Resent-Message-ID: <"SLBF6.0.iy1.DTYUr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2618 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Steve Cheng writes: > Problem with mailing list? > Or may be I'm the only one? > I sometimes get duplicate messages (no particular person) on the list. Me too. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Sun Jun 7 01:49:16 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA28611; Sun, 7 Jun 1998 01:49:14 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA24622; Sun, 7 Jun 1998 01:47:46 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 01:47:46 -0700 (PDT) Sender: thomas@sun1.muenchen-land.baynet.de Message-ID: <357A51E0.F2D5D86F@gmx.de> Date: Sun, 07 Jun 1998 10:40:00 +0200 From: Thomas Tanner X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: GGI mailing list Subject: Re: Duplicate mails? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"clXSi.0.c06.mEbUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2619 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Steve Cheng wrote: > > Problem with mailing list? > Or may be I'm the only one? > I sometimes get duplicate messages (no particular person) on the list. Me too. And I sometimes get mails with a delay of two or three days. BTW: Is there no mailing list archive for last month? -- Thomas Tanner ----------------------------- email: tanner@gmx.de tanner@ggi-project.org web: http://home.pages.de/~tanner GGI: http://www.ggi-project.org From ggi-develop-request@eskimo.com Sun Jun 7 02:32:28 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA28724; Sun, 7 Jun 1998 02:32:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA27924; Sun, 7 Jun 1998 02:33:26 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 02:33:26 -0700 (PDT) Sender: injector@clubneon.dyn.ml.org Message-ID: <357A5C83.D5F4E2FF@stu.ac.cc.md.us> Date: Sun, 07 Jun 1998 05:25:23 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Duplicate mails? References: <357A51E0.F2D5D86F@gmx.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"TCVSm3.0.Bq6.avbUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2620 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Thomas Tanner wrote: > > BTW: Is there no mailing list archive for last month? Where were you looking for the archive? The one on the web site is there. I thought I got the ftp one, but I could be wrong. The server is awful slow right now, and I can bearly connect (seems a couple people are interested in the CVS?), or I'd look before posting this. So if you could let me know where you didn't find the archive I'll see if I can figure it out. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Sun Jun 7 06:43:19 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA28874; Sun, 7 Jun 1998 06:43:17 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA16556; Sun, 7 Jun 1998 06:46:49 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 06:46:49 -0700 (PDT) From: Andrew Apted Message-ID: <19980607162154.16427@ajax.netspace.net.au> Date: Sun, 7 Jun 1998 16:21:54 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi: get/put-buffers Reply-To: ggi-develop@eskimo.com References: <199806051139.NAA27732@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806051139.NAA27732@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Fri, Jun 05, 1998 at 01:39:38PM +0200 Resent-Message-ID: <"sjCpW1.0.W24.6dfUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2621 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com [another 2nd try -- you didn't think I would be quiet on this subject ? :-)] Hartmut writes: > It looks like (from many posts I read) that we have to > - make the buffer layout as similar as possible to the main visual > layout, for maximum speed. > - not provide any conversion routines in the base libggi API. > - give some access to the buffers. I propose that ggiCrossBlit() is kept (albeit without the stretching), and that the same depth transfers are optimised (e.g. by me :) to perform fast conversion. This is the necessary fallback mechanism when a program does not understand either the DirectBuffer or the PixelLayout format (e.g. RGB 6:6:4). Without it, a program would have to resort to using ggiPutPixel(vis, x, y, ggiMapColor(vis, &col)) -- *much* slower. > Question: can we safely assume that the buffer is > pixelwise linear, that means that pixels are stored > with increasing x next to each other, and that first the lines with > lower y , then those with higher y are stored, i.e. a rectangle > with a width of three and a height of two will be stored > pixel (0,0) (1,0) (2,0) (0,1) (1,1), (2,1) in that order? Yep. > If we guarantee that, only the pixel format has to be defined, > and this has far less posibilities than the direct-buffer struct > can hold, and using a directbuffer struct for communicating > this information is overkill. > > There are two possibilities: > - The pixel layout used for Get/PutHline and friends is guaranteed > to be the same as for the frame buffer [1]. > Then either the direct buffer or the enhanced mode struct, see my > mail about the (memory) visual memory layout, carry this > information. Yes, and I think the "ggi_common_plb_setup" values are just perfect for the job. With your other proposal of putting this in a new "ggi_mode.pixelfmt" field, we can kill two birds with one stone. > For other 'strange' modes (did somebody recently talk about > 5-bit planar modes on Amiga?) we would probably pad the internal > pixel representation to full bytes anyway, wouldn't we? Yup. > I propose > - we guarantee that one pixel consumes either k bytes (packed > true colour) or 2**n bits (covering 1,2,4-bpp modes). > If the hardware has other sizes (like 30 bits), they will be > padded. (This is IMHO needed to reduce bit-shifting) Agreed. > - we guarantee that the pixels are stored linearly on all targets. Agreed. > - the exact pixel layout will define > - how many bits per pixel > - what colour model > - what bits are where (rrrrgggg as oposed to ggggrrrr) Don't forget endianess (normal vs reverse). All those things are covered by the ggi_common_plb_setup values in the DirectBuffer headers. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Sun Jun 7 06:45:21 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA28879; Sun, 7 Jun 1998 06:45:19 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA16574; Sun, 7 Jun 1998 06:46:54 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 06:46:54 -0700 (PDT) From: Andrew Apted Message-ID: <19980607160059.64690@ajax.netspace.net.au> Date: Sun, 7 Jun 1998 16:00:59 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi API: frames, z-Buffers and so on Reply-To: ggi-develop@eskimo.com References: <199806050742.JAA24233@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806050742.JAA24233@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Fri, Jun 05, 1998 at 09:42:59AM +0200 Resent-Message-ID: <"1GaM82.0.o24.BdfUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2622 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com [2nd try, my first post must have got eaten by a grue :)] Hartmut writes: > Andy suggested that he will chnange the libggi *implementation* to allow to > override the setmode calls, so I propose to > - not deal at all with Z-Buffers, texture buffers and so on > in libggi. Agreed. > Double-buffering OTOH is quite basic and affects ALL graphics primitives. > so i propose to > - add support for multiple frame buffers (of equal size and organisation) > into libggi. > > As accessing the ggi_mode struct is documented and a frames element > defined, I propose > - not to change the ggi_mode struct and document to use the frames field > to indicate the number of frames needed, and > - not to change the current set*Mode calls. Also agreed. > I propose that the frames are numbered 0..(num-1). > > I propose that after mode setting number 0 is the current screen > for display and writing/reading. > > I propose the following four calls for switching the frame: > > - ggi_error ggiSetDisplayFrame(vis, int frameno) > - ggi_error ggiSetDrawingFrame(vis, int frameno) > - int ggiGetDisplayFrame(vis) > - int ggiGetDrawingFrame(vis) Agreed 100%. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Sun Jun 7 13:36:55 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA29388; Sun, 7 Jun 1998 13:36:52 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA13095; Sun, 7 Jun 1998 13:25:43 -0700 Resent-Date: Sun, 7 Jun 1998 13:25:43 -0700 Date: Sun, 7 Jun 1998 16:30:18 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: LGPLed LibGGI ok for commercial developers (Was: Re: KGI license?) In-Reply-To: <199806071501.LAA13806@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"G8cTy3.0.UC3.6TlUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2623 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Edward S. Marshall wrote: > GPL v2 on libggi (and the other libraries) prevents the use of it by > commercial (closed-source) application developers. How many of the game > developers you're hoping to attract to using GGI as a base will do so when > they realize that to do so means releasing the source to their projects? LibGGI is under *L*GPL v2, not GPL v2. There's a signficant difference, since it allows closed-source developers to link to it. There's really no solid reason that we can't use LGPL for libGGI. Now ... we do still need to work out what we should do for KGI. -=MenTaLguY=- From ggi-develop-request@eskimo.com Sun Jun 7 15:07:02 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA29480; Sun, 7 Jun 1998 15:07:00 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA00888; Sun, 7 Jun 1998 15:09:12 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 15:09:12 -0700 (PDT) Message-ID: <19980607165806.45204@fries.net> Date: Sun, 7 Jun 1998 16:58:06 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: KGI license? References: <199806061800.LAA17775@nova.botz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199806061800.LAA17775@nova.botz.org>; from Jurgen Botz on Sat, Jun 06, 1998 at 11:00:52AM -0700 Resent-Message-ID: <"anKmN1.0.gD.6-mUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2624 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, Jun 06, 1998 at 11:00:52AM -0700, Jurgen Botz wrote: > Somebody wrote: > > > Please remember that RMS himself advocates an X-style license instead of > > > a BSD license, > > Yes. And the recent debacle with the Open Group's taking X out of > the open software arena and releasing bugfixes for critical security > bugs only to paying members shows just why the GPL is such a good > idea. Actually it simply illustrates the opposite point. XFree is continuing to release a free reference version of X. The vendors using the X11R6.4 code only suggests that the vendors will be more compatible with XFree. X standards are being decided by the world not XFree. At least they are accepted. There will be, I have been told, no new GPL code in OpenBSD. It does not make sense to have one part BSD license and another part of the same project be lgpl. If it is, it will not even be considered by OpenBSD. I personally expect the same from NetBSD and FreeBSD, but cannot speak for them. Oh, and btw, XFree will not incorporate gpl or lgpl code. It doesn't matter if you put Xggi under 'free' licensing terms, libggi isn't free in the same way so it won't float. What is wrong with XFree's license? XFree marches on as a free implementation, usable by all free os's. If you do not want your idea to be popular or gain any acceptance outside of Linux such as XFree has, then, I'm sorry. There's nothing I can do to convince you. I thought we changed it from linux-ggi to ggi for a reason. -- Todd Fries .. toddf@acm.org Copyright c 1996 X Consortium Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, dis- tribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the fol- lowing conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABIL- ITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABIL- ITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium. X Window System is a trademark of X Consortium, Inc. From ggi-develop-request@eskimo.com Sun Jun 7 15:10:13 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA29488; Sun, 7 Jun 1998 15:10:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA01360; Sun, 7 Jun 1998 15:12:24 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 15:12:24 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <357B0F51.1E72E7C@cistron.nl> Date: Mon, 08 Jun 1998 00:08:17 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: LGPLed libggi NOT ok for BSD (Re: LGPLed LibGGI ok for commercial developers (Was: Re: KGI license?)) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"qK3cK1.0.5L.31nUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2625 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com MenTaLguY wrote: > > On Sat, 6 Jun 1998, Edward S. Marshall wrote: > > GPL v2 on libggi (and the other libraries) prevents the use of it by > > commercial (closed-source) application developers. How many of the game > > developers you're hoping to attract to using GGI as a base will do so when > > they realize that to do so means releasing the source to their projects? > > LibGGI is under *L*GPL v2, not GPL v2. There's a signficant difference, > since it allows closed-source developers to link to it. There's really no > solid reason that we can't use LGPL for libGGI. Apparantly you've not read my response to Andrew's post. There's a problem for *BSD (I mentioned some of the reasons why the LGPL is not liked by BSD'ers when we started the BSD port discussion a few months a go) and this can cause a cloned BSD'ed libggi to appear. That's something we really don't need. In fact, your other post about the license contains a lot of stuff that's completely false: 1. BSD licensed stuff being abused. What do you mean? BSD allows proprietary use. 2. GPL is not more free: the reasons you give have nothing whatsoever to do with freedom but with 'getting back improvements/changes' 3. Misleading statement: 'preserve _our_ ability to use and benefit from _our_ code': You will always have the ability to use the code you put under any license. You _will_ get back any improvements/changes when GPL'ing, but, you will change the set of people using it and people contributing to it. So there's a choice. Both give contributions. You choose from which side. There is NOT a well ordered relation of getting code back such that BSD < GPL (esp. for libs and low level stuff, as I mentioned before; for apps a GPL style license will likely give back more, depending on the app in question). 4. 'GPL allows anyone to benefit from the code -- except in cases where it would be at the expense of everyone else. That's something X-style and BSD licenses don't accomplish.' : Not true. Various companies won't use it and thus it won't benefit everone. And this is not just in cases where it would not benefit everyone (e.g. the static linking issue may be important for speed etc) 5. 'except ... at the expense of everyone' is untrue. 6. The libggi split can happen at any time. As libggi (esp. the part only needed for KGI support) is quite small, this is not very difficult, and just as lesstif is a cloned motif, so can libggi be cloned and made proprietary. > Now ... we do still need to work out what we should do for KGI. No we don't. That was not the problem. My suggestion is to make the base libggi +KGI etc BSD2 (the 2 clause BSD license) and anything fancy like font libraries, libggi3d etc could be LGPL. If XGGI cannot be run on a pure BSD licensed system, it won't be part of *BSD, but an optional piece. Wouter From ggi-develop-request@eskimo.com Sun Jun 7 16:05:30 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA29622; Sun, 7 Jun 1998 16:05:27 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA08328; Sun, 7 Jun 1998 16:05:51 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 16:05:51 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <357B1821.2A7CFF3A@cistron.nl> Date: Mon, 08 Jun 1998 00:45:53 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: libggi: palettes References: <199806041209.OAA27849@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8JoAS1.0.022.DpnUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2626 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > The decision algorithm can be as complicated as you want, but it will normally > very simple, and I see good reason for this. > - normally you put all entries into the palette you want to have at > startup, so each application sets the palette only once. > - For a fullscreen mode, there is nobody competing about the CLUT, so > set s=0. If you don't want to implement it differently, too. > - On X it might be good to allocate from the end, to have the 'general' > colours not messed up. > Wouter (?) said he had code to copy the system-wide X palette into a > private one and to allocate some colours there. Yes, I have that code if anyone needs it. Wouter From ggi-develop-request@eskimo.com Sun Jun 7 16:05:59 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA29626; Sun, 7 Jun 1998 16:05:58 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA23101; Sun, 7 Jun 1998 16:04:03 -0700 Resent-Date: Sun, 7 Jun 1998 16:04:03 -0700 Sender: wouter@cistron.nl Message-ID: <357B1C27.245CAF92@cistron.nl> Date: Mon, 08 Jun 1998 01:03:03 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: GGI develop Subject: Undisplayed screen parts and stuff Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"U6wk12.0.qe5.YnnUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2627 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com LS, Here's the problem: v 1. I have a 320x200 program that looks ok on a 14" monitor but looks very very ugly on a 15" or bigger monitor. v 2. I have a 320x200 program that looks ok full screen in a 320/200 aspect ratio mode but looks squashed when running in X (4/3 aspect ration) The solution would be to have non-displayed parts of the screen. I.e. not use 320x200 modes but a 320x200 subset of 320x240, and for example use 320. This could be done automatically given the monitors specifications such that pixels are not larger than a given maximum). This would need an API change probably. The only alternative at this moment is to use a larger virtual screen and use only part of it, but this does not take into account the monitor size without ugly workarounds (perhaps add a function to get the pixel size/monitor size?) Is it possible ? Btw, was that monitor data base Sengan (I believe) got permission to use ever used at all? The number of monitor specifications included in GGI has increased but not that much. Wouter From ggi-develop-request@eskimo.com Sun Jun 7 16:18:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA29665; Sun, 7 Jun 1998 16:18:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA09820; Sun, 7 Jun 1998 16:17:29 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 16:17:29 -0700 (PDT) Date: Sun, 7 Jun 1998 19:15:18 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: licensing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"fHPGH.0.CP2.4-nUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2628 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com yow. I don't think I need to quote from Wouter's post deconstructing my argument -- he's made his point very completely. Anyway, he's right. Those are (mostly) the same arguments I've been using on myself to maintain my stance, and if I'm going to be intellectually honest here, I'll have to admit my position was pretty much untenable. So, the upshot of this is that I agree that we'd better go with a BSD license for LibGGI if we don't want to alienate the BSD folks. All other things being equal, I'd still opt for LGPL over BSD. They're not, though, and BSD isn't that bad at all. Just for the record, I didn't mean to imply that both BSD and X licenses had been abused, although I'm afraid that that's what I wrote. Even what I was counting as abuse of the X license wasn't strictly so (as far as I know the terms of the license were not violated). Even so, the free software community still got screwed over, though, not having the fixes availible to them. -=MenTaLguY=- From ggi-develop-request@eskimo.com Sun Jun 7 16:29:16 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA29698; Sun, 7 Jun 1998 16:29:13 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA24908; Sun, 7 Jun 1998 16:26:37 -0700 Resent-Date: Sun, 7 Jun 1998 16:26:37 -0700 X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Mon, 8 Jun 1998 01:25:45 +0200 (MET DST) From: Stefan Mars To: ggi-develop@eskimo.com Subject: Re: LGPLed libggi NOT ok for BSD (Re: LGPLed LibGGI ok for commercial developers (Was: Re: KGI license?)) In-Reply-To: <357B0F51.1E72E7C@cistron.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"twvy42.0.456.j6oUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2629 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 8 Jun 1998, W. Scholten wrote: > 1. BSD licensed stuff being abused. What do you mean? BSD allows > proprietary use. I can't speak for MentalGuy, who wrote what caused the above reply. However, I do have a comment of my own. It is true that BSD can't be abused in this way, because it allows for proprietary use. But in my mind it is exactly that allowance that makes BSD so unacceptable to me. I write code for fun, because I like it, in essence I do it for myself. I distribute it to others in the hope that they will find it useful, that at least someone som day will have that short thought "I thank the author of this program for doing this. This app is excellent and has really helped me getting more productive" (or have more fun, whatever we are talking about. That does not mean that I want to see someone else making money from code I have written. I accept people like RedHat who charges a distribution fee, and who charges for support of the product. But if someone is trying to sell my program, or use it as a base for another program to sell, hence making money out of it, then I want my share. I don't mind giving it away to the community under GPL/LGPL, but if someone shall make money, then it is me, because I wrote the damn thing. And that's why I can't support BSD license. Now, it is my understanding, that the BSD people can't use GPL code in their kernel, and if we want them to incorporate GGI/KGI into their kernel, then we will have to change license. Ok, I can go that far in order to help GGI become a standard. There are good reasons for not leaving any open-source "free" OS behind (as well as good reasons to support the commercial ones), and besides I haven't written anything of the actual kernel :). But it should stop there. If BSD doesn't want to use a LGPL LibGGI, then I say that is their problem, and if they want to write a new one from scratch and hence reinvent the wheel, by all means, let them. I don't really know right now what I will do if the license becomes changed.. someone here (Andrew perhaps?) once said in a mail that if the license becomes changed to a BSD style, then his interest in contributing would greatly diminish. The same is true for me. I am saving money to buy hardware to port GGI/KGI to, to write new drivers for. Probably the hardware will still be bought, but will I do the ports? I don't know. I will probably always remain in the GGI project in the meaning that I will write apps (where I myself can decide the license), and I will finish the directx port (LGPLed license, and will stay that way). But how certain can anyone be. It is with some sadness that I see that an issue like this, a license issue, is taking so much time and energy from what we really ought to be doing, and that's coding. But for most people, and certainly including myself, it's a very infected question that revolvs around principles, ideals and feelings. Still.. I'm sad. -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Sun Jun 7 16:34:41 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA29727; Sun, 7 Jun 1998 16:34:39 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA12782; Sun, 7 Jun 1998 16:36:00 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 16:36:00 -0700 (PDT) X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Mon, 8 Jun 1998 01:28:15 +0200 (MET DST) From: Stefan Mars To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <19980607165806.45204@fries.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"XJa6J1.0.c73.TFoUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2630 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 7 Jun 1998, Todd T. Fries wrote: > Oh, and btw, XFree will not incorporate gpl or lgpl code. It doesn't matter > if you put Xggi under 'free' licensing terms, libggi isn't free in the same > way so it won't float. What is wrong with XFree's license? Xggi doesn't incorporate code that is gpl or lgpl (unless Krausse put the server itself under it, something which it is my understanding that he can't do), but instead we _link_ against LibGGI. That is not the same thing as incorporating the code, and quite frankly I don't see the problem. -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Sun Jun 7 16:46:49 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA29861; Sun, 7 Jun 1998 16:46:46 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA15343; Sun, 7 Jun 1998 16:52:05 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 16:52:05 -0700 (PDT) Date: Sun, 7 Jun 1998 18:47:48 -0500 (CDT) From: ixx Reply-To: taylorcc@arn.net To: ggi-develop@eskimo.com Subject: Re: LGPLed libggi NOT ok for BSD (Re: LGPLed LibGGI ok for commercial developers (Was: Re: KGI license?)) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"jGaEB1.0.cl3.YUoUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2631 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com now I am for lgpl but I want to make a few comments. On Mon, 8 Jun 1998, Stefan Mars wrote: > from code I have written. I accept people like RedHat who charges a > distribution fee, and who charges for support of the product. But if > someone is trying to sell my program, or use it as a base for another > program to sell, hence making money out of it, then I want my share. I > don't mind giving it away to the community under GPL/LGPL, but if someone > shall make money, then it is me, because I wrote the damn thing. I can get a GPL'd piece of software and sale it for oodles of money. GPL does not restrict me form doing that. It does require me to make the source available, aswell as any modifications I make. The purpose of the GPL is to keep the source open. Anyhow I agree with you for the rest of the stuff Stefan. Except I would rather be behind BSD than anything proprietary (close source [read not good for all]). Btw, what is the license for the binary-only drivers? taylorcc From ggi-develop-request@eskimo.com Sun Jun 7 17:05:38 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA30082; Sun, 7 Jun 1998 17:05:35 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA30473; Sun, 7 Jun 1998 16:56:34 -0700 Resent-Date: Sun, 7 Jun 1998 16:56:34 -0700 Date: Sun, 7 Jun 1998 18:54:16 -0500 (CDT) From: ixx Reply-To: taylorcc@arn.net To: ggi-develop@eskimo.com Subject: Re: licensing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"oAJ6g3.0.xR7.oYoUr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2632 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 7 Jun 1998, MenTaLguY wrote: > So, the upshot of this is that I agree that we'd better go with a BSD > license for LibGGI if we don't want to alienate the BSD folks. All other > things being equal, I'd still opt for LGPL over BSD. They're not, though, > and BSD isn't that bad at all. I think you may be right, though I too would rather have LGPL. Rather have all open source though. From ggi-develop-request@eskimo.com Sun Jun 7 18:16:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA30194; Sun, 7 Jun 1998 18:16:31 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA04209; Sun, 7 Jun 1998 18:22:08 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 18:22:08 -0700 (PDT) To: ggi-develop@eskimo.com Subject: Re: LGPLed libggi NOT ok for BSD (Re: LGPLed LibGGI ok for commercial developers (Was: Re: KGI license?)) References: MIME-Version: 1.0 X-Face: #.`T$>|mFxfHna0Wy-(\k3d5TWne~qr.cVHv(ye95XPctC&SXXcZJOPdbqzjWOsgO9AK"/9 unLFS+cdbl&EIVhO2yVW ~z8*h(Rbpng{9B+,_gj+OM{%8O|h5~'Lo=N6jPvwp.vp240Z"`&I(\(#s5[:`y%MIX,%[L=vQJi[S, `B:!}As%w97=Ut[9Eg<(*(^LDD8g Content-Type: text/plain; charset=US-ASCII From: Peter Bortas Date: 08 Jun 1998 03:00:55 +0200 In-Reply-To: Stefan Mars's message of "Mon, 8 Jun 1998 01:25:45 +0200 (MET DST)" Message-ID: <763edgg114.fsf@raven.idonex.se> Lines: 41 X-Mailer: Gnus v5.6.2/XEmacs 20.4 - "Emerald" Resent-Message-ID: <"GzPsD.0.a11.wopUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2633 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Stefan Mars writes: > On Mon, 8 Jun 1998, W. Scholten wrote: > > > 1. BSD licensed stuff being abused. What do you mean? BSD allows > > proprietary use. > > I can't speak for MentalGuy, who wrote what caused the above reply. > However, I do have a comment of my own. It is true that BSD can't be > abused in this way, because it allows for proprietary use. But in my mind > it is exactly that allowance that makes BSD so unacceptable to me. I write > code for fun, because I like it, in essence I do it for myself. I > distribute it to others in the hope that they will find it useful, that at > least someone som day will have that short thought "I thank the author of > this program for doing this. This app is excellent and has really helped > me getting more productive" (or have more fun, whatever we are talking > about. That does not mean that I want to see someone else making money > from code I have written. I accept people like RedHat who charges a > distribution fee, and who charges for support of the product. But if > someone is trying to sell my program, or use it as a base for another > program to sell, hence making money out of it, then I want my share. I > don't mind giving it away to the community under GPL/LGPL, but if someone > shall make money, then it is me, because I wrote the damn thing. I'm just a lurker in this list. I haven't coded anything for GGI right now, neither have I any plans to. I'm just jumping in to make a correction here: I can take your code and sell it for a buck-load of money if you put it under GPL. In fact, I sell GPL'ed code for a living. I happen to be a programmer on this particular piece of code (Roxen Challenger), but thats beside the point. In fact I can take your code, make changes to it, sell this modified code to a customer and refuse to send you the changes. This customer has of course the right to receive the source and give it to you if he'd want to. -- Peter Bortas http://peter.bortas.org Idonex AB http://www.roxen.com Lysator ACS http://www.lysator.liu.se zino@lysator.liu.se From ggi-develop-request@eskimo.com Sun Jun 7 19:06:11 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA30255; Sun, 7 Jun 1998 19:06:09 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA13256; Sun, 7 Jun 1998 19:00:11 -0700 Resent-Date: Sun, 7 Jun 1998 19:00:11 -0700 Sender: wouter@cistron.nl Message-ID: <357B4527.4A863CF0@cistron.nl> Date: Mon, 08 Jun 1998 03:57:59 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: KGI license? References: <199806061800.LAA17775@nova.botz.org> <19980607165806.45204@fries.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"JHvf2.0.yE3.gMqUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2635 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Todd T. Fries wrote: > There will be, I have been told, no new GPL code in OpenBSD. It does not > make sense to have one part BSD license and another part of the same project > be lgpl. If it is, it will not even be considered by OpenBSD. I personally > expect the same from NetBSD and FreeBSD, but cannot speak for them. You don't mean if KGI/libggi=BSD, and other stuff like libggi3d=LGPL then none of GGI will be used, do you? I would separate GGI into 2 parts: base + extensions. base=needed for any GGI on KGI application (which needs to be BSD to be included in *BSD), extension=advanced/higher level stuff (which could be LGPL or artistic or whatever) like libggi3d, the directx lib. Soeren Schmidt from the FreeBSD core team already said LGPL'ed drivers/essential libraries are not acceptable, but non-essential libraries? Regards, Wouter PS. I'm working on the KGI-OpenBSD port. Hope to get it running soon. From ggi-develop-request@eskimo.com Sun Jun 7 19:06:35 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA30260; Sun, 7 Jun 1998 19:06:34 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA14834; Sun, 7 Jun 1998 19:11:52 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 19:11:52 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <357B480A.692DF7F7@cistron.nl> Date: Mon, 08 Jun 1998 04:10:18 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: GGI develop Subject: Re: Undisplayed screen parts and stuff References: <357B1C27.245CAF92@cistron.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"AjOOH2.0.ed3.YXqUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2636 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com W. Scholten wrote: > The solution would be to have non-displayed parts of the screen. I.e. > not use 320x200 modes but a 320x200 subset of 320x240, and for example > use 320. This could be done automatically given the monitors > specifications such that pixels are not larger than a given maximum). > This would need an API change probably. This probably isn't very clear: what I'm getting at is that the display of the 320x200 area would be _as if_ it were part of a 320x240 area (i.e. with square pixels), but the mode would just be regular 320x200. Can this be done adjusting the chipset info on when to start writing to the screen etc. ? Wouter From ggi-develop-request@eskimo.com Sun Jun 7 19:07:47 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA30265; Sun, 7 Jun 1998 19:07:45 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA13223; Sun, 7 Jun 1998 19:00:05 -0700 Resent-Date: Sun, 7 Jun 1998 19:00:05 -0700 Sender: wouter@cistron.nl Message-ID: <357B3474.186332F7@cistron.nl> Date: Mon, 08 Jun 1998 02:46:44 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: licensing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Eb_4t3.0.PE3.aMqUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2634 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com MenTaLguY wrote: > > yow. I don't think I need to quote from Wouter's post deconstructing my > argument -- he's made his point very completely. Anyway, he's right. Those > are (mostly) the same arguments I've been using on myself to maintain my > stance, and if I'm going to be intellectually honest here, I'll have to > admit my position was pretty much untenable. I'm glad you take it this way. I was being pretty pedantic about it :) But this does come from the time not so long ago that I was heavily involved in all these discussions in various groups (mainly to get a good license for classes, what the GPL and also the LGPL aren't really designed for). I spent a lot of time making a license also, and consequently I tend to analyze any licensing statement and the results each has very carefully. I also like the 'you must give back improvements' of the GPL (otherwise I would have just BSD'ed my eiffel classes for example), but if a license doesn't give you the results you want, you have to change it. Regards, Wouter From ggi-develop-request@eskimo.com Sun Jun 7 19:20:08 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA30282; Sun, 7 Jun 1998 19:20:06 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA15186; Sun, 7 Jun 1998 19:17:51 -0700 Resent-Date: Sun, 7 Jun 1998 19:17:51 -0700 Message-ID: <19980607211441.44266@fries.net> Date: Sun, 7 Jun 1998 21:14:41 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: KGI license? References: <199806061800.LAA17775@nova.botz.org> <19980607165806.45204@fries.net> <357B4527.4A863CF0@cistron.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <357B4527.4A863CF0@cistron.nl>; from W. Scholten on Mon, Jun 08, 1998 at 03:57:59AM +0200 Resent-Message-ID: <"pNN_o2.0.7j3.EdqUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2637 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, Jun 08, 1998 at 03:57:59AM +0200, W. Scholten wrote: > Todd T. Fries wrote: > > > There will be, I have been told, no new GPL code in OpenBSD. It does not > > make sense to have one part BSD license and another part of the same project > > be lgpl. If it is, it will not even be considered by OpenBSD. I personally > > expect the same from NetBSD and FreeBSD, but cannot speak for them. > > You don't mean if KGI/libggi=BSD, and other stuff like libggi3d=LGPL > then none of GGI will be used, do you? Over emphasis, sorry :-) > I would separate GGI into 2 parts: base + extensions. base=needed for > any GGI on KGI application (which needs to be BSD to be included in > *BSD), extension=advanced/higher level stuff (which could be LGPL or > artistic or whatever) like libggi3d, the directx lib. > > Soeren Schmidt from the FreeBSD core team already said LGPL'ed > drivers/essential libraries are not acceptable, but non-essential > libraries? Non-essential libraries, aka that which will not make it into the tree proper, are as trivially dealt with as tcl/tk. Just make it an optional edition (aka a port) that can be retrieved and compiled at a user's discression. No, I don't think the win32 directx lib will be of much interest :-) > PS. I'm working on the KGI-OpenBSD port. Hope to get it running soon. Woohoo. x86 I presume? .. hopefully it'll be useful on the other arch's as well... I'd be glad to lend a hand when the time comes that you need one .. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Sun Jun 7 19:23:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA30291; Sun, 7 Jun 1998 19:23:31 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA16373; Sun, 7 Jun 1998 19:20:57 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 19:20:57 -0700 (PDT) Date: Sun, 7 Jun 1998 21:30:06 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: kgi/lib/libggi and kgi/driver interdependencies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"zpMzu2.0.f_3.4gqUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2638 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com For those that missed it on IRC and haven't checked the new struture out of CVS yet, vendor specific driver-libs are now stored separate from the kgi target and libggi, in kgi/lib/libggi. (The drivers are in kgi/driver/.) Q. I assume there is no problem in having kgi/driver/chipset// need kgi/lib/libggi// (and visa versa) to compile? More to the point, I'd like to link objects compiled in lib/libggi/WD/text16/ with -D__KERNEL__ into the driver module as part of my scroller. Is this cool or should we still have separate text16 stuff kept in kgi/driver/chipset/? Thanks. -- Brian S. Julin From ggi-develop-request@eskimo.com Sun Jun 7 19:42:09 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA30297; Sun, 7 Jun 1998 19:42:07 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA21421; Sun, 7 Jun 1998 19:47:07 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 19:47:07 -0700 (PDT) Date: Sun, 7 Jun 1998 22:44:54 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: Undisplayed screen parts and stuff In-Reply-To: <357B480A.692DF7F7@cistron.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"TAs9W.0.YE5.e2rUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2639 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 8 Jun 1998, W. Scholten wrote: > This probably isn't very clear: what I'm getting at is that the display > of the 320x200 area would be _as if_ it were part of a 320x240 area > (i.e. with square pixels), but the mode would just be regular 320x200. > Can this be done adjusting the chipset info on when to start writing to > the screen etc. ? Under the current API, you're only solution would be to get a 320x240 mode, wipe it black, and then only draw in a 320x240 box. But this rules out virt.y > visible.y. libGGICRT (or whatever it ends up being named) will allow physical size/position negotiation. -- Brian S. Julin From ggi-develop-request@eskimo.com Sun Jun 7 20:10:41 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA30312; Sun, 7 Jun 1998 20:10:37 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id UAA26099; Sun, 7 Jun 1998 20:11:52 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 20:11:52 -0700 (PDT) Date: Sun, 7 Jun 1998 23:09:27 -0400 (EDT) From: Steve Cheng Sender: steve@maxt9m11.ipoline.com To: GGI Mailing List Subject: IRC summary (part one) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"_FN8U.0.hN6.rPrUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2641 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com [IRC session summary: This summary highlights the important decisions reached on various aspects of GGI. I have included the basic rationale for the decision, if possible. I have quoted liberally, where the quoted material is clear. (If I have misquoted anyone, please correct me.) However, if more information is needed (e.g. why solution (B) was not adopted, etc.), please read the full log relevent to your topic. Especially I will not repeat the two licensing wars here :-) Now this summary has taken much longer than expected (need about two more hours). I'm really sorry, I don't have time to do the whole summary yet. This is the first part that is 'finished'; I promise to post the remaining parts tomorrow. Thanks your patience.] CVS Scheme ========== There are, of course, two CVS repositories: development and stable. Only a few people will access the stable repository, while all developers can use the devel repository. Both development and stable will have read access for all. Devel and stable are two different trees. Periodically, the stable maintainers will diff devel code back to stable and thoroughly check the code. This is to ensure that there are no incomplete/inconsistent/ uncoordinated changes to stable, and it will always work for non-GGI-developers. Development should go full speed at the devel tree as usual. Jason has committed KGI/EvStack into devel. New Directory Layout ==================== The KGI-specific "driver libraries" of LibGGI have been moved to the the kgi/ directory. This includes all the vendor-* libraries. The display-kgi target itself stays in LibGGI. Rationale: Easier separation between LibGGI and KGI, and to prevent the LibGGI tree to get too bloated. "They [KGI driver libraries] are taylored for specific KGi drivers. Though they are technically part of LibGGI, they have to be engineered to meet the KGI driver. Thus they should be close to it." "The patches directory will probably be renamed to something more generic and will hold all "OS-addendums" we need to make KGi drivers run on a particular OS." On the topic of includes and packaging: "... having a top-level include/ subdir, making a seperate package, as Stefan is suggesting, would be a good idea. this way the KGI target could remain part of libggi package, and the KGI backend libs can be moved to the kgi package" Makefile customization have been moved to a toplevel directory. The development trees will be a 'full' system, which includes almost everything. In the future, it should be possible to automatically "Split things to several packages that can be downloaded seperately [for non-developers]. The goes for Libs and such. [also: vendor libs]" New LibGGI Extension Scheme =========================== For full API details, please read Andy's message to the GGI mailing list. Basically it allows per-visual extending and overriding of the underlying API. Some things that are currently in core LibGGI will be moved out to a smaller extension: * ggi*RayPos and friends -- CRT specifics * other "mode tweaking" * ggiSetSplitLine Rationale: Not all targets implement the above functionality nor do they make sense on some targets. Eases porting of main libGGI. Complex Mode Negotiation ======================== "The new extension scheme allows to connect into the communications channel established by the LibGGI display-* module. This means, that we can link into the communication LibGGI->X or LibGGI->KGI and thus even change very basic things like mode negotiation. This enables us to schedule the complex mode negotiation for later and make mode negotiation schems that fit the current application (3D, video, ...)" LIBGGI Topics 1) Multiple Buffering ===================== Multi-buffered modes will be done by setting the "frames" member of the ggi_mode struct and passing that to ggiSetMode(). Two manipulte buffers, use: * SetDisplayedFrame() * SetDrawingFrame() ggiFlush() simple clipping to enhance targets having to emulate a DirectBuffer ============================================================================== Have "some kind of clipping list which is initialized to the full display, and reinitialized to that after a ggiFlush() .. and modified by a new call. This way, old applications will still update the full framebuffer, while applications aware of the new call can restrict changes.." Nested calls to ggiInit()/ggiExit() =================================== "Change returncodes, so you can detect it was the last "Exit" that actually cleaned things up." (These calls will nest, and are paired. ggiInit(), if already called, will just increase the counter, and decrement on ggiExit(). When it reaches zero ggiExit() will really deinit the library.) Switch-away/Switch-back Behavior ================================ Question: "What has to be done when a program is switched away (either the window (in X) becomes inactive, or the VT is switched), and on re-activation?" No protocol implementing any of this behaviour has been decided. Possible solutions: "A callback mechanism (Extensions already have it) that handles this." Or the program can specify behaviour to library. Current KGI implementation: "On switch-away (loss of input focus) a libGGI app gets SIGTSTP. On regain of focus, libGGI app gets SIGCONT. If the app has to redraw, gets SIGWINCH" (Iconification and focus change of windowed targets are other similar situations but no specific protocol has been decided.) // Steve e-mail: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Sun Jun 7 20:11:16 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA30317; Sun, 7 Jun 1998 20:11:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id UAA19707; Sun, 7 Jun 1998 20:05:50 -0700 Resent-Date: Sun, 7 Jun 1998 20:05:50 -0700 Message-ID: <19980607220528.60111@AeroSpace> Date: Sun, 7 Jun 1998 22:05:28 -0500 From: David Fries To: ggi-develop@eskimo.com Subject: Re: CVS passwords References: <199806061006.MAA10807@orb.suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199806061006.MAA10807@orb.suntech.fr>; from Emmanuel Marty on Sat, Jun 06, 1998 at 12:01:32PM +0200 X-URL: http://aerospace.miango.com/~david/ Resent-Message-ID: <"DfPci3.0.pp4.EKrUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2640 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, Jun 06, 1998 at 12:01:32PM +0200, Emmanuel Marty wrote: > Hello, > > Could the persons listed below, send me by _private_ email, > a crypted-passwd for "development branch" CVS access ? Thanks :) > > David Fries I'm still working on my ggi driver for the Trident video card. It is a slow go with everything else going on, but I finally figured out how to access all the registers (it appears one register "type" is accessed differently in MMIO and not documented, that threw me for a very long loop). So right now it is text only and they are better to go with the IBM driver. I do plan to change this, but concidering I have never touched VGA hardward before I have a long way to go. I just wanted to drop a note saying I didn't go away, I'm just not ready to put my code in. -- +---------------------------------+ | David Fries | | dfries@mail.win.org | +---------------------------------+ From ggi-develop-request@eskimo.com Sun Jun 7 20:12:20 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA30322; Sun, 7 Jun 1998 20:12:19 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id UAA20115; Sun, 7 Jun 1998 20:12:10 -0700 Resent-Date: Sun, 7 Jun 1998 20:12:10 -0700 Message-ID: <19980607214306.12200@fries.net> Date: Sun, 7 Jun 1998 21:43:06 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: ANNOUNCE: anoncvs.us.ggi-project.org is open ! References: <199806061800.LAA17775@nova.botz.org> <19980607165806.45204@fries.net> <357B4527.4A863CF0@cistron.nl> <19980607211441.44266@fries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e Resent-Message-ID: <"ze_Bn1.0.6w4.9QrUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2642 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I will mirror nightly at midnight CDT. There are two ways you may access this archive, totaling four possible CVSROOT variables: Method One ---------- CVSROOT=:pserver:anoncvs@anoncvs.us.ggi-project.org:/cvs CVSROOT=:pserver:anoncvs@anoncvs.us.ggi-project.org:/cvsdevel You will have to login. The password is anoncvs. Method Two ---------- For those of you who prefer ssh, and not to login, use: CVS_RSH=ssh CVSROOT=anoncvs@anoncvs.us.ggi-project.org:/cvs CVSROOT=anoncvs@anoncvs.us.ggi-project.org:/cvsdevel Please let me know if there are any problems. I'm on ISDN 128k + stac compression, so don't be expecting T1 or OC3 or anything fancy like that :-) -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Sun Jun 7 21:10:45 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA30351; Sun, 7 Jun 1998 21:10:42 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA07763; Sun, 7 Jun 1998 21:12:14 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 21:12:14 -0700 (PDT) X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Mon, 8 Jun 1998 06:04:28 +0200 (MET DST) From: Stefan Mars To: ggi-develop@eskimo.com Subject: Re: LGPLed libggi NOT ok for BSD (Re: LGPLed LibGGI ok for commercial developers (Was: Re: KGI license?)) In-Reply-To: <763edgg114.fsf@raven.idonex.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Fg9Mg1.0.7v1.RIsUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2643 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On 8 Jun 1998, Peter Bortas wrote: > I can take your code and sell it for a buck-load of money if you put it > under GPL. In fact, I sell GPL'ed code for a living. I happen to be a As bort Peter and ixx has pointed out to me it is indeed you can indeed sell GPL code. On the other hand, since they must give any changes to the source back to the community, a person would simply download and compile himself and avoid paying. You all know what I mean :) -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Sun Jun 7 21:27:00 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA30378; Sun, 7 Jun 1998 21:25:38 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA11970; Sun, 7 Jun 1998 21:31:33 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 21:31:33 -0700 (PDT) From: bkosse@iname.com Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 07 Jun 1998 21:26:48 -0700 (PDT) Reply-To: bkosse@iname.com Sender: ben@wyrmslayer.warewolf.com To: ggi-develop@eskimo.com Subject: Licensing woes.... (or, LGPL vs. BSD) Resent-Message-ID: <"dO4w81.0.sw2.YasUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2644 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Would someone, anyone, PLEASE tell me what is so godaweful about the L-GPL? It seems that the *BSD guys seem to think that L-GPL performs the same viral infection as GPL only it is more prevelant. I think that if the *BSD guys want pure BSDL code then they can go and write their own LibGGI. As far as I can tell, all that L-GPL does is force you to allow your users to relink against the most current version of the library (on a dynamic system, there's nothing else to do whereas on a static system, you have to provide, at the *USER'S* request, object code. Note, Sun already does this with their kernel). Hell, all you BSD folks, you've already *GOT* a critical component on LGPL and that is your C runtime library, assuming of course that GCC is the standard compiler on the *BSD's. Placing LibGGI under LGPL is NOT a bad thing. Placing it under BSD style licensing is, unfortunately, asking for trouble and while we might spread quicker, we will end up with mutually exclusive and incompatible LibGGI's very quickly if a commercial vendor (i.e. Sun or SGI) decide LibGGI is a good thing. They did it before with Unix proper, they will most likely do it again with something even easier to mess with. (Rather, the problem will be their stuff doesn't compile on Linux but the reverse will be true.) -- Ben Kosse http://www.rit.edu/~bmk7411 The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- Nietzsche From ggi-develop-request@eskimo.com Sun Jun 7 23:41:51 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA30515; Sun, 7 Jun 1998 23:41:49 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id XAA07076; Sun, 7 Jun 1998 23:40:32 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 23:40:32 -0700 (PDT) Date: Mon, 8 Jun 1998 02:33:04 +0000 (GMT) From: Michael Funk X-Sender: mwfunk@foo.bar.com Reply-To: mwfunk@uncc.campus.mci.net To: ggi-develop@eskimo.com Subject: Re: Licensing woes.... (or, LGPL vs. BSD) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"PYqtq2.0.Sk1.UTuUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2645 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 7 Jun 1998 bkosse@iname.com wrote: > Would someone, anyone, PLEASE tell me what is so godaweful about the L-GPL? > > It seems that the *BSD guys seem to think that L-GPL performs the same viral > infection as GPL only it is more prevelant. No. This is not true. No one is concerned about 'infection'; everyone knows what the purpose of the LGPL is. Disinformation is not the issue. > I think that if the *BSD guys want pure BSDL code then they can go and write > their own LibGGI. The issue isn't BSDL, it's copyleft. They'd be perfectly happy with an X-ish license or whatever. Regardless of its good intentions or whether or not it does what it's supposed to do, or whether or not one buys into the ideology, the LGPL is a restrictive license (regardless of whether or not you think the restrictions are good; they're still restrictions). LGPL costs you much and buys you little. > As far as I can tell, all that L-GPL does is force you to allow your users to > relink against the most current version of the library (on a dynamic system, > there's nothing else to do whereas on a static system, you have to provide, at > the *USER'S* request, object code. Note, Sun already does this with their > kernel). It does a lot of stuff! It's a big, long, complicated license full of all sorts of restrictions, and one can't take code from an LGPL'd library and use it in a non-copyleft project. It's isn't a (L)GPL vs. BSDL thing, it's a (L)GPL vs. the world thing. > Hell, all you BSD folks, you've already *GOT* a critical component on LGPL and > that is your C runtime library, assuming of course that GCC is the standard > compiler on the *BSD's. gcc, yes, libc, no. > Placing LibGGI under LGPL is NOT a bad thing. Placing it under BSD style > licensing is, unfortunately, asking for trouble How on earth is it "asking for trouble"? Rather, it's "not alienating a whole bunch of people". This is sounding less like "share the software" and more like some sort of "us vs. them" thing, except it's not clear who "they" are (corporations, other free software projects, academia...?), or what is to be gained by "beating" them, at whatever mysterious game is being played here. > and while we might spread > quicker, we will end up with mutually exclusive and incompatible LibGGI's very > quickly if a commercial vendor (i.e. Sun or SGI) decide LibGGI is a > good thing. This is highly unlikely, and they wouldn't benefit from it if they did do this. The free software version would always be the standard. Heck, if anything, they might decide to contribute to it. > They did it before with Unix proper, Darn that diversity! Are you suggesting everyone should've stuck with Version 7, which, by the way, was all proprietary code? That was the last time there was anything around that could be called "Unix proper", and it predates both of the companies you mentioned by a number of years. > they will most likely do it again with > something even easier to mess with. (Rather, the problem will be their stuff > doesn't compile on Linux but the reverse will be true.) This is all rather paranoid. They gain nothing from any of this, whereas they could potentially gain much from cooperation. Admittedly, corporations will do whatever's in their own best interest, but you're really villainizing them here. Even if they did do what you say, it wouldn't make a difference. The Linux/*BSD people would continue using the free software version. It would be {Sun, SGI, whoever}'s loss. High quality free software can stand on its own merit against proprietary alternatives, and doesn't need to hide in a legal jungle to do it. For that matter, they could just pay a small group of programmers to do a proprietary, cleanroom implementation of the whole thing in a matter of a couple of months, regardless of whether or not it was (L)GPL'd. Big companies have lots of resources and can do stuff like that. Much nicer to not totally alienate them; they might even decide to come over and play, and put those vast resources to work for the forces of good. Yuck...apologies if I've offended anyone, I really didn't mean any of that to come out as harshly as it might be interpreted. These sorts of discussions always get people (like me) riled up. I'll refrain from making any further comment on any of this; licensing always turns into an emotional issue. :( Mike From ggi-develop-request@eskimo.com Sun Jun 7 23:50:01 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA30524; Sun, 7 Jun 1998 23:49:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id XAA09118; Sun, 7 Jun 1998 23:56:08 -0700 (PDT) Resent-Date: Sun, 7 Jun 1998 23:56:08 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806080652.IAA08310@cip8.e-technik.uni-erlangen.de> Subject: Re: Undisplayed screen parts and stuff To: ggi-develop@eskimo.com Date: Mon, 8 Jun 1998 08:52:40 +0200 (MESZ) In-Reply-To: from "Brian Julin" at Jun 7, 98 10:44:54 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"f3jZ-3.0.KE2.5iuUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2646 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > On Mon, 8 Jun 1998, W. Scholten wrote: > > This probably isn't very clear: what I'm getting at is that the display > > of the 320x200 area would be _as if_ it were part of a 320x240 area > > (i.e. with square pixels), but the mode would just be regular 320x200. > > Can this be done adjusting the chipset info on when to start writing to > > the screen etc. ? > > Under the current API, you're only solution would be to get a > 320x240 mode, wipe it black, and then only draw in a 320x240 > box. But this rules out virt.y > visible.y. > > libGGICRT (or whatever it ends up being named) will allow physical > size/position negotiation. > > -- > Brian S. Julin > > Not exactly. The mode struct has entries for the screen size. Although these are currently (AFAIK) unused, they could be used to specify at least the aspect ratio of the screen. So it would be possible to checkmode some 320x200 mode with 4:3 aspect ratio (or a 320x240 mode with 16:9 aspect ratio ...) although the currnet monitor driver would be unlikely to do what you want. So the API is there, the functionality not. If you think this is a critical issue, we could 1) either schedule it for libggiCRT 2) or document some method of using the screen size fields for setting and requesting the aspect ratio. There is no need for new functions. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 8 01:01:25 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA30619; Mon, 8 Jun 1998 01:01:23 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA16168; Mon, 8 Jun 1998 00:57:34 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 00:57:34 -0700 (PDT) X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Mon, 8 Jun 1998 09:54:47 +0200 (MET DST) From: Stefan Mars To: Linux-GGI Subject: Licensing (Andy, READ THIS)! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"8wWCP1.0.Ry3.hbvUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2648 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com For a while now the discussion about the licensing of different parts of GGI has been hitting the mailing lists, the IRC meeting and also some private mail :). I am beginning to think that it has reached the point where the question shouldn't be who the different licenses will alienate GGI from, but rather: are we about to alienate our own developers? It is indeed a question that has a lot of emotions involved in it, and most people doesn't seem willing to move from their position, because it affects so much of what they believe in. I know I am not willing to budge. But this also means that the discussion can go one forever and ever, and right now we need peace to code and get Degas together, and so I suggest that the core-team spends a while with the IRC log and the mailing list archives, and then _they_ decide the different licenses. The rest of us will just have to take that decission and live with it, or leave if we can't. But above all, we need peace, and we need to know what the future will be. Btw, I have for the purpose of this email defined the GGI core team as those who has write-acces to the stable repository as that reflects those who has been active a long time and also carries a large workload of the project. -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Mon Jun 8 01:02:05 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA30666; Mon, 8 Jun 1998 01:02:03 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA16459; Mon, 8 Jun 1998 00:58:47 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 00:58:47 -0700 (PDT) Sender: thomas@sun1.muenchen-land.baynet.de Message-ID: <357B97CE.EF6BA96F@gmx.de> Date: Mon, 08 Jun 1998 09:50:38 +0200 From: Thomas Tanner X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Duplicate mails? References: <357A51E0.F2D5D86F@gmx.de> <357A5C83.D5F4E2FF@stu.ac.cc.md.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Upp-Y3.0.014.pcvUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2649 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Chris Meadors wrote: > > BTW: Is there no mailing list archive for last month? > > Where were you looking for the archive? The one on the web site is there. > I thought I got the ftp one, but I could be wrong. The server is awful slow > right now, and I can bearly connect (seems a couple people are interested in > the CVS?), or I'd look before posting this. So if you could let me know > where you didn't find the archive I'll see if I can figure it out. I meant the one on the ftp site. It was not there when I tried it last time. Now it seems to be there but I don't have the access permissions for it? -- Thomas Tanner ----------------------------- email: tanner@gmx.de tanner@ggi-project.org web: http://home.pages.de/~tanner GGI: http://www.ggi-project.org From ggi-develop-request@eskimo.com Mon Jun 8 01:04:45 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA30678; Mon, 8 Jun 1998 01:04:43 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id AAA06859; Mon, 8 Jun 1998 00:52:17 -0700 Resent-Date: Mon, 8 Jun 1998 00:52:17 -0700 X-Authentication-Warning: arenda.lightspeed.net: wolfwings owned process doing -bs Date: Mon, 8 Jun 1998 00:56:21 -0700 (PDT) From: WolfWings ShadowFlight Sender: wolfwings@arenda.lightspeed.net To: Michael Funk cc: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Jj_BT3.0.3h1.mWvUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2647 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Michael Funk wrote: >The article was just a pointer to one of RMS' recent pronouncements >regarding BSDL, in which he actually made a pretty valid point about >it. For those who aren't familiar with it, BSDL consists of 3 things: > > (1) A copyright notice > (2) 4 conditions for modification and redistribution > (3) A disclaimer, denying legal liabilty ---[snip]--- >It's a silly clause, which >could be easily removed. Couldn't we make a custom GGI license, that does just that? I.E. Take the BSD license, and remove that one clause, and call it the GGI license? Or, as a simpler alternative, say that it uses the BSD license as a base, with that clause being removed? _ _ _|_ WolfWings ShadowFlight | | | | | | | | wolfwings@lightspeed.net | | | | | | | | "Love is a bird, |_|_| |_|_| | | She needs to fly... _ / Let all the hurt, \-.______,-' Inside of you die..." - Madonna, Frozen From ggi-develop-request@eskimo.com Mon Jun 8 01:32:56 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA30702; Mon, 8 Jun 1998 01:32:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA21678; Mon, 8 Jun 1998 01:28:10 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 01:28:10 -0700 (PDT) Date: Mon, 8 Jun 1998 04:25:32 +0000 (GMT) From: Michael Funk X-Sender: mwfunk@foo.bar.com Reply-To: mwfunk@uncc.campus.mci.net To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"2K5ou3.0.cI5.O2wUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2650 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 8 Jun 1998, WolfWings ShadowFlight wrote: > On Fri, 5 Jun 1998, Michael Funk wrote: > > >The article was just a pointer to one of RMS' recent pronouncements > >regarding BSDL, in which he actually made a pretty valid point about > >it. For those who aren't familiar with it, BSDL consists of 3 things: > > > > (1) A copyright notice > > (2) 4 conditions for modification and redistribution > > (3) A disclaimer, denying legal liabilty > > ---[snip]--- > > >It's a silly clause, which > >could be easily removed. > > Couldn't we make a custom GGI license, that does just that? I.E. Take the > BSD license, and remove that one clause, and call it the GGI license? Or, > as a simpler alternative, say that it uses the BSD license as a base, with > that clause being removed? That's actually what the FreeBSD people use (whenever possible), a stripped down version of BSDL. Just a copyright notice, the legal disclaimer, permission to modify and redistribute, and the first 2 conditions (must distribute license with source/must distribute license with bins). They generally ditch the advertising clause and the endorsement clause, which are kind of silly to begin with. Quite minimal, very classy. Mike From ggi-develop-request@eskimo.com Mon Jun 8 01:56:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA30715; Mon, 8 Jun 1998 01:56:49 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA23539; Mon, 8 Jun 1998 01:47:11 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 01:47:11 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806080841.KAA02022@sunserver1.rz.uni-duesseldorf.de> Subject: Re: LGPLed libggi NOT ok for BSD (Re: LGPLed LibGGI ok for commercial developers (Was: Re: KGI license?)) In-Reply-To: from Stefan Mars at "Jun 8, 98 06:04:28 am" To: ggi-develop@eskimo.com Date: Mon, 8 Jun 1998 10:41:00 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"xE2T31.0.gl5.DKwUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2651 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > I can take your code and sell it for a buck-load of money if you put it > > under GPL. In fact, I sell GPL'ed code for a living. I happen to be a > > As bort Peter and ixx has pointed out to me it is indeed you can indeed > sell GPL code. On the other hand, since they must give any changes to the > source back to the community, a person would simply download and compile > himself and avoid paying. You all know what I mean :) No. At least _one_ can be forced to pay. He can then give it away for free, but ... I do not see so much a point in commercial usage of a BSD style licensed thing. BSD contains a "give credits" clause which can be formulated in a way that it suffices giving credits in some accompanying documentation (not the silly "flash it over the screen" thing). Thus if a commercial vendor just takes your code and redistributes it, the give credits clause might point the user to the original sources which are free. If he adds a substantial new feature to the distribution, I think it is his right to charge for that. If he doesn't, only a fool will buy his product, if the free one is available. If the new feature is good, we can probably easily backport it ... At worst this needs reverse engineering which is legal in many states where our developers come from ... So I do not see GPL restricting us in any way ... CU, Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 8 02:08:18 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA30737; Mon, 8 Jun 1998 02:08:16 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA25765; Mon, 8 Jun 1998 02:01:31 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 02:01:31 -0700 (PDT) Date: Mon, 8 Jun 1998 10:58:24 +0200 (DFT) From: Massimiliano Ghilardi Reply-To: Massimiliano Ghilardi To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"AhuJ_.0.PI6.eXwUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2652 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 6 Jun 1998, Steve Cheng wrote: > On Sat, 6 Jun 1998, Michael Funk wrote: > > Just a word of warning: > > Public Domain is not a license. If you put something into public domain, > then you disown ALL copyrights on the code. Consequently, you cannot apply > any other licenses on your code since it is not copyrighted by you any more. This is getting a little off topic, but I have a few questions about PD: 1) can someone pick PD code from the net and re-use and distribute it in software with a different (non-PD) license? Naively, I'd say so as PD is usually regarded as "do whatever you wish with the code". But this also mean that the original author can re-license PD code with whatever license he wants... which would contradict your statement. Anyone has an answer? 2) I am not a lawyer too, but I know that the code I write is copyrighted by me even if it does not contain any copyright notice. So I imagine that if I have some code I wrote sitting on my HD, I can do whatever I want with it, even if I have distributed a modified (as I added a license) version of that code to the net. This just because receiving a licensed copy of a program is not the same as writing it: you do not have to license the code to yourself. Again, anyone can confirm/correct this? Max From ggi-develop-request@eskimo.com Mon Jun 8 02:09:07 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA30745; Mon, 8 Jun 1998 02:09:04 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA26880; Mon, 8 Jun 1998 02:05:43 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 02:05:43 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806080903.LAA10715@cip8.e-technik.uni-erlangen.de> Subject: Re: KGI license? To: andreas.beck@ggi-project.org Date: Mon, 8 Jun 1998 11:03:15 +0200 (MESZ) Cc: ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jun 5, 98 07:16:28 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"n1f2n.0.tZ6.abwUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2653 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andy wrote: > > > > [ Licensing ] > > This is -really- something that needs to get cleared up ASAP before more > > cooks enter the picture. May I suggest that during the IRC session, the > > developers hammer out something regarding a licensing scheme that pleases > > everyone in the core development team? > > O.K. - Can we all agree on the following : > > 1. All parts of GGI, that are to be patched into, linked to, or somehow > otherwise incorporated into another piece of software should use the > licensing policy of the appropriate piece of software, or a compatible > one which is likely to be accepted by the authors of the modified > software. > > This means GPL for Linux kernel patches, new files and such, > BSD for BSD-patches etc., evteually commercial licenses on SUNOS patches > or something like this. First. I think we need ONE LICENSING DOCUMENT. I have no idea yet how it could look like, but we need exactly one document, for one reason. Each and every contributor to this project must KNOW EXACTLY what the terms of distribution are, and must adhere to it. Each and every file must have the same /* (c) 199x Erika Mustermann */ /* for copyright and licensing information see BASEDIR/doc/GGILICENSE */ at the top. It can't be that different files in one package have different licensing schemes. One tarball, one license. How this one license can have 'this is GPL on GPL systems, BSDish on *BSD, LGPL if it's (part of) a library' (or what finally is decided on), I don't know. But if we only have email flamewars about this issue, no contributor knows exactly what will happen to his contribution. That can't be. So we need one license document, and this one GGI license must apply to all our releases. > > 2. All parts, for which there seems no technical reason for not doing so, > we should use BSD licensing in the version that says "give credits in the > program _or_ accompanying documentation", to avoid that "having to flush > messages over the screen" problem. > > 3. I'd like some parts, especially "stub" drivers and example code to be > really "freeware". I.e. "do with that as you wish". That sounds fine with me. > > I'd really like to move over to *BSD style licensing, because it gives me much > less headaches regarding commercial drivers/apps/... > > I do not think that we will gain more drivers using GPL, so I think BSD > licensing should do a better job. It still protects our intellectual > property by requesting credit (see Eric S. Raymond, "Homesteading in the > noosphere"), while getting us best possible driver support. > > CU, Andy I don't fear that some vendor (e.g. Sun, SCO) starts bundling libggi in their base OS distribution. I don't fear that some HW vendor starts writing KGI drivers for 3D cards, including libggi3d vendor-libs and not releases the source code. To me, and that is surely MHO only, this is absolutely OK. What I would fear is that someone starts forking an incmpatible API, like Microsoft tried with Java. Sun and their fan club were big and determined enough to stop that (AFAIK), we wouldn't. We work in the nowhere land between GPLed (Linux), BSDish (*BSD), XFree, and commercial software (Glide, SCO, Solaris, BeOS, Win*), and I don't think any existing license can cover our problems here. I would like to start with collecting individual 'claims' we have to cover in our license. From the top of my head: 1) No guarantee for anything, it might even fry your monitor. 2) If you distribute this software , you have to include this license and the CONTRIBUTORS file (e.g.) 3) If you want to use this software without modification, i.e. link it to your application (statically or dynamically), either (at your discretion) provide source code (open source in the esr sense) or (2) applies: give credit. 4) If you write a driver (including vendor-libs) for this system: see (3): source code or give credit. 5) If you change/enhance the base functionality, you have to provide full source code under this license ('SW derived from free SW must stay free' in the GPL sense). IMHO 3-5 cover all uses one can have with our software (porting to a different OS is included in (4)). What other things have to be covered by our license? Bottom line: - we need ONE license that all our software is distributed under. - I doubt we'll find an existing license that works. - we must start collecting the points we want to cover with the license. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 8 02:21:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA30765; Mon, 8 Jun 1998 02:21:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA28800; Mon, 8 Jun 1998 02:18:28 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 02:18:28 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806080910.LAA10824@cip8.e-technik.uni-erlangen.de> Subject: Re: MGA Impression Chipsets. To: ggi-develop@eskimo.com Date: Mon, 8 Jun 1998 11:10:54 +0200 (MESZ) In-Reply-To: from "wlfshmn@ramses.ml.org" at Jun 5, 98 09:55:40 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FMntE3.0.q17.WnwUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2654 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Greetings, > > IS-ATLAS chipset, wich is quite a bit like the Mystique and The Milleniums > (And so are the IS-HELENA, IS-TITAN and IS-DUBIC I guess) so I just want > to make sure none of you are already writing a driver for this card. If > not, I would like a chance at writing such a thing. > > Johan Karlberg, No longer studying, unemployed and generally with too much > spare time. > > AFAIK from Matrox only Millennium I/II/AGP and Mytique are in the works. Is documentation for other chipsets available? Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 8 02:49:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA30795; Mon, 8 Jun 1998 02:49:51 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA01371; Mon, 8 Jun 1998 02:36:42 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 02:36:42 -0700 (PDT) From: wlfshmn@ramses.ml.org Date: Mon, 8 Jun 1998 11:34:39 +0200 (CEST) To: ggi-develop@eskimo.com Subject: Re: MGA Impression Chipsets. In-Reply-To: <199806080910.LAA10824@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"JuC4_.0.HL.d2xUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2655 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 8 Jun 1998, Hartmut Niemann wrote: > > > > Greetings, > > > > IS-ATLAS chipset, wich is quite a bit like the Mystique and The Milleniums > > (And so are the IS-HELENA, IS-TITAN and IS-DUBIC I guess) so I just want > > to make sure none of you are already writing a driver for this card. If > > not, I would like a chance at writing such a thing. > > > > Johan Karlberg, No longer studying, unemployed and generally with too much > > spare time. > > > > > AFAIK from Matrox only Millennium I/II/AGP and Mytique are in the works. > > Is documentation for other chipsets available? > > Hartmut. This is a matter of definition, I have yet to aquire any kind of assitance from Matrox proper, I do have enough information on the IS-ATLAS to write working drivers, although not optimally accelerated and I have hopes that with such a driver in hand, It will show Matrox that they loose nothing from releasing the full specs. Abou the other cards, I have only about 40 lines of documentation (A diff more or less to the basic MGA engine) for the IS-DUBIC but I have no hardware to test this on, I plan on aquiring a few cheap Matrox boards after I get the IS-ATLAS driver to work properly. Luckily whith the MGA chipsets, they are all base on the same core. So alot of what has been written for the Mystique and milleniums, will also work on the older chipsets. Johan Karlberg > > -- > Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de > http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] > From ggi-develop-request@eskimo.com Mon Jun 8 03:31:11 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA30837; Mon, 8 Jun 1998 03:31:09 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id DAA11475; Mon, 8 Jun 1998 03:21:02 -0700 Resent-Date: Mon, 8 Jun 1998 03:21:02 -0700 Message-ID: <19980608121849.A139@crap.casema.net> Date: Mon, 8 Jun 1998 12:18:49 -0400 From: "smoke van c.r.a.p" To: ggi-develop@eskimo.com Subject: license me stupid Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Resent-Message-ID: <"dcjtw.0.Bp2.EixUr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2656 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com okay, i don't want to start a huge flame-war here, so please reply at smoke@casema.net, and NOT to the ggi-list: Why is it that some hardware-vendors don't want to give the specs to their video-cards ? Why is it they don't want to give out source-code to video drivers ? Would it be commercially `better' for them to keep these things secret ? I myself think not. It's that these companies have been used to a Microsoft policy of keeping bad things hidden from the eye of the public. I think this is fundamentally `stupid'. If not, please do not read on and email me why. Given it's really stupid, why not show these companies there are other ways ? I think there are enough vendors that DO give out specs, and given the support from X, Svgalib and perhaps the binary drivers in WinXX - ggi will draw enough attention to make these companies think again. I get this funny feeling that I'm completely stupid. I know there are a lot of companies in this just for the money, but why not boycott these ? At this moment most people don't know a thing about the politics involved in the computer business. Why not just let these people know they've done a bad thing when buying `closed hardware' ? The only thing I can imagine is that the core development team of GGI is very very sweet and wants everyone to be happy. This is why I didn't really want to flame someone - it's just that I feel so wrong about these companies. I haven't done any real code for the GGI project myself, but I sure am using it. And I want my program to be completely free. Do I have to be scared that hardware vendors keep on hiding their sources ? People all over the world will complain the program I wrote is buggy, just because their video-driver isn't up to date, and no one can do anything about it. How many times do I have to hear that someone's pc is broken or some very good written software is bad, just because it runs on buggy drivers ? (Can i call win95 a driver?) A lot of questions, I don't want to influence the core team here. You people are doing a great job, and you'll have to decide what to do with it. I just didn't know where else to ask. Thanks in advance, smoke/crap reply to smoke@casema.net From ggi-develop-request@eskimo.com Mon Jun 8 03:43:56 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA30851; Mon, 8 Jun 1998 03:43:54 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA08950; Mon, 8 Jun 1998 03:40:14 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 03:40:14 -0700 (PDT) From: wlfshmn@ramses.ml.org Date: Mon, 8 Jun 1998 12:38:17 +0200 (CEST) To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"uSQrh.0.kB2.C-xUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2657 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 8 Jun 1998, WolfWings ShadowFlight wrote: > On Fri, 5 Jun 1998, Michael Funk wrote: > > >The article was just a pointer to one of RMS' recent pronouncements > >regarding BSDL, in which he actually made a pretty valid point about > >it. For those who aren't familiar with it, BSDL consists of 3 things: > > > > (1) A copyright notice > > (2) 4 conditions for modification and redistribution > > (3) A disclaimer, denying legal liabilty > > ---[snip]--- > > >It's a silly clause, which > >could be easily removed. > > Couldn't we make a custom GGI license, that does just that? I.E. Take the > BSD license, and remove that one clause, and call it the GGI license? Or, > as a simpler alternative, say that it uses the BSD license as a base, with > that clause being removed? > _ My question would be, to what extent are we allow to modify existing licenses, after all, even the Licenses themselves are copyrighted I suppose. Johan Karlberg From ggi-develop-request@eskimo.com Mon Jun 8 04:30:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA30878; Mon, 8 Jun 1998 04:30:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA13483; Mon, 8 Jun 1998 04:18:29 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 04:18:29 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806081116.NAA13990@cip8.e-technik.uni-erlangen.de> Subject: Re: LGPLed libggi NOT ok for BSD (Re: LGPLed LibGGI ok for commercial To: ggi-develop@eskimo.com Date: Mon, 8 Jun 1998 13:16:07 +0200 (MESZ) Cc: becka@sunserver1.rz.uni-duesseldorf.de (Andreas Beck) In-Reply-To: <199806080841.KAA02022@sunserver1.rz.uni-duesseldorf.de> from "becka@rz.uni-duesseldorf.de" at Jun 8, 98 10:41:00 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"XA80R1.0.NI3.0YyUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2658 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > > > I can take your code and sell it for a buck-load of money if you put it > > > under GPL. In fact, I sell GPL'ed code for a living. I happen to be a > > > > As bort Peter and ixx has pointed out to me it is indeed you can indeed > > sell GPL code. On the other hand, since they must give any changes to the > > source back to the community, a person would simply download and compile > > himself and avoid paying. You all know what I mean :) > > No. At least _one_ can be forced to pay. He can then give it away for free, > but ... > > I do not see so much a point in commercial usage of a BSD style licensed > thing. > > BSD contains a "give credits" clause which can be formulated in a way that > it suffices giving credits in some accompanying documentation (not the > silly "flash it over the screen" thing). > > Thus if a commercial vendor just takes your code and redistributes it, the > give credits clause might point the user to the original sources which > are free. > > If he adds a substantial new feature to the distribution, I think it is his > right to charge for that. If he doesn't, only a fool will buy his product, > if the free one is available. > > If the new feature is good, we can probably easily backport it ... > > At worst this needs reverse engineering which is legal in many states where > our developers come from ... > > So I do not see GPL restricting us in any way ... > > CU, Andy Andy, just to make sure: Du you mean GPL or BSD in this sentence? I am unsure whether I misunderstand your mail or you made a typo. Please clarify. > > -- > Andreas Beck | Email : > > -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 8 05:09:12 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA30908; Mon, 8 Jun 1998 05:09:11 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA20502; Mon, 8 Jun 1998 04:59:44 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 04:59:44 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806081154.NAA10783@sunserver1.rz.uni-duesseldorf.de> Subject: raypos and such ... To: ggi-develop@eskimo.com (mailing list GGI) Date: Mon, 8 Jun 1998 13:54:34 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Z4Y3G3.0.D05.i8zUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2660 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Sorry - my ISP had severe problems ... Subject: CRT things (*raypos, mode tweaking) -> extension ? Date: Sun, 7 Jun 1998 12:41:18 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org Hi folks ! As some aspects in the current API and some proposed additions - namely the *raypos functions and functions to tweak monitor setup - are rather CRT- centric and thus not available on all targets, and they are unneeded for most applications, I'd suggest to move them out of the standard API into an extension. The new extension scheme should easily support this, as the extension can now query the backend it is running on and thus load backend-specific code. I see three advantages in this : 1. The LibGGI API itself gets a bit more straightforward and less VGA/CRT centric, 2. while we still have the functionality around easily, if it is needed. 3. We can use that extension for more things that shouldn't go into basic LibGGI like requesting other refresh rates, using VESA DPMS etc. Plus it would make a nice checkpoint for the new extension scheme :-). CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 8 05:14:26 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA30913; Mon, 8 Jun 1998 05:14:25 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA19362; Mon, 8 Jun 1998 04:53:10 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 04:53:10 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806081150.NAA10675@sunserver1.rz.uni-duesseldorf.de> Subject: Re: KGI license To: ggi-develop@eskimo.com Date: Mon, 8 Jun 1998 13:50:11 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"5X7Mv1.0.Ok4.a2zUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2659 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > No. At least _one_ can be forced to pay. He can then give it away for free, > > but ... > > > > I do not see so much a point in commercial usage of a BSD style licensed > > thing. > > > > BSD contains a "give credits" clause which can be formulated in a way that > > it suffices giving credits in some accompanying documentation (not the > > silly "flash it over the screen" thing). > > > > Thus if a commercial vendor just takes your code and redistributes it, the > > give credits clause might point the user to the original sources which > > are free. > > > > If he adds a substantial new feature to the distribution, I think it is his > > right to charge for that. If he doesn't, only a fool will buy his product, > > if the free one is available. > > > > If the new feature is good, we can probably easily backport it ... > > > > At worst this needs reverse engineering which is legal in many states where > > our developers come from ... > > - - So I do not see GPL restricting us in any way ... Sorry. Typo. + + So I do not see BSD licensing restricting us in any way ... Thanks, Hartmut for pointing it out. CU,Andy P.S.: You might have noticed that I want a license, that allows KGI drivers to run on _every_ system. Any licensing scheme that will inhibit using KGI drivers on any system will lock me out of the project. -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 8 05:24:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA30921; Mon, 8 Jun 1998 05:24:41 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA23617; Mon, 8 Jun 1998 05:24:18 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 05:24:18 -0700 (PDT) From: Andrew Apted Message-ID: <19980608221917.64550@ajax.netspace.net.au> Date: Mon, 8 Jun 1998 22:19:17 +1000 To: ggi-develop@eskimo.com Subject: display-fbdev just committed Reply-To: ggi-develop@eskimo.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 Resent-Message-ID: <"cbBei.0.vm5.mVzUr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2661 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi folks, I have just committed the display-fbdev target to the development repository / playpen :-). This should be usable right now in conjunction with the VGER kernel and the VESAFB framebuffer driver. If anyone wants to try this out, just say so and I'll go into more detail. I also committed a display-monotext target. This is an AAlib-like thingy that emulates an GT_8BIT mode on the textmode of another target. For example, I've been playing DUMB with it on my MDA card using display-fbdev. Lastly, I've added some code to libggi/scripts/configure to parse the .config file. Thus doing a "make config" no longer forgets the previous configuration. Could one of the shell-script gurus please take a lot and check that a) it is nice and portable, and b) I haven't done something stupid and/or broken something ? Thanks ! Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Mon Jun 8 06:10:28 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA30956; Mon, 8 Jun 1998 06:10:26 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA29765; Mon, 8 Jun 1998 05:55:43 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 05:55:43 -0700 (PDT) Date: Mon, 8 Jun 1998 08:53:20 -0400 (EDT) From: James A Simmons To: e94_msu@e.kth.se cc: ggi-develop@eskimo.com Subject: Re: libggi: Alpha values In-Reply-To: <3577C9DC.95CACDE2@ebc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"GWajb2.0.vG7.8zzUr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2662 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Marcus Sundberg wrote: > Hartmut Niemann wrote: > > > > Hi! > > > There was the suggestion to enhance ggi_color, which currently holds > > > three shorts for r,g, and b, with an additional alpha value > > > (transparency). Chris Meadors asked this recently again. > > > > The discussion seems not to be whether or not to support alpha > > values, but where and how. > > Some people argued that it would be necessary to change ggi_color, > > some others support moving a ggi_rgba_color and alpha-aware > > drawing functions to some libggi2d. > > > > My concern is that having (software) Alpha support in each and every > > graphics routine will slow that down. > > Most applications won't need Alpha support, like graphical > > desktops or CAD. > > I would like not to include alpha support in our base library. > > > > The discussion is open, the decision won't be made in Erlangen anyway ... > > Of course the base libggi routines should not use Alpha values! > But I don't see how that prevents us from adding a "short alpha" > to the ggi_color struct. Then we have all options open to add > alpha support where needed. (And we also end up with a properly > aligned struct...) > > //Marcus > For a KGI based libggi I like to suggest that we seperate ioctl.h from the library. Here is what I sugguest. That in ioctl.h we have a special ggi_mode like structure. This will enable any API to be able to be built on top of KGI. So this special ggi_mode in ioctl.h could accept from say libggi3D a ggi3d_mode that would ask to use the alpha component. In libggi it would be just a matter of type casting ggi_mode to this new mode structure. From ggi-develop-request@eskimo.com Mon Jun 8 07:20:26 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA31034; Mon, 8 Jun 1998 07:20:23 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA12360; Mon, 8 Jun 1998 07:14:39 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 07:14:39 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806081412.QAA18730@cip8.e-technik.uni-erlangen.de> Subject: Re: raypos and such ... To: ggi-develop@eskimo.com Date: Mon, 8 Jun 1998 16:12:04 +0200 (MESZ) In-Reply-To: <199806081154.NAA10783@sunserver1.rz.uni-duesseldorf.de> from "becka@rz.uni-duesseldorf.de" at Jun 8, 98 01:54:34 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"xXaTf3.0.013.D7_Ur"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2663 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andy, you mentioned setSplitline as one other candidate for this extension scheme. Can we agree on removing splitline and *raypos from libggi about two days after the first draft libggicrt with a working vga splitline is in the 'stable' repository and the splitline part of the ggi demo is confirmed to work with it? Just not that it falls into some black gouraud-shaded triangle like ggi-circle did ... Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 8 08:00:05 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA31065; Mon, 8 Jun 1998 07:59:53 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA27796; Mon, 8 Jun 1998 07:45:54 -0700 Resent-Date: Mon, 8 Jun 1998 07:45:54 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <357BF918.F9A256AC@e.kth.se> Date: Mon, 08 Jun 1998 16:45:44 +0200 From: Marcus Sundberg Reply-To: e94_msu@e.kth.se X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: IRC summary (part one) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KEO9-3.0.0o6.Xa_Ur"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2664 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! Sorry I couln't attend the IRC meeting, I'll try to be there next sunday. > ggiFlush() simple clipping to enhance targets having to emulate a DirectBuffer > ============================================================================== > > Have "some kind of clipping list which is initialized to the full display, > and reinitialized to that after a ggiFlush() .. and modified by a new > call. This way, old applications will still update the full framebuffer, > while applications aware of the new call can restrict changes.." If we're going to have this it must be clearly documented that it is NOT guarenteed that only the clipped area is flushed. Ie. the target may flush the entire display if it so desires. If anyone objects to this - imagine the following: An app depends on only the clipped region being flushed. This app is running on a KGI target without HW clipping. The app issues a bunch of libggi primitive commands that causes acceleration commands to be placed in the accel queue. Now the app changes the clipping list and calls ggiFlush(), and as there's no HW clipping the entire accel queue will have to be thrown away and filled again. And in order to do this the target must save every libggi call mad since the last ggiFLush()... //Marcus From ggi-develop-request@eskimo.com Mon Jun 8 08:54:44 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA31103; Mon, 8 Jun 1998 08:54:36 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA04200; Mon, 8 Jun 1998 08:40:33 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 08:40:33 -0700 (PDT) Message-Id: <199806081540.RAA17410@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 08 Jun 1998 17:35:13 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: CVS login problem and solution Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"cPgFm.0.S11.jN0Vr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2665 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello all, You can call me a freaking idiot - last night, I moved the ggi-project.org zone to a new primary DNS: degas.ggi-project.org Unfortunately the zone on the new machine was copied before I changed the record for "cvs" and it still pointed to the old machine (Steffen's, in germany). So basically if your DNS updated, you are now talking to the old machine and it will refuse your login. I have corrected it, but it might take up to a day to propagate properly. In the meantime, you can use "degas.ggi-project.org" instead of "cvs.ggi-project.org" .. Sorry ! -- Emmanuel PS: When I sent this the first time, I've been told that I wasn't subscribed to the list !!? It probably means I missed all traffic today. I'll look up the archives, but if you had any question directed to me, please send PM .. From ggi-develop-request@eskimo.com Mon Jun 8 09:11:13 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA31120; Mon, 8 Jun 1998 09:11:04 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA02611; Mon, 8 Jun 1998 08:56:35 -0700 Resent-Date: Mon, 8 Jun 1998 08:56:35 -0700 To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: kgi/lib/libggi and kgi/driver interdependencies Date: 8 Jun 1998 15:04:55 GMT Organization: OnTV Pittsburgh, L.P. Lines: 48 Sender: Jason McMullan Distribution: local Message-ID: <6lguin$8tv$1@butter.visus.com> References: <6lfima$nlf$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"H9d3H3.0.ge.oc0Vr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2666 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Brian Julin wrote with confidence: > Q. I assume there is no problem in having kgi/driver/chipset// > need kgi/lib/libggi// (and visa versa) to compile? More to the > point, I'd like to link objects compiled in lib/libggi/WD/text16/ with > -D__KERNEL__ into the driver module as part of my scroller. Is this > cool or should we still have separate text16 stuff kept in > kgi/driver/chipset/? Good question.... I would say keep it separate for now, but let's look at how difficult it would be to combine the code. There may be some hairy issues with respect to use of libc in the lib code (which is perfectly legal), -fPIC problems, etc. Geert U. has given his blessing for the use of fbcon in the GGI project, so I'm going to start writing a textop management system, and write wrappers for his text framebuffer code ie: ... set_mode ... /* Set up struct kgi_mode.. */ mode.textop=kgi_textop_acquire("iplane16-amiga"); /* kgi_textop_acquire will see if iplane16-amiga is already * loaded, and if not do a modprobe() on "textop-iplane16-amiga" * then it returns a pointer to the textop struct that * that module registered */ ... ... free_mode ... /* Release memory and stuff */ kgi_textop_release(mode.textop); -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Mon Jun 8 09:24:34 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA31131; Mon, 8 Jun 1998 09:24:31 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA04860; Mon, 8 Jun 1998 09:01:16 -0700 Resent-Date: Mon, 8 Jun 1998 09:01:16 -0700 Sender: duff@eskimo.com Message-ID: <357C0AB1.D81829ED@cip.informatik.uni-erlangen.de> Date: Mon, 08 Jun 1998 18:00:49 +0200 From: Andreas Vogler X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.100 i586) MIME-Version: 1.0 To: GGI Subject: SVGAlib target Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ka5Ow1.0.mB1.Ah0Vr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2667 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi, I just tested the lastest devel sources of LibGGI and I have run into a problem with the SVGAlib target. There are some references to MOUSE_*BUTTON and some of them seem to be undefined. Where should they be defined, do I have to update some files? Any idea? Andreas -- / \ "All that we see or seem \ / / \ is but a dream within a dream" E.A. Poe \ / From ggi-develop-request@eskimo.com Mon Jun 8 09:28:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA31138; Mon, 8 Jun 1998 09:28:42 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA13964; Mon, 8 Jun 1998 09:19:45 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 09:19:45 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <357B5F14.77B27350@cistron.nl> Date: Mon, 08 Jun 1998 05:48:36 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: IRC summary (part one) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"eSj1w2.0.vP3.Ry0Vr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2668 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Steve Cheng wrote: > However, if more information is needed (e.g. why solution (B) was not > adopted, etc.), please read the full log relevent to your topic. Especially > I will not repeat the two licensing wars here :-) Damn. I missed the IRC session again through various circumstances. I could have tested my asbestos suit in the license war (with flame throwers, right?) :) > Switch-away/Switch-back Behavior > ================================ > > Question: "What has to be done when a program is switched away (either the > window (in X) becomes inactive, or the VT is switched), and on > re-activation?" > > No protocol implementing any of this behaviour has been decided. Possible > solutions: > > "A callback mechanism (Extensions already have it) that handles this." > Or the program can specify behaviour to library. > > Current KGI implementation: "On switch-away (loss of input focus) a libGGI > app gets SIGTSTP. On regain of focus, libGGI app gets SIGCONT. If the app > has to redraw, gets SIGWINCH" > > (Iconification and focus change of windowed targets are other similar > situations but no specific protocol has been decided.) What about events like in X? Then you don't need to mess with signal handlers (SIGWINCH) and you can simply use select on the ggi input if the program should not continue running in the bg. Wouter From ggi-develop-request@eskimo.com Mon Jun 8 09:38:57 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA31167; Mon, 8 Jun 1998 09:38:51 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA16822; Mon, 8 Jun 1998 09:31:54 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 09:31:54 -0700 (PDT) From: Andrew Apted Message-ID: <19980609020806.29099@ajax.netspace.net.au> Date: Tue, 9 Jun 1998 02:08:06 +1000 To: ggi-develop@eskimo.com Subject: Re: IRC summary (part one) Reply-To: ggi-develop@eskimo.com References: <357BF918.F9A256AC@e.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <357BF918.F9A256AC@e.kth.se>; from Marcus Sundberg on Mon, Jun 08, 1998 at 04:45:44PM +0200 Resent-Message-ID: <"7e-CR.0.j64.t71Vr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2670 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Marcus writes: > > Have "some kind of clipping list which is initialized to the full display, > > and reinitialized to that after a ggiFlush() .. and modified by a new > > call. This way, old applications will still update the full framebuffer, > > while applications aware of the new call can restrict changes.." > > If we're going to have this it must be clearly documented that it > is NOT guarenteed that only the clipped area is flushed. Ie. the > target may flush the entire display if it so desires. Yep. > If anyone objects to this - imagine the following: > An app depends on only the clipped region being flushed. > This app is running on a KGI target without HW clipping. > The app issues a bunch of libggi primitive commands that causes > acceleration commands to be placed in the accel queue. > > Now the app changes the clipping list and calls ggiFlush(), and > as there's no HW clipping the entire accel queue will have to > be thrown away and filled again. No. Changing the clipping region implies a flush of everything outside the new region which hasn't been flushed yet. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Mon Jun 8 09:39:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA31172; Mon, 8 Jun 1998 09:39:30 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA15912; Mon, 8 Jun 1998 09:27:53 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 09:27:53 -0700 (PDT) From: Andrew Apted Message-ID: <19980609022249.44443@ajax.netspace.net.au> Date: Tue, 9 Jun 1998 02:22:49 +1000 To: ggi-develop@eskimo.com Subject: Re: SVGAlib target Reply-To: ggi-develop@eskimo.com References: <357C0AB1.D81829ED@cip.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <357C0AB1.D81829ED@cip.informatik.uni-erlangen.de>; from Andreas Vogler on Mon, Jun 08, 1998 at 06:00:49PM +0200 Resent-Message-ID: <"DvqNG1.0.Tu3.441Vr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2669 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andreas Vogler writes: > I just tested the lastest devel sources of LibGGI and I have run into a > problem with the SVGAlib target. > > There are some references to MOUSE_*BUTTON and some of them seem to be > undefined. Where should they be defined, do I have to update some files? > Any idea? Ahh, you're talking MOUSE_FOURTHBUTTON, MOUSE_RESETBUTTON etc..., right ? Those defines don't exist in my version of SVGAlib either... maybe in a later version ? I'd say just comment out that section of event.c and try again. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Mon Jun 8 10:50:17 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA31260; Mon, 8 Jun 1998 10:50:10 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA24038; Mon, 8 Jun 1998 10:36:45 -0700 Resent-Date: Mon, 8 Jun 1998 10:36:45 -0700 Date: Mon, 8 Jun 1998 19:34:39 +0200 (MEST) To: ggi-develop@eskimo.com Subject: Extensions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: 08142597465-0001@t-online.de From: Uwe_Maurer@t-online.de (Uwe Maurer) Resent-Message-ID: <"eBKWz3.0.Tt5.j42Vr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2671 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! How can I get the pointer to the private data of the extension without using the VIS_EXT macro? (VIS_EXT is defined in "internal.h") Uwe From ggi-develop-request@eskimo.com Mon Jun 8 12:05:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31396; Mon, 8 Jun 1998 12:05:29 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA18280; Mon, 8 Jun 1998 11:59:07 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 11:59:07 -0700 (PDT) Message-Id: <199806081841.UAA30955@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: Extensions In-reply-to: Your message of "Mon, 08 Jun 1998 19:34:39 +0200." Date: Mon, 08 Jun 1998 20:41:19 +0200 From: Marcus Sundberg Resent-Message-ID: <"vbTLH3.0.UT4.sH3Vr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2672 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > How can I get the pointer to the private data > of the extension without using the VIS_EXT macro? Why would you want to do that. The macros _should_ be used. //Marcus From ggi-develop-request@eskimo.com Mon Jun 8 12:06:18 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31404; Mon, 8 Jun 1998 12:06:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA18323; Mon, 8 Jun 1998 11:59:19 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 11:59:19 -0700 (PDT) Message-Id: <199806081839.UAA00449@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: SVGAlib target In-reply-to: Your message of "Tue, 09 Jun 1998 02:22:49 +1000." <19980609022249.44443@ajax.netspace.net.au> Date: Mon, 08 Jun 1998 20:39:40 +0200 From: Marcus Sundberg Resent-Message-ID: <"Y0haV2.0.6U4._H3Vr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2673 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > I just tested the lastest devel sources of LibGGI and I have run into a > > problem with the SVGAlib target. > > > > There are some references to MOUSE_*BUTTON and some of them seem to be > > undefined. Where should they be defined, do I have to update some files? > > Any idea? > > Ahh, you're talking MOUSE_FOURTHBUTTON, MOUSE_RESETBUTTON etc..., right ? > > Those defines don't exist in my version of SVGAlib either... maybe in a > later version ? I'd say just comment out that section of event.c and > try again. Yes, those were introduced in some 1.2.x version where x > 10. Guess I'll get to do my first commit to the new CVS repository tonight. ;-) //Marcus From ggi-develop-request@eskimo.com Mon Jun 8 13:19:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA31454; Mon, 8 Jun 1998 13:18:56 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA02147; Mon, 8 Jun 1998 13:11:20 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 13:11:20 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Licensing (Andy, READ THIS)! To: ggi-develop@eskimo.com Date: Mon, 8 Jun 1998 19:41:50 +0200 (MET DST) In-Reply-To: from "Stefan Mars" at Jun 8, 98 09:54:47 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"13Rqu2.0.PX.YL4Vr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2675 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all ! > For a while now the discussion about the licensing of different parts of > GGI has been hitting the mailing lists, the IRC meeting and also some > private mail :). I am beginning to think that it has reached the point > where the question shouldn't be who the different licenses will alienate > GGI from, but rather: are we about to alienate our own developers? Yes. This is the problem. We have to solve that _now_. > It is indeed a question that has a lot of emotions involved in it, and > most people doesn't seem willing to move from their position, because it > affects so much of what they believe in. I know I am not willing to > budge. Yeah. This is a really big problem. It is an almost religious issue. > But this also means that the discussion can go one forever and ever, and > right now we need peace to code and get Degas together, and so I suggest > that the core-team spends a while with the IRC log and the mailing list > archives, and then _they_ decide the different licenses. The rest of us > will just have to take that decission and live with it, or leave if we > can't. But above all, we need peace, and we need to know what the future > will be. Exactly. O.K. - I will make a list of yes/no questions (and please stick to only yes and no - I will ignore comments anyway), so I get an overview, what the majority wants. Please send me replies in PM - I will collect the data until next weekend and try to derive a reasonable licensing policy from it. A. PD parts: A1. Should there be parts, that are marked as public domain (like stubs for creating new drivers and such) ? A2. Should more than just "sample code" be PD ? B. Giving credits: B1. Should redistribution of any GGI code (except such explicitly marked PD) require giving credits to the original authors ? B2. Should "give credits" mean "display them on screen" ? B3. Would it be enough to require to redistribute the text of the license and a list of contributors ? C. Source availability: C1. Should the license force redistribution of source for any modification you make to any part of GGI ? C2. Should certain parts of LibGGI use GPL ? Which [ ] LibGGI [ ] Extensions [ ] KGI drivers [ ] Linux KGI->OS-interface C3. Should we enforce having to give a pointer to the free source the work was derived from ? D. Linking: D1. Should programs that are dynamically linked to some part of GGI have any restrictions applied ? Which ? [ ] give credits [ ] release source D2. Should programs that are dynamically linked to some part of GGI have any restrictions applied ? Which ? [ ] give credits [ ] release source [ ] allow relinking D3. Should static linking be considered "redistribution" ? E. Availability/Cross platform things: E1. Do you want KGI drivers to be useable on any platform ? E2. Shall we allow KGI drivers which are under a license that disallows their use on some platforms due to license incompatibilities ? E3. As linking non-GPL code with GPL code is said to be impossible, would you accept Linux not being able to incorporate KGI drivers in the kernel itself (module will be o.k.) ? Hope I got most of the relevant points. Send me suggestions/updates and most importantly your answers. I might add a second part to this questionaire, if it turns out I missed too much. CU, ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 8 13:19:59 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA31456; Mon, 8 Jun 1998 13:19:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA02168; Mon, 8 Jun 1998 13:11:26 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 13:11:26 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: SVGAlib target To: ggi-develop@eskimo.com Date: Mon, 8 Jun 1998 19:44:15 +0200 (MET DST) In-Reply-To: <357C0AB1.D81829ED@cip.informatik.uni-erlangen.de> from "Andreas Vogler" at Jun 8, 98 06:00:49 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"o-bCo1.0.mX.fL4Vr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2676 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I just tested the lastest devel sources of LibGGI and I have run into a > problem with the SVGAlib target. > > There are some references to MOUSE_*BUTTON and some of them seem to be > undefined. Where should they be defined, do I have to update some files? > Any idea? I have the same problem here. Probably got ot update SVGAlib. Maybe someone could look into autodetecting that case and falling back ? AFAIS it's only a couple of mouse button #defines and such ... CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 8 13:53:31 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA31507; Mon, 8 Jun 1998 13:53:26 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA23618; Mon, 8 Jun 1998 13:49:01 -0700 Resent-Date: Mon, 8 Jun 1998 13:49:01 -0700 Date: Mon, 8 Jun 1998 16:48:34 -0400 (EDT) From: Steve Cheng Sender: steve@maxt8m26.ipoline.com To: ggi-develop@eskimo.com Subject: Re: SVGAlib target In-Reply-To: <199806081839.UAA00449@zafir.e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"UNkWm.0.vm5.yu4Vr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2677 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 8 Jun 1998, Marcus Sundberg wrote: > > Those defines don't exist in my version of SVGAlib either... maybe in a > > later version ? I'd say just comment out that section of event.c and > > try again. > > Yes, those were introduced in some 1.2.x version where x > 10. > Guess I'll get to do my first commit to the new CVS repository > tonight. ;-) Ah ok. Just #ifdef MOUSE_FOURTHBUTTON /* code here */ #endif // Steve e-mail: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Mon Jun 8 14:08:28 1998 Return-Path: Received: from mx2.eskimo.com (root@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA31589; Mon, 8 Jun 1998 14:08:18 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA02114; Mon, 8 Jun 1998 13:11:10 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 13:11:10 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: KGI license? To: ggi-develop@eskimo.com Date: Mon, 8 Jun 1998 19:17:59 +0200 (MET DST) In-Reply-To: <199806080903.LAA10715@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at Jun 8, 98 11:03:15 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"jyXBF.0.sW.PL4Vr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2674 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all ! > First. I think we need ONE LICENSING DOCUMENT. I have no idea yet how it could look > like, but we need exactly one document, for one reason. > Each and every contributor to this project must KNOW EXACTLY what the terms > of distribution are, and must adhere to it. > Each and every file must have the same > /* (c) 199x Erika Mustermann */ > /* for copyright and licensing information see BASEDIR/doc/GGILICENSE */ > at the top. It can't be that different files in one package have different licensing > schemes. > One tarball, one license. > > How this one license can have 'this is GPL on GPL systems, BSDish on *BSD, LGPL if it's > (part of) a library' (or what finally is decided on), I don't know. > > But if we only have email flamewars about this issue, no contributor knows exactly > what will happen to his contribution. That can't be. So we need one license document, > and this one GGI license must apply to all our releases. YES ! And we need to decide _now_. Contributions from many of our developers depend on what we decide. We may loose some, but if we go on to "just code", we will one day reach a position, where the issue cannot be resolved anymore, and we would have to ditch the entire project, because we are in a legal mess that prevents GGI to be used with anything. > I don't fear that some vendor (e.g. Sun, SCO) starts bundling libggi in their > base OS distribution. I don't fear that some HW vendor starts writing > KGI drivers for 3D cards, including libggi3d vendor-libs and not releases the > source code. To me, and that is surely MHO only, this is absolutely OK. > > What I would fear is that someone starts forking an incmpatible API, like > Microsoft tried with Java. Sun and their fan club were big and determined > enough to stop that (AFAIK), we wouldn't. We cannot stop someone like M$ anyway. If they want to steal our stuff, they can. They have the ressources to do a cleanroom re-implementation of about anything. Our only change is to spread out as far as possible. If we can serve M$ OSes ourselves, and be compatible with the rest of the world, how much success would M$ have with an incompatible API ? > We work in the nowhere land between GPLed (Linux), BSDish (*BSD), XFree, > and commercial software (Glide, SCO, Solaris, BeOS, Win*), and I don't think > any existing license can cover our problems here. Yes. It looks like we have to roll our own. > 1) No guarantee for anything, it might even fry your monitor. Yes. A legal disclaimer of warranty. > 2) If you distribute this software , you have to include this license > and the CONTRIBUTORS file (e.g.) Yes. However we should not use the "display" clause of BSD, but keep it confined to human readable files that have to come with the package. > 3) If you want to use this software without modification, i.e. link > it to your application (statically or dynamically), either > (at your discretion) provide source code (open source in > the esr sense) or (2) applies: give credit. Why ? I would rather say : If you ship parts of our work, you need to include the licensing documents because of 2). Static linking is IMHO distribution. For dynamic linking, we need not care, because the credits must have come with the dynamic libraries. > 4) If you write a driver (including vendor-libs) for this system: see (3): source code > or give credit. No. If you write a driver, and do so on your own, without using code from our tree, or only code that has been explicitly marked as PD, there is AFAIK no legal way to enforce a license on that code. > 5) If you change/enhance the base functionality, you have to provide full source > code under this license ('SW derived from free SW must stay free' in the GPL sense). I do not support that. What is wrong with a vendor making some enhancement and making money from it ? 2) forces him to point to the location of the free version, so his enhancement should better be worth the money. More points to cover ? CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 8 14:54:37 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA31627; Mon, 8 Jun 1998 14:52:35 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA01539; Mon, 8 Jun 1998 14:46:58 -0700 Resent-Date: Mon, 8 Jun 1998 14:46:58 -0700 Date: Mon, 8 Jun 1998 17:45:07 -0400 (EDT) From: Steve Cheng Sender: steve@maxt2m22.ipoline.com To: GGI Mailing List Subject: IRC summary (final) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"HWNH7.0.jN.Gl5Vr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2678 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com [IRC session summary: This summary highlights the important decisions reached on various aspects of GGI. I have included the basic rationale for the decision, if possible. I have quoted liberally, if the signal level makes it possible (if I have misquoted anyone, please correct me.) However, if more information is needed (e.g. why solution (B) was not adopted, etc.), please read the full log relevent to your topic. Especially I will not repeat the two licensing wars here :-)] CVS scheme ========== There are, of course, two CVS repositories: development and stable. Only a few people will access the stable repository, while all developers can use the devel repository. Both development and stable will have read access for all. Devel and stable are two different trees. Periodically, the stable maintainers will diff devel code back to stable and thoroughly check the code. This is to ensure that there are no incomplete/inconsistent/ uncoordinated changes to stable, and it will always work for non-GGI-developers. Development should go full speed at the devel tree as usual. New directory layout ==================== The KGI-specific "driver libraries" of LibGGI have been moved to the the kgi/ directory. This includes all the vendor-* libraries. The display-kgi target itself stays in LibGGI. Rationale: Easier separation between LibGGI and KGI, and to prevent the LibGGI tree to get too bloated. "They [KGI driver libraries] are taylored for specific KGi drivers. Though they are technically part of LibGGI, they have to be engineered to meet the KGI driver. Thus they should be close to it." "The patches directory will probably be renamed to something more generic and will hold all "OS-addendums" we need to make KGi drivers run on a particular OS." On the topic of includes and packaging: "... having a top-level include/ subdir, making a seperate package, as Stefan is suggesting, would be a good idea. this way the KGI target could remain part of libggi package, and the KGI backend libs can be moved to the kgi package" Makefile customization have been moved to a toplevel directory. The development trees will be a 'full' system, which includes almost everything. In the future, it should be possible to automatically "Split things to several packages that can be downloaded seperately [for non-developers]. The goes for Libs and such. [also: vendor libs]" New libGGI extension scheme =========================== For full API details, please read Andy's message to the GGI mailing list. Basically it allows per-visual extending and overriding of the underlying API. Some things that are currently in core LibGGI will be moved out to a smaller extension: * ggi*RayPos and friends -- CRT specifics * other "mode tweaking" * ggiSetSplitLine Rationale: Not all targets implement the above functionality nor do they make sense on some targets. Eases porting of main libGGI. Complex mode negotiation ======================== "The new extension scheme allows to connect into the communications channel established by the LibGGI display-* module. This means, that we can link into the communication LibGGI->X or LibGGI->KGI and thus even change very basic things like mode negotiation. This enables us to schedule the complex mode negotiation for later and make mode negotiation schems that fit the current application (3D, video, ...)" [LIBGGI Topics] 1) Multiple buffering ===================== Multi-buffered modes will be done by setting the "frames" member of the ggi_mode struct and passing that to ggiSetMode(). Two manipulte buffers, use: * SetDisplayedFrame() * SetDrawingFrame() Simple clipping on ggiFlush() ============================= To enhance targets having to emulate a DirectBuffer, by restricting flushes to small areas. Have "some kind of clipping list which is initialized to the full display, and reinitialized to that after a ggiFlush() .. and modified by a new call. This way, old applications will still update the full framebuffer, while applications aware of the new call can restrict changes.." Nested calls to ggiInit()/ggiExit() =================================== "Change returncodes, so you can detect it was the last "Exit" that actually cleaned things up." (These calls will nest, and are paired. ggiInit(), if already called, will just increase the counter, and decrement on ggiExit(). When it reaches zero ggiExit() will really deinit the library.) Switch-away/switch-back behavior ================================ Question: "What has to be done when a program is switched away (either the window (in X) becomes inactive, or the VT is switched), and on re-activation?" No protocol implementing any of this behaviour has been decided. Possible solutions: "A callback mechanism (Extensions already have it) that handles this." Or the program can specify behaviour to library. Current KGI implementation: "On switch-away (loss of input focus) a libGGI app gets SIGTSTP. On regain of focus, libGGI app gets SIGCONT. If the app has to redraw, gets SIGWINCH" (Iconification and focus change of windowed targets are other similar situations but no specific protocol has been decided.) Alpha values in ggi_color ========================= [There's no clear conclusion here in the log. I hope I get this right.] Alpha values should go into the ggi_color struct. Rationale: "otherwise another wrapper struct is necessary for anything that wants to use [alpha values]." ("However, basic libggi ignores it.") Some modes have spare bits. ggi_color is intended to be for "a few local variables"; i.e. not buffers or DirectBuffers of any type. Porting drivers to Degas ======================== There are a lot of differences: * Changes in the struct kgi_display * Changes in struct kgi_mode * New fields * all the timing info is now in kgi_mode.tm * textop function table * versioning "The rules for what you can attach to the structures has changed to be much more strict." "GGI Console (the new name for `EvStack') uses the driver's textop virtual function table to provide a lot of the functionality for drawing on the framebuffer. Eventually, a set of in-kernel `This is how you draw text on a linear-X framebuffer' textop structures will be in place, a la textop_linear_text16." EvStack interacts with drivers through a scroller, which replaces the old text16 stuff. Scrollers provide a backbuffer (UTF 16 currently), and is used by the terminal emulation to render on the screen, in both text and graphics modes without difference to the driver. To clarify, "fbcon and KGI are both display targets of the GGI console (EvStack)." (KGI/EvStack now in devel tree.) KGI Display Driver Guide in progress. Also "see the current documention in degas/kgi/doc for some hints. It'll be fully fleshed out soon." display- prefix on target names =============================== e.g. "display-memory" vs. "memory" "Have both by using /etc/ggi/libggi.conf set up accordingly. Official version as used in overriding libs and such is display-*". [... I wish all libggi decisions were as easy as this ... You mortals have been spared from the evils of reliving the horrors of cutting the IRC log :] Layout of memory visuals ======================== [A bit vague here.] Use LibGGI driver libraries (linear-*, etc.) on the memory visual to mimic the layout of the framebuffer. Copying between the memory visual and DirectBuffer will be faster -- no CrossBlits. Graphtype values ================ "The graphtypes are "GT_XXX + depth" e.g. GT_RGB + 16. The resulting mode still could be r5g5b5, or r5g6b5, or r6g6b6, with or without byte swapping, or ..." [No clear decision here on actual implementation in driver libraries. Probably the first one:] Separate linear-* and color-fixed-r5g6b5, etc, like current generic-ramdac. At mode setup load these libraries. -= OR =- "using DB names for the libs: linear-r5g6b5 etc... [which] would load a generic linear-16 (for pixel-stuffing drawing), and contain code for ggiMapColor() etc." ggiGet/Put* buffer opaqueness ============================= Currently: "ggiGet/PutHLine and friends have no documented buffer layout. The only guarantee is that the size of the buffer is width * height * sizeof(ggi_pixel). This is bad because one can't prepare a buffer 'offline' and then blit onto the screen." Extend DirectBuffer: "Having the getbuffer call accept a new exported pointer as the "get first" parameter (which is yet defined to be NULL) and thus allow it to query any buffer format, not only the screen one." That is, use ggi_common_plb_setup values to specify format. Could be named "like DB_FRAMEBUFFER, DB_GETPUTBUFFER, DB_ZBUFFER". ggi_info_db to be deprecated in favor of DirectBuffer. GGI licensing ============= [I can only say is that there's no decision reached whatsoever (except #includes/samples). Frankly, I hate going through all this licensing debate. It's a religious issue that is repeated everywhere in the Free Software Community. I see the debate is still raging on in the mailing list. I don't mean that licensing is unimportant; in fact, please fill out Andy's survey on this issue to get it sorted out quickly. All I will try to do here is summarize some main points.] (1) "#includes and programming samples should be as free as possible." --> BSD licensing with the "give CREDITS" removed [why don't you just call it X-style license? It's more clear (no advertising clause)... and allows you to "sublicense" -- meaning code can be incorporated into GPL code? *duck*] (2) LibGGI as LGPL No requirements to ship source with commercial apps Of course, get back contributions to code. Using static linking, it is possible to fix library because "object code" is shipped. --> decided at first, but seems to be some opposition now... "LGPL is still restrictive" to BSD Loss of freedom (in some aspects, at least). (3) KGI "the Linux-specific kernel portions ought to be GPL" i.e. "degas/os/* - as appropriate for target os" GPL must link only to GPL; Linux is GPL and requires GPL. Otherwise KGI must be modules. Of course BSD requires BSD license. "We NEED to put them under some license that is compatible with _all_ OSes we want them to run on ..." Seems impossible. See above. Public domain is out of the question. No control of code whatsoever. Dual license: Some contributors might not agree to release code under both licenses (BSD, GPL). There could be multiple source trees. i.e. a split, more duplication. "We should allow all driver authors to use whatever license they want. However I think we should propose a very free license as the default." [Still screwed.] "Now if this linking poses a licensing problem, then lawyers are weird. Conclusion : Lawyers are weird ..." :) "I think we should postpone this discussion, as it doesn't seem to lead to anything... we should check with some people with experience in that field (bruce ? eric ? Richard ? ...)" [just for clarification: Bruce Perens, Eric S. Raymond, Richard Stallman] [Whew... Now that CVS is finally open and hopefully most issues sorted out, let's start coding!] // Steve e-mail: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Mon Jun 8 15:59:51 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA31708; Mon, 8 Jun 1998 15:59:49 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA08735; Mon, 8 Jun 1998 15:59:17 -0700 Resent-Date: Mon, 8 Jun 1998 15:59:17 -0700 Date: Mon, 8 Jun 1998 19:04:28 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase Reply-To: MenTaLguY To: GGI ML Subject: OFFTOPIC !!! need help with ega/vga textmode hacks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"RNm7h1.0.L82.4p6Vr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2679 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Just wondering if there were any old ega/vga hackers hanging around on the list; I'm doing a Linux port of an old DOS game that relied on a lot of specific text mode behaviors. So I have something fairly close to the original hw behavior to test on right now, I've cobbled together a conlinux display driver for the program (using a mmap()ed /dev/vcsa* for a framebuffer). While the console ioctl()s supply _most_ of the functionality the program needs, I'm finding that I still have no way to set a non-blinking (that is, high bg bit = intensity) 80x25 text mode with true 8x14 characters (instead of 9x14, which leaves unpleasant stripes in the display when using the 8x14 fonts that are integral to the game). The DOS version used the old BIOS services to accomplish both, but as far as I know there's no good way to use the BIOS services from Linux, so it looks like I'm stuck with port twiddling. Could anyone tell me precisely how to accomplish either one or both through direct port access? Or, alternatively, are there any vm86()-related hacks I could use to use the BIOS? Hopefully, once the relevent KGI drivers mature somewhat, I'll be able to accomplish this through a KGI interface, but in the meantime, it'd be nice to be able to release the port with a decent-looking display on 'conventional' 80x86 Linux. Please reply privately. -=MenTaLguY=- From ggi-develop-request@eskimo.com Mon Jun 8 19:05:05 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA31920; Mon, 8 Jun 1998 19:04:58 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA14675; Mon, 8 Jun 1998 19:09:38 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 19:09:38 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Extensions To: ggi-develop@eskimo.com Date: Mon, 8 Jun 1998 22:33:28 +0200 (MET DST) In-Reply-To: from "Uwe Maurer" at Jun 8, 98 07:34:39 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"OVb6w3.0.Ab3.Ub9Vr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2680 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi Uwe ! > How can I get the pointer to the private data > of the extension without using the VIS_EXT macro? > (VIS_EXT is defined in "internal.h") There is a slight "change of attitude" here: As I wanted to be able to influence, extend and bypass even _existing_ LibGGI functionality, Extensions are now considered to be allowed to access LibGGI internal state. This is needed for things like extending the X protocol anyway (like enabling PEX via LibGGI3D), we can as well give access to LibGGI internal structs. I know this isn't great with respect to extensions being independent from the main library, but I think the additional possibilities like overriding target-dependent things like *raypos and friends is worth it ... Note, that there will be some reorganization in the #includes to make access to things like internal.h less bothersome while compiling extensions. CU, ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 8 20:45:58 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA32054; Mon, 8 Jun 1998 20:45:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id UAA04697; Mon, 8 Jun 1998 20:52:21 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 20:52:21 -0700 (PDT) Date: Mon, 8 Jun 1998 23:46:44 +0000 (GMT) From: Michael Funk X-Sender: mwfunk@foo.bar.com Reply-To: mwfunk@uncc.campus.mci.net To: GGI Mailing List Subject: Re: IRC summary (final) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"r_4Rh2.0.F91.m5BVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2681 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Sorry, I promised not to say another word on this, but... :( Just to clear up a few misconceptions, then I promise to shut up for once and for all: > --> BSD licensing with the "give CREDITS" removed BSDL proper (and all variations I've seen) has no such requirement. I'm not sure where people get the impression that one of the goals of such licenses is to give credit to the authors. I suppose the advertising and endorsement clauses could be loosely interpreted in this way, but even the FreeBSD people have generally dropped those 2 clauses. What it does do is assign explicit copyrights at the very beginning, which generally go to the contributing authors, or an organization. In a very general sense this might be seen as a "credits list", but there aren't any requirements to display the copyrights when the software runs or anything. The only requirements are that the license (which contains the copyrights) is shipped with redistributed and/or modified sources, or is listed somewhere within a binary distribution (either in printed documentation, or in a special 'about' screen, or wherever). > [why don't you just call it X-style license? It's more clear (no > advertising clause)... and allows you to "sublicense" -- meaning code > can be incorporated into GPL code? *duck*] For the record, most of the *BSD people dropped the advertising and endorsement clauses years ago. BSDL, as defined by common usage today, does not contain those things, any more than all BSDL code is copyrighted to the Regents of the University of California. :) Also, AFAIK BSDL code can be used inside of GPL'd code, but the BSDL code that was incorporated into the GPL'd code becomes GPL'd as well (not the original BSDL work from which the code originated, rather the code that actually exists within the GPL'd project). Hence the irony that all of these noncopyleft licenses can intermingle and share code with one another, but GPL is GPL exclusively. > Of course BSD requires BSD license. No. Just noncopyleft! I'm sure they wouldn't have one bit of trouble with "X-style" or whatever the kids are calling it these days. It's all kind of the same anyway: copyright, legal disclaimer, "you must include the license when redistributing", and explicitly granted permission to modify/redistribute in source or binary forms. That's all there is to it! Those 4 ingredients are all that are needed. > Seems impossible. See above. Maybe Linus should be consulted on this. I believe that one could write kernel code under a less restrictive license and have it included in the (GPL'd) kernel. The code magically becomes GPL'd when it is distributed as a package along with the rest of the kernel, but that doesn't taint the original sources. If anyone could get Linus to comment on this, he would be the person most qualified to comment on (and most in control of) licensing issues with regard to Linux kernel code. He's made snap GPL interpretations before (anyone remember, "Does making a system call into a GPL'd kernel count as calling into a GPL'd library?"). > Public domain is out of the question. No control of code whatsoever. ? Control shouldn't be an issue, rather protection from hostile legal action, and optionally copyright assignment (or 'credit', if people prefer to think of it that way). That's really the only purpose of any of these licenses...covering the collective asses of the people who wrote the code, so they can't be sued, and so that someone else can't make the original code proprietary (the original code; derived works are a different story), on some thin legal claim that it really belonged to them in the first place (i.e., an employer claiming ownership of an employee's code, and demanding that people take it off of their ftp sites). There ultimately is no "control" in free software, be it GPL or not. Such is the very nature of free software. If anyone really had control, we'd all be living in proprietaryland. > [just for clarification: Bruce Perens, Eric S. Raymond, Richard Stallman] Bruce would probably be an excellent person to ask about this. He was extremely helpful on the Berlin list several months back, when they were mucking about and trying to find an appropriate license (before eventually deciding on GPL). He is extremely knowledgeable (and appears to be deeply interested) in such issues. Religious issues suck. :( I'll shut up now. Mike From ggi-develop-request@eskimo.com Mon Jun 8 21:00:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA32078; Mon, 8 Jun 1998 21:00:31 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA07980; Mon, 8 Jun 1998 21:07:41 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 21:07:41 -0700 (PDT) Message-Id: <3.0.1.32.19980608232110.006abc98@aracnet.net> X-Sender: dessex@aracnet.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 08 Jun 1998 23:21:10 -0400 To: From: David Essex Subject: Off Topic: DDJ ggi article Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"y4OYO.0.Wy1.9KBVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2682 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Good News ! Got my copy of July's issue of Dr. Dobb's Journal today, and found a nice surprise. A full article on the GGI project ! Kudos Andrea ! Hopefully this will give GGI the attention and support it deserves. David From ggi-develop-request@eskimo.com Mon Jun 8 21:51:06 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA32193; Mon, 8 Jun 1998 21:51:04 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA17990; Mon, 8 Jun 1998 21:57:37 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 21:57:37 -0700 (PDT) Sender: injector@clubneon.dyn.ml.org Message-ID: <357CBD3A.24168DF8@stu.ac.cc.md.us> Date: Tue, 09 Jun 1998 00:42:34 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Duplicate mails? References: <357A51E0.F2D5D86F@gmx.de> <357A5C83.D5F4E2FF@stu.ac.cc.md.us> <357B97CE.EF6BA96F@gmx.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"2UdKD1.0.yO4.-2CVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2683 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Thomas Tanner wrote: > > I meant the one on the ftp site. It was not there when I tried it last time. > Now it seems to be there but I don't have the access permissions for it? If you didn't notice yet I have fixed the permissions. Please, anyone who notices anything wrong with the web or ftp sites, please e-mail me personally. If you didn't notice the announcement on the What's New page and my name tacked to the bottem of every page now. I am the new webmaster. I'm having a lot of fun maintaining the site. But this site is full of surprises, a lot of which I tend to miss. So if you see something not quite right, let me know: cmeadors@stu.ac.cc.md.us and webmaster@ggi-project.org both work, the 'webmaster' one gets snagged by a mail filter and dropped in a special folder so I'll notice it quicker. Yes, I know the mirrors haven't been updating, this will be fixed RSN. I already have the new files on the ftp site for downloading, but I would like something a little more automated. 'Bare' with me, Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Mon Jun 8 22:10:07 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA32236; Mon, 8 Jun 1998 22:10:05 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id WAA20954; Mon, 8 Jun 1998 22:13:35 -0700 (PDT) Resent-Date: Mon, 8 Jun 1998 22:13:35 -0700 (PDT) Date: Tue, 9 Jun 1998 01:09:57 -0400 (EDT) From: Jordan Mendelson To: ggi-develop@eskimo.com Subject: Mesa-GGI, Disappearance of KGI, etc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"IdMv93.0.E75.yHCVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2684 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Just curious if anyone had patches to sucessfully create a working MesaGL library under libggi 1.4.0 (which comes in the degas source tree). It seems the extension registration API has changed a bit and I can't seem to find any documentation on it. Also, is Degas *only* going to be libggi? I noticed that KGI is completely missing from it.. so I assume EvStacks will be the official KGI correct? Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From ggi-develop-request@eskimo.com Mon Jun 8 23:37:29 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA32312; Mon, 8 Jun 1998 23:37:25 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA16965; Mon, 8 Jun 1998 23:33:22 -0700 Resent-Date: Mon, 8 Jun 1998 23:33:22 -0700 Date: Tue, 9 Jun 1998 01:30:54 -0500 (CDT) From: ixx Reply-To: taylorcc@arn.net To: ggi-develop@eskimo.com Subject: Re: LGPLed libggi NOT ok for BSD (Re: LGPLed LibGGI ok for commercial developers (Was: Re: KGI license?)) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"WyhGr3.0.y84.nSDVr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2685 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 8 Jun 1998, Stefan Mars wrote: > As bort Peter and ixx has pointed out to me it is indeed you can indeed > sell GPL code. On the other hand, since they must give any changes to the > source back to the community, a person would simply download and compile > himself and avoid paying. You all know what I mean :) Yep, just saying you can try to sell it. What I like about the license is "open source". That is what I am for. Currently I make money (still in college) doing web pages, and misclaneous consulting. SQL programmming, network programming, sysadmin work, etc. All the software I develop is under GPL or something like that. I sell "solutions" to problems basically not source code. I want my code to be freely available. I just hope I will be able to continue with this way of doing thins once I am out. Its possible with Netscape and others as examples. Anyhow... taylorcc From ggi-develop-request@eskimo.com Tue Jun 9 01:08:45 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA32472; Tue, 9 Jun 1998 01:08:42 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id AAA23695; Tue, 9 Jun 1998 00:59:18 -0700 Resent-Date: Tue, 9 Jun 1998 00:59:18 -0700 From: Hartmut Niemann Message-Id: <199806090758.JAA14804@cip8.e-technik.uni-erlangen.de> Subject: Re: First pass at KGI docs... To: jmcc@ontv.com Date: Tue, 9 Jun 1998 09:58:24 +0200 (MESZ) Cc: becka@sunserver1.rz.uni-duesseldorf.de (Andreas Beck), core@suntech.fr (Emmanuel Marty), ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: <199806051738.NAA10898@pepsi.visus.com> from "Jason McMullan" at Jun 5, 98 01:38:38 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"SFfYG3.0.5o5.LjEVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2686 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > 'becka@rz.uni-duesseldorf.de wrote with particular insight...' > > > I've put my first pass at the new EvStack - KGI documentation > > > on the cvs.ggi-project.org CVS repository (degas/kgi/doc/*) > > > Primary develpers, take a look at it. I should have it fully > > > fleshed out and publicly availible by Friday night. > > > > Oh - you were this ... :-) > > > > Hartmut asked why another docs directory was made. > > > Ok, I'll cooperate with him on this... > I had a first glance on kgi/doc/kgi.sgml, and finally some idea how to manage the documentation. Not all has been sorted out yet, but I would like to hear your opinion anyway. 1) Documentation local to a tree gets a local doc directory, as with KGI. Global and general information goes into /degas/doc. 1b) driver readmes should go to some kgi/doc/driver instead of scattering them all over the source tree. 2) if a given DOC directory is small, that is: less than four sgml files, then the structure will be: .../doc: all .txt, .sgml, .dvi ... files, except for html .../doc/html: all html files. This should give directories with not too many files. 3) if a doc dir (and at least the main dir will fall into the category) has more than three .sgml files, the structure will be: ..doc: only plain text files (doc that is only text, and the .txt output) ..doc/sgml: sgml source ..doc/tex: tex ..doc/dvi: dvi ..doc/ps: ps (from dvi output) ..doc/html/documentname/ : html files for documentname.sgml This is pretty much the old system, except for the txt files that had their own directory. 4) Documentation source will be either plain text (depreciated) or .sgml, currently using LinuxDoc, i.e. sgml-tools version 1.0.x (x==6 here), but I will upgrade to 1.1 and 2.0 as soon as it seems stable enough. there will be no .html file without sgml file, unless you can give me a VERY GOOD REASON to do so. 5) The snapshots will only include .txt and .sgml of the sgml files. Tarballs will be generated and uploaded to ftp.ggi-project.org for all other formats. 6) man pages (if we ever find one who can write them) will get their ..../man directory. Still open is whether a given document should go to 2) or 3). Still open is how to keep the 'derived' files in sync. I have a make file system in place for the main tree (for the old doc tree, that is), but don't know yet how to handle the scattered files. a pm with 'hi Hartmut, I committed bla/blubb.sgml to the devel tree, still have a sgml buglet in there, can you fix it and commit the txt version?' will most probably work well enough for the beginning. Still open is how to create one browseable documentation tree from it, but maybe I'll symlink one. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Tue Jun 9 01:52:01 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA32508; Tue, 9 Jun 1998 01:51:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA28417; Tue, 9 Jun 1998 01:55:01 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 01:55:01 -0700 (PDT) Sender: loic@g5gindy.g5g.fr Message-ID: <357CF492.B722EAA2@europe.tgs.com> Date: Tue, 09 Jun 1998 10:38:42 +0200 From: Loic Vigneras X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: ggi list Subject: Re: Licensing (Andy, READ THIS)! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lN20Z3.0.vx6.ZXFVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2687 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all ! Hi Andy ! > > It is indeed a question that has a lot of emotions involved in it, and > > most people doesn't seem willing to move from their position, because it > > affects so much of what they believe in. I know I am not willing to > > budge. > > Yeah. This is a really big problem. It is an almost religious issue. I'd said it's rather a philosophical issue (and here start a new war :) well, seriously it's probably rarther an emotional issue than a technical one. So, your (moreover exelent) list of questions, may have to keep it in mind. perhaps can you add some philosophicaly oriented question ? About this list ; who can reply ? 1 core team members, 2 ggi developers, 3 every one who is interested in the ggi project ? For myself, I prefer GPL/LGPL ( have a look at http://www.gnu.org/philosophy ) Public Domain may help in the short range (that'snt sure) but never in the long range. Open Source Sofftware need to grow in the commercial area. And BSD style, even with "give credits" restriction is too "free" ;) for this purpose (IMHO) -- , \|/ -------------------- trav: (33)0556133777 ce que j'ecris \|/ . | V Loic (Loig) Vigneras FAX: (33)0556130210 n'engage V | `- ^ Loic@europe.tgs.com -------------------------- que moi --- ^ -' From ggi-develop-request@eskimo.com Tue Jun 9 04:00:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA32593; Tue, 9 Jun 1998 04:00:45 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA10681; Tue, 9 Jun 1998 03:40:18 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 03:40:18 -0700 (PDT) Message-Id: <199806091040.DAA10653@mx2.eskimo.com> From: "Kendall Bennett" Organization: SciTech Software, Inc. To: ggi-develop@eskimo.com Date: Tue, 9 Jun 1998 03:38:34 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: MGA Impression Chipsets. Priority: normal References: <199806080910.LAA10824@cip8.e-technik.uni-erlangen.de> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.01a) Resent-Message-ID: <"4JyxX1.0.jc2.G4HVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2688 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > AFAIK from Matrox only Millennium I/II/AGP and Mytique are in the works. > > > > Is documentation for other chipsets available? > > > > Hartmut. > > This is a matter of definition, I have yet to aquire any kind of assitance > from Matrox proper, I do have enough information on the IS-ATLAS to write > working drivers, although not optimally accelerated and I have hopes that > with such a driver in hand, It will show Matrox that they loose nothing > from releasing the full specs. Abou the other cards, I have only about 40 > lines of documentation (A diff more or less to the basic MGA engine) for > the IS-DUBIC but I have no hardware to test this on, I plan on aquiring a > few cheap Matrox boards after I get the IS-ATLAS driver to work properly. > > Luckily whith the MGA chipsets, they are all base on the same core. So > alot of what has been written for the Mystique and milleniums, will also > work on the older chipsets. Beware that if you intend to support the MGA-ATLAS and earlier chips (ie: before the MGA-STORM used in the Millenium chips), that these devices do not have *any* hardware linear framebuffer. The chips are similar from the accelerator point of view to the MGA-STORM and later, however the only direct framebuffer access is via a 7Kb sliding window (yes, 7Kb, not 64Kb as you would expect!). Hence these chips are a royal pain to implement support for. The one saving grace is that the framebuffer window start can be aligned to a 4Kb address, and hence you can implement a virtualised linear framebuffer (but I don't know if KGI is currently designed to allow a 4Kb window instead of the regular 64Kb window that all other chips use). We don't currently support those chips for this very reason (in SciTech Display Doctor that is), although one day we might get around to writing the support (we have all the specs and sample boards to test with). Regards, +--------------------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +--------------------------------------------------------------------------+ | Kendall Bennett | Email: KendallB@scitechsoft.com | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +--------------------------------------------------------------------------+ From ggi-develop-request@eskimo.com Tue Jun 9 05:45:26 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA32672; Tue, 9 Jun 1998 05:45:23 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA27336; Tue, 9 Jun 1998 05:34:55 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 05:34:55 -0700 (PDT) Sender: torgeir@eskimo.com Message-ID: <357D4696.E7F88A3@vertech.no> Date: Tue, 09 Jun 1998 14:28:38 +0000 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i686) MIME-Version: 1.0 To: Linux GGI Subject: [Fwd: Try my new DMA kernel functions] Content-Type: multipart/mixed; boundary="------------35CC0BCD434F0C25E25A44EC" Resent-Message-ID: <"BTFO-2.0.zg6.hlIVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2689 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This is a multi-part message in MIME format. --------------35CC0BCD434F0C25E25A44EC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is very relevant for libGGI / kgi interaction. See also Alan Cox' response on linux-kernel. -- Torgeir Veimo, Vertech AS, email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 --------------35CC0BCD434F0C25E25A44EC Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Delivered-To: vertech-torgeir.veimo@vertech.no Received: (qmail 724 invoked from network); 9 Jun 1998 11:58:07 -0000 Received: from sabre-wulf.nvg.ntnu.no (root@129.241.210.67) by dns.subnett.no with SMTP; 9 Jun 1998 11:58:07 -0000 Received: from vger.rutgers.edu ([128.6.190.2] EHLO vger.rutgers.edu ident: TIMEDOUT [port 12102]) by sabre-wulf.nvg.ntnu.no with ESMTP id <49279-27049>; Tue, 9 Jun 1998 13:55:58 +0200 Received: by vger.rutgers.edu id <970821-9848>; Tue, 9 Jun 1998 06:06:23 -0400 Received: from Zuse.suse.de ([195.125.217.2]:64549 "EHLO Poisson.suse.de" ident: "TIMEDOUT") by vger.rutgers.edu with ESMTP id <971039-9848>; Tue, 9 Jun 1998 05:52:58 -0400 Received: from localhost (sim@localhost) by Poisson.suse.de (8.8.8/8.8.8) with SMTP id NAA20260; Tue, 9 Jun 1998 13:34:03 +0200 X-Authentication-Warning: Poisson.suse.de: sim owned process doing -bs Date: Tue, 9 Jun 1998 13:34:03 +0200 (CEST) From: Simon Pogarcic To: linux-3d@suse.de cc: linux-kernel@vger.rutgers.edu Subject: Try my new DMA kernel functions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Hi, I wrote few DMA kernel functions, based on sound driver code which works well so far I tested it. Unfortunately, it is not implemented as module (/dev/dma) because the standard mmap() function prototype is not sufficient for all info exchange between function and application which uses DMA. The way the code is written is described in README, and you will probably recognize that it is based on Linus' proposals. Patch is written for 2.0.33 kernel. However, to test the new functions, you will need to load the test module 'dmatest.o' and 'mknod /dev/dmatest c 127 0'. This calls the new functions and prints informations. To trigger the module use 'test.c' (you need to compile it, of course :) Please consider the code as an 'early alpha', as 'test code', as 'proposal' - I'd just like to hear your opinion about the whole stuff, and future plans considering DMA-feature integrated in kernel. When writting to me, please note that I'm not on the kernel mailing list. tgz can also be found on www.suse.de/~sim cu, simon begin 644 kdma-2.0.33-980602.tgz M'XL(`.88=#4``^P[:7?;1I+Y"OR*DC(Q28NDJ,.2+5F>,([L:"S)?I)R["9Y M&!!LBACAX`*@*.W$\]NWCN[&05KQ)/',>_N&?A:)/JJKZZ[JQIE_HR9AI#[[ MA)^MP6!O=Q<^`X"=[7W^AKUM^:;/[NX>-CS9V1WL[._C0-@:/!EL?P:#3XF4 M^F_WH!?O/L6_ MW_M1Y+J7%R^I?1S[A?B>/CUV?&G7>-A_=\:[.QML?X_&6SM[.RC_L/^_I.M_^C_O^+CNK#Z M\T9EB8H@G\]F:5;`),W@Z[,AC.:3BO"#FG22%%DZG@=%F*+:U7NO MI@INU/TBS<8Y+UA,PQS\V2Q+_6`*?C*&*?Z)PN0:4E16'#Z;WN=AX$<0JSC- M[M%^S),;G),I-XYA,D]XH1Q:GG>M"F^2*>7-_&N5M[K0PCE>[,^\3.4JNU4M M7J&5*6JC05[F)]>JU4>\W-R/%5J#8)J$`2!6*`UC"!-&(D_G.'&UAD:4%C8P16(6J0)D5X/4_G>96^7?Q1P"(LIG"3 MI(L$QF'NCV_]I"#DZ2F8YXB"FPH*-\*MV`^1.N$U1"&:.;B:IKDR@YD.M,/3 M,)GG+4"JSM+M\E]M:F-QB,+/Z>Z!&E`1IIF(09SLW4_\S###&0G4,> M_J^2C:_BF>"3J6*>);FKN3V?(?K0WGK^O'U^X9T=GWFG)Y=7E[VMC7?#U\?> MY3J[[Z=(/OG68[D;8O0=@0/4FOL MB5#^E*PH?-T.M:>L#*=(5[YMD9(++0X+V1(NC-6I&4BSZ MZJY0R9B5&?+[O%`QTS(_0",_%*UCI81>^7$=W"1*[[57P&-\2#U\9A5MSY,\ MO$X07)2BJI/@=ESW%2EMEVEG-TX2%OH1#A`6M"S(%NXX0'.N,5V$R-EIBMA2 M7%D1;S1,(Y(IVJ:Q#\8BD!E321?921:G:1.Z*+1ND86T=`K8QQBP54+!O@[S MJ=5708&)-2&5$,N9*$4D:Z,"%^A5.BYMM`\G$RUZQ`)4?P)&UIUAT:)06S2/ M23DR4N.\#\>D7NZ$W0+/((E`@J!15EK?6^.1Q_K>0B.0H3^:\NAJ_/CL^O+LGLD3"=O3':MQU:5#5 M2FEND]<>:T&D(>-TCCM%1),;$BLL:.A-+D$$RYIB;7&V&+:E8(+TTB M=.0H!D11[55+CB(=;F,R87Z7D"XX4ZA42HJE4R!FC2D2G=D7@ MP1F/`$7]@JFFP_*J3RN0X+E07`S\/)%`B8-')-Q$%@2VYU7A8`UR;Y32@4Z1 MD=YHOVF]@X:-4H@J4X@6E2N.4Y4GK0)$X)'8.D84&2>HD8_TMM*1&X48$R1* M`_QS7\\SP4]L)G1[4,CKJ%K=;^OD2+1?#.+:-O)\P"21, M-'Y=60(8LV3HT#=:6U$3US!ZZM^RY\15DT`)YN5&U%V@9C82JCA_DGS,3"PX M5F!+^!['W+*A<@-@-D#1+\5A*0SZR^6%ARL$RQ4#"'IQBHL]V7SV=+G>L%@L M^E29Z8_5YC\PG5E9E,#V+_6@_\^EO-_T006CO**WW1_T=W9ZSYX.]@;;_7$X MF?QQ:SQ<_]O9&9CZ__[>[O9@&S`/QQ__J?_]*SYHBLG5SN^,!'!!?#..-RGF M[`?.JRR$\_068!^VGAX\V3_8V8*M9\_VW8V-#9E9&7R%QNTO\P1@&[9V#@9[ M!SO/:/!3]\LOH;>UV]V##?S[%+[\TH7/T<9%\[&"YQH*&YC^],5R%T4'M,"J MOGPA'1O-CD5&I8QL91]*/0.K@O/S>#-7UV1T&PMQ#^?3U$%;V7ZV1WO9?O:T M2^S#BC6=L'&VE[4,U5G'>MB"* M-OB`P?RN6B9!8"@F^J9Q<7A'_O0>`C:U,:8?R#,MV!2BUK0_3;-)3XDB(+S&#:4(LL)ADE,B#[)[C61G9<3?^ M[FXX.14Q`SF2FE`DQ@=2ZS_B0INO+GY>1ZP=AA0D!>^@$4_&9%FHI]F.J-=: M"4@H$%`$V@3O:'#(<)\SFO)[8P,1S*8>)\Y`#Q'Y M?_J!4S!'.2P9XCBR;T3I;/C..[]H5R;30!R`0U=V(_8:.,886YU?W86L9+`G ML$OHZS%=[JWC2>K6#A$1S2@(X?F1<`="(3;A*GIE$A?5#F43I?JU88D\3!7@ M@6@$K!VHIDZ_5FG[51$++ ML^D((\1E>9Y-">,/RCDM,(%VFVM(1\`E^>'IR>MS;NET,"*$00?^7O(6F+DZ MP4XQ\)U$Z<*R5,BO+2V;%Z$R_B4[Z^#&*$G2^9&M!)B$FVI"3#6.?$0C$VI',X=`PS#!C51;:HTOCK18 M`:LA@W%$`!%.TP&V*WSH6E$>"%F)*;"FYVK6U*S(\.+U-VOPEE7VBS$F15-, MZ3'/6:M:$8:I`;(\PYK>N059A6D2*$ZT+X9G:PU>.]J`:-EX5D#6!O566T(G4:$8>Q@U3?` M4<5(2`_9\J.*B9!6L8]'FJRK[7PIMI]_@7;=+TI_5;HK9!A3ENBG&KV.&-\Z?[02&\;81\.1P5W@!_X$_Y6F>ZT,^CHF M^K`QH+@<%>7*=E'HQZ8I47=V2&FP9IFZ%2,B0ZT3TR&C'6YC1&&&GHXRF)0[ MD39N*,=7>P0%0R]C0X4Y1Y7831.6%[<.FTM09>D3ZKX6/CY0U)3D22(S!%K0 M-ELXM`2T*U@"VKVL&&3H65)7%C0K5JAFY+7J$;X?7IP?P%=259IEZ0C%3PK$ M51,H\O?>1CY::&OT[-9<5*>"A>Q$#(G\KDG"2"/M6#EJ"(3M=TJ(U&8@TN^Z MQ%E:U2&64JL'&'AK&D?XY1>]7J=33JMF*AJ)JF)^,$H5"FO:ZJ(;6C-;5:V8 MA:0>1;\O17)P^&`(^<&B*T9?1J+4C@20N6";; M;DL]C21^5='[J]_MFD#W)''1!_!KY['<7)]\-KXZ[\.[B[97W_<4) M_7ZDH70:8/AIN^_\OL,K@6G)U?^(`RPF3N/$2L#0L=72H54[[]3.K?C6#-7$ M5YY9K2*DDXTL#5>0%\7X465$267\9:/TLFS/]V>HI2)>'V+-X#?R9;-2'N'< MZ0-'UR`IYG*^V`4=(38/M?CXNC%!GUV;";43;"/3'^/;SLXD`Q5I@#C6A]I( MZCC&4?IZ%=WKJ0RK'X#CV-O8+QW^9D%2PP6W[,8K,AHR8G*:#W&5J_$V=J,A=UL.8;3(4E/*3^]1!6TUD/OSY[) MLVGNPRF?8J%QAVFZX/,FF6NT8)%F-[I$&,C=$[*NP52A?:(C03KFL6OHN9E" MD::#H+$YB3?J10<_/BTXG_5E,"7#3A/)0^,N/RJ;?RB=7TJ(M!_I'9^F#L4C`UL)U=MG=FW4Y)#FE]&J(;$A M:95>22JW6"EC\V=-DBU33$3=P]O+4>_7MU;<7QW\6/C'4&-FC M)AX[`7@$WYUYIV]?OCG^6B-:MW@$1U$A@:;)@X>>^?ES*.LWC(P>N&$+4;(' MW?RB]`59%,8_7IR>G)U<4;V(UOZY3XT>#EDEU?6QG*%$*EX2\(^A6$FRX>OA MR7E52-RR>CA.Z<28KFZSY).$\*%X+O?0Z/I=UHO4K8H@0TL;)@K#P]2,"D@)QG,^W88(R?L$YG9<=15]<[?<%G'82"U%6:].?K!22WVL M?H_@'RR99ZACJZ3)3OR#!*EN3JU!YX5UR85JE7(%!Y6'0I^V1'&FTJH34#X? M68$QM1\=#584C/])5$N?M4+F*=>*0[EPK64-!2>4H&>F\R>^AD@[R"4%HAO6 M,I^9I:_H-@\=VQT>8^2@Y#!=)C+)!JL"RP-E''+;&NTS&,(=ZA!((B`^#:6% M,)R@0[XT%M6D6WY&8BA+Q]"2RLX?B#P[NBIO"OLKAW4X4%ZJ\R/#$/@#E7Y: M>IEE_Y1=MPP37B'$W@M$CF-K":E-DSEQDX/GLEV*P/IHS1AFTRFZ=`3F9YMS M!?[9@5^@YBB6Y_UR1*[C;/A?]`89#I<'SG4.:Z)%7"0[0#:'XUN>;N]6\YTQ MOOB:*#0_;3J"[M2,F8#Q(RH5L/Y>?C.\0`7NR04DI'/L)W1#@,_2IWS!NS`W M/?5DOB678Q+#]Z0R0JIG'R?5A*^4GU7[U4N;[?)C?;O\ADN>:@N]H(O7=$6! MHJ7PH/2V#ZXB0PYUN&%&L$81CZB@3B\3L=FD0.O'.I!',+@;3'ZN\BR=Y940 MWK9.)KFR=2W3&B;I6*T8/2M4F>[8^XTU8T:NYV6D,%>D2_ZLJ*5/>LG>Q[]& M=T(7P*MF7NZP]\LHA<.4(BW\:"GUA'TGS59S$7,6S^,_%$8A<5]OTJ/)H?;#6%D MQ9/TRSZ5KG&-;4$ZOYYZLI".7U]`[0TI<3X-.M4(U83S:;U2@IDOQCCD=DA1 MUTJS\/`AI[&(1W).1'L]:MX+J)G.BC->VNU8IG9MYJT-Q<$*8(T[!JP\LU2, M;&4Y6NY]2`Z;T'^_'-8".?H2SF%"8RI'TEYZ MS8I"+>F"H8FC'?("\4J0U3U];+<=%4%L"%".H^K38.87[WDU(%[ MQAC+9S33I`4!!_SZ0CJE!GP(S5:D9E!UFE8W`":P^;C,L!ER./4,\8,KV%L! M#M<4`Q,@(_':;6YZW!'@FD/FK%;`8-:LFWG]C:5VS_/SV//`\V[3R"_"2'E> M>WW]``[6LW5H!QU=&S"GI3J1'W1*%C>K&'Q0C=\;6Z;49^7*;13)JE7)VF7` M56>*XC_KAXKR;@(L5WT_HA[[[5EY*2TK_?IRM;A>J;$W1^1@K;%YZT7:T#8G M2-;W0^G\H5'[:\+I]0X?.N9GK6:@\/8-1>QT@/.%!!%<:>J4YG8)QRI7ZT^9O!>MA:5,E%MRGE:EKK*TZ-ZSNBN.@3[?)[4=XK_P`7T;(!L?JU( M/6T,)";,OFMM7TNVV4_?_<`]77DG=/,FOX_S?N"<81I-EW6W!K#U[.#)X.#) M7O.R;F,&7>\]\^]A^QEL[1T\>7:P^[2\L;N[3[=<\>_^RAN[YNKM4D=`;\&N M[*&W?7_E1BZ]Q8JTM%++HN[/[[RQN@T#\A-%--/3%C]K.["`OLIT1.K*^\NCNZK+P[PK5AZ M!8&-*0.1`QK.#\VS&(5JBUFH;"$?5&N@`UQ"!9'!Q;DLG_B1?:5?XJQ*BH,8 M$-K-2U`(@J[M0V\.O5ZB%CVB-?3ND'9%&J3)I#^EIR"-9\P$>KC%.(:.T:;_ MU]ZU-;5Q+.'SNOLKUJ22[,H2[`HA=*20*@S"(5SD0B(^E.-2":UL9.M"(N-YD8M6ZIQ.899+]=HI0IKXO[A M_O&I8JM^RVR%[51I19SCP3RO7C,Z;2O*Q!H:/:B+F72@ZMIOT@K!#8#-,Z1P MYQ[#GF#&[(PB-95'UCEXM$A[Y9;IENL3]7B'LCOGCFI@;V)B%YML"2FT<6AC MH90";W(#A'(FU)#I!C(/?%F=9?[M&9L11?SI8@YKE:Z1S#P]-;7KUC<9 MWXX6>?M4Q+"XJMQ6Z$'G!X)&N1M/*-VSW-03J>64N;MN1[I&)G9 MV"X$MMAC/N_,IU.,V'%SGHZO1D-8&N,1K*]'#\?I/+V9C%2,EJ)3D/.+3OD' MZ@9NN#)>;]3116>6.\&=W,=.<:('\?/,G_NU%PDKND>)H3 MXU''2R!IP(]P%4KH$D^TJY`YG%_U>V>OVA[B6Z2;/(*K7VG.,>Y&IIBD2U*2 M$>8/=$E,=/MXRUXB.TO0S^@S'`?`;[E4V\>=X[.CSFD7**N*4N%Z*&(-`AI[ MW*J29J=SW-M_>:J(:C'2=-#E>JY\5`)]:VCG>Y>>\"OH*U`W8B4$3DV,A_/1 M9/X).+7@Z$5`O;7[^_*D\[J[VWE]C".4Q*K'(#(,/U8FXX_HG?K>L!"2;K=] MK*!;I&LP7;OWO]Z+[AD6_MY>:D_/UWI2'2_O*[;Q2/S'C<@*1L_AKL88W MEC.PF*RN1UG/BMZC%RLB48:J7/%]DI+5R/=YF`D9.NUU^R?MP_9VM]WR?8D> MH0FB=]39/>J^)`2IU^[V$#_B,L2^PH.\/DT!FK%5-UL4R%-P1PBA:K-*I3$2 M-5#\3,-,(N'EX&I*E(,K-'2Z\VVK/R]ETR,O*PP<&'YH45@/CSTU4-[W_FB? M[.^=O=H^.0JANK)H`%@S=%@97O[51^WPNT7X$U52#JB@\.3B\LC,^0:+^G.& MWH7*R"%@^)^D$X.`JX&C`$!8PZH"PFQKS2A0>:Q;\)4J1INA1KYW9Y$;4S0* M6")JS6K1GW50(N)G*479=$HC4W9\TK,#S5%[$F_+++/WMOC"G): M&D37\(>@LB_M?FSU.I#]Y5>0O;Z'<5)%-/;*F0*/K:!!)9?"K%PQE+E\7DM. MEEY?[-1F9;%$ZGF^'"4:/K3:9TN(;$G0"OE!N2"Y"T+U2[^NG$B-65KK5V6E M'`)0[`FQDJ_GL(Z=@OQ7+&A-5R+UTO,$`>\OVRE4/V7KS;)LGV2>"?<8K*Y@ MP[-DYN#8>L_G,%_MW25&$DMCYZ2DQ[-E\I;W`[L\G@-3KZTZE%:[1'_*&@91 M##S^UDO1$O"&T[07T>&D]/,+ND9-5Q:'>FG+3T\%&XQ*$/Z81&6 M7TN>`*P>"VCW%X^Z&-+^'&Y)#NRW.QWL*>L#&"2\(,H/_S$3]TBY_!__OH7= M(6_Z&4*ZQ%+`B%$D`)HT"YR!Q90B5.(<^X?S04IV3XHC65VU#T6Q=-_\N'@K M!XWC5INC/E0M;&G%07]X<07?0W.EELW=OE+^B0BP=/9 M@`,6Z2H#!8H'UAD4F`9H#C,59X?/5^R<*;.U%>/=(._Y_,A`X[NJ)5HVF2ID M:;."4H\H++/QXD+2%!TF-%L$.]Q,1^:^:K->T_)?4:E62_S8VG^2_;_'X6E$"2QHE@/YO MO@BHPBDYF:9`=K$D+5^K&RPMGG<^GT]:IO[>R6D;;IC$).QM'W8Q)<[HC?[$ M0>9)=X(@U9M+Y=22OD6\$2W/A">;4BLPZ%Y:\\F6``4*^D#TM#6)M5=A[4I& MEU(*^H-9VM=<'Y*S_(%\+!$3_T<6>2)7:1M,ME%,%`LZ!"EJYS(5Z@V#1M-; M,!0\FKV_OE!56/>7TDQ@!;.K58E]5M#44H>*`_X[3ZJ84Z(=2VV&5D&OL1GE M^4B\_KW@&N'8T[/6K1UXYD&`-8ZSO(:55[7RDOJ!R*M9>>M5F=>P\NJU`Z<] M66FU<>"T&&=]Q=#GG_]0XO$.,(+A;?FRO(A(C`W#\#;ZY9>D'CT/PTOXU(`/ M3OM!AC[ MZ]1.T[BG2"J`C!]`0E&NS*>2;+@<-OU7@'`QQOH02HH,T4J+A$P^X*])4KH< MIWU.&<+GEA%D2%I'"Z,PT&9Y*,?@NJ=#^%UV".],YN0_H__K`>H/BC36R>M[ M0R@'<@4V3$*%JIUJEB+4_&(P&[L(#,:>03&*C1_A:Z7",HM=\./X>H`""_Y% M%QH;90B1,B@%YG<4K1$H"S(+]<""4:;S#RTG93">(2?1XKZ^&T]N/CC:=85W MNN[:A#3F9/E`->ZT\1F2G,22L5NU0V:4(J[;K:447$\O4VU.1 MO43](EBDU:B9"WU`_DJ3P<=C7@^D3L.BB2<99/G46\,M(3@ZOFES8Q="W(V# MJ_?#,M^&\/GVS5O<]W@BJCZB$P`445T/Z7/P:Y`$ZEC#)$66O,7E]7/\,^FB M/#CH:%.D(.B?#\X'K:+"B5/X?#!$[*NX<#57,T8R&XX*"Z\[A3'D&7<#)1B8 EA,3WL@./3@%K3["0@P/VO9FXI^?I>7J>GO_C^0<&7O2.`'@````` ` end _______________________________________________________________________________ simon pogarcic sim@suse.de www.suse.de/~sim _______________________________________________________________________________ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu --------------35CC0BCD434F0C25E25A44EC-- From ggi-develop-request@eskimo.com Tue Jun 9 05:46:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA32676; Tue, 9 Jun 1998 05:46:09 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA28622; Tue, 9 Jun 1998 05:40:28 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 05:40:28 -0700 (PDT) Date: Tue, 9 Jun 1998 14:35:30 +0200 (MEST) To: ggi-develop@eskimo.com Subject: Re: Mesa-GGI, Disappearance of KGI, etc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: 08142597465-0001@t-online.de From: Uwe_Maurer@t-online.de (Uwe Maurer) Resent-Message-ID: <"lKCSl.0.5_6.wqIVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2690 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 9 Jun 1998, Jordan Mendelson wrote: > > Just curious if anyone had patches to sucessfully create a working MesaGL > library under libggi 1.4.0 (which comes in the degas source tree). It > seems the extension registration API has changed a bit and I can't seem to > find any documentation on it. > > I will put the new ggimesa patch on my homepage after the #includes of libggi are reorganized and display-kgi supports ggiGetAPI(). glut-3.6 is also ported to ggi, so you can run all OpenGL apps without modifications. Uwe From ggi-develop-request@eskimo.com Tue Jun 9 07:08:01 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA32736; Tue, 9 Jun 1998 07:07:45 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA13949; Tue, 9 Jun 1998 07:01:02 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 07:01:02 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806091358.PAA17747@sunserver1.rz.uni-duesseldorf.de> Subject: Re: Mesa-GGI, Disappearance of KGI, etc In-Reply-To: from Uwe Maurer at "Jun 9, 98 02:35:30 pm" To: ggi-develop@eskimo.com Date: Tue, 9 Jun 1998 15:58:06 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"DRrBT.0.rP3.S0KVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2691 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I will put the new ggimesa patch on my homepage after the > #includes of libggi are reorganized and display-kgi supports ggiGetAPI(). > > glut-3.6 is also ported to ggi, so you can run all OpenGL apps > without modifications. Great news ! Tell me, if I can be of any help other than making the GetAPI call (which I will do RSN) ... CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Tue Jun 9 07:28:56 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA32767; Tue, 9 Jun 1998 07:28:53 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA16814; Tue, 9 Jun 1998 07:16:18 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 07:16:18 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: Mesa-GGI, Disappearance of KGI, etc Date: 9 Jun 1998 14:15:07 GMT Organization: OnTV Pittsburgh, L.P. Lines: 19 Sender: Jason McMullan Distribution: local Message-ID: <6ljg1b$921$1@butter.visus.com> References: <6lih1d$sli$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"edlt12.0.Z64.mEKVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2692 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jordan Mendelson wrote with confidence: > Also, is Degas *only* going to be libggi? I noticed that KGI is completely > missing from it.. so I assume EvStacks will be the official KGI correct? Yep - EvStacks (now know as `the GGI Console') is placed under degas/os/Linux - KGI is currently being defined as `host independant' so a KGI module can run under Linux, FreeBSD, XFree86 (XAA), etc... -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Tue Jun 9 09:48:58 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA00131; Tue, 9 Jun 1998 09:48:55 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA07144; Tue, 9 Jun 1998 09:44:33 -0700 Resent-Date: Tue, 9 Jun 1998 09:44:33 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Licensing (Andy, READ THIS)! To: ggi-develop@eskimo.com (mailing list GGI) Date: Tue, 9 Jun 1998 07:51:24 +0200 (MET DST) In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jun 8, 98 07:41:50 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"eeA0L3.0.Tl1.mPMVr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2693 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Sory CCP error : > D1. Should programs that are dynamically linked to some part of GGI have > any restrictions applied ? Which ? > [ ] give credits [ ] release source > - D2. Should programs that are dynamically linked to some part of GGI have + D2. Should programs that are statically linked to some part of GGI have > any restrictions applied ? Which ? > [ ] give credits [ ] release source [ ] allow relinking CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 9 12:12:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA00322; Tue, 9 Jun 1998 12:12:52 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA32540; Tue, 9 Jun 1998 12:08:19 -0700 Resent-Date: Tue, 9 Jun 1998 12:08:19 -0700 Date: Mon, 8 Jun 1998 22:57:49 +0200 (CEST) From: Michael Krause X-Sender: rawstyle@localhost To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"hnSiU2.0.Ey7.YWOVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2694 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 8 Jun 1998, Stefan Mars wrote: > Xggi doesn't incorporate code that is gpl or lgpl (unless Krausse put the > server itself under it, something which it is my understanding that he > can't do), but instead we _link_ against LibGGI. [...] Oh, just let me drop in here. I just noticed I never mentioned officially on this list that XGGI isn't being worked on by me any more. I've decided that this beast is a bit too large for me, and because of that I'm not particularly thrilled by the thought of being mentioned as the maintainer. XGGI is a kind of core application for GGI, and it deserves a more enthusiastic maintainer :) It's just strange that noone seems to be seriously interested in it. Other than that, I have a comment on the current libGGI discussion (I hope I'm just misinterpreting things). I remember it's being said that DirectBuffer use is deprecated. I must strongly object to this, as this kind of frame buffer access is IMHO the service a low-level graphics library is ought to provide. No, make that "the primary, most-important and only service"; I think even ggiDrawLine, let alone the text drawing functions, don't belong into the basic libGGI. Does DirectX provide a putString function? -- michael krause [aka raw style / lego] - http://ms.demo.org/rst/ From ggi-develop-request@eskimo.com Tue Jun 9 12:56:07 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA00381; Tue, 9 Jun 1998 12:56:01 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA07894; Tue, 9 Jun 1998 12:49:37 -0700 Resent-Date: Tue, 9 Jun 1998 12:49:37 -0700 Date: Tue, 9 Jun 1998 21:49:03 +0200 (MET DST) From: Rodolphe Ortalo X-Sender: ortalo@schubert To: ggi-develop@eskimo.com Subject: linux-2.1.103 config specials or 2.1.105 GGI patch ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"_1D3M1.0.Ex1.G7PVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2695 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello, I am currently trying to setup a running degas system, but I fall against an unusual problem: I'm unable to compile a running 2.1.103 kernel... :-( There seems to be a problem with IDE disks or DMA for disk or smthing like that. Is there a known bug to avoid on 2.1.103 systems ? I may have an incorrect config. However, with the same config, I have a running 2.1.105 kernel, therefore my second question is: does someone plan to update the KGI patch for 2.1.105 (the current 2.1.103 patch fails). I fear I don't have the knowledge to do the patch myself (but I may try, I have the motivation now :-). Thank you for any clarification, Rodolphe From ggi-develop-request@eskimo.com Tue Jun 9 13:23:50 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA00425; Tue, 9 Jun 1998 13:23:45 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA13278; Tue, 9 Jun 1998 13:18:45 -0700 Resent-Date: Tue, 9 Jun 1998 13:18:45 -0700 X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Tue, 9 Jun 1998 22:17:45 +0200 (MET DST) From: Stefan Mars To: Michael Krause cc: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"69vdZ3.0.LF3.aYPVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2696 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 8 Jun 1998, Michael Krause wrote: > Oh, just let me drop in here. I just noticed I never mentioned > officially on this list that XGGI isn't being worked on by me any > more. I've decided that this beast is a bit too large for me, and > because of that I'm not particularly thrilled by the thought of being > mentioned as the maintainer. XGGI is a kind of core application for > GGI, and it deserves a more enthusiastic maintainer :) It's just > strange that noone seems to be seriously interested in it. Sad to see you leave.. I wonder who will maintain it now. > Other than that, I have a comment on the current libGGI discussion (I > hope I'm just misinterpreting things). I remember it's being said > that DirectBuffer use is deprecated. I must strongly object to this, > as this kind of frame buffer access is IMHO the service a low-level > graphics library is ought to provide. No, make that "the primary, > most-important and only service"; I think even ggiDrawLine, let alone > the text drawing functions, don't belong into the basic libGGI. Does > DirectX provide a putString function? DirectX handles stuff like modesetting and directbuffer, but no putString, no :) -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Tue Jun 9 13:37:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA00447; Tue, 9 Jun 1998 13:37:14 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA06483; Tue, 9 Jun 1998 13:36:11 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 13:36:11 -0700 (PDT) Date: Tue, 9 Jun 1998 16:13:54 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: linux-2.1.103 config specials or 2.1.105 GGI patch ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ciKzo3.0.Ab1.uoPVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2697 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 9 Jun 1998, Rodolphe Ortalo wrote: > I am currently trying to setup a running degas system, but I fall > against an unusual problem: I'm unable to compile a running 2.1.103 > kernel... :-( > There seems to be a problem with IDE disks or DMA for disk or smthing > like that. Is there a known bug to avoid on 2.1.103 systems ? I may > have an incorrect config. Edit /usr/src/linux/Makefile and _comment_out_ "SMP=1" Then recompile the kernel and try again. -- Brian S. Julin From ggi-develop-request@eskimo.com Tue Jun 9 13:41:15 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA00459; Tue, 9 Jun 1998 13:41:10 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA15374; Tue, 9 Jun 1998 13:38:47 -0700 Resent-Date: Tue, 9 Jun 1998 13:38:47 -0700 Message-Id: <199806092038.WAA06084@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: KGI license? In-reply-to: Your message of "Mon, 08 Jun 1998 22:57:49 +0200." Date: Tue, 09 Jun 1998 22:38:30 +0200 From: Marcus Sundberg Resent-Message-ID: <"FIquv.0.xl3.MrPVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2698 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I remember it's being said > that DirectBuffer use is deprecated. I must strongly object to this, Huh? I really hope that you got that wrong... Could someone please deny this! //Marcus From ggi-develop-request@eskimo.com Tue Jun 9 13:51:46 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA00468; Tue, 9 Jun 1998 13:51:43 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA18179; Tue, 9 Jun 1998 13:48:11 -0700 Resent-Date: Tue, 9 Jun 1998 13:48:11 -0700 X-Authentication-Warning: flensburg.kapet.de: kapet owned process doing -bs Date: Tue, 9 Jun 1998 20:43:44 +0200 (CEST) From: Karsten Petersen To: ggi-develop@eskimo.com Subject: Re: linux-2.1.103 config specials or 2.1.105 GGI patch ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"TGG6b.0.sR4.9-PVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2699 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 9 Jun 1998, Rodolphe Ortalo wrote: > I am currently trying to setup a running degas system, but I fall > against an unusual problem: I'm unable to compile a running 2.1.103 > kernel... :-( > There seems to be a problem with IDE disks or DMA for disk or smthing > like that. Is there a known bug to avoid on 2.1.103 systems ? I may > have an incorrect config. nope, 2.1.103 can't run on uniprocessor systems, there is a bug in the apic-init code iirc. > Thank you for any clarification, > > Rodolphe CU Karsten aka TI Visit my Homepage: http://www.tu-chemnitz.de/~kapet From ggi-develop-request@eskimo.com Tue Jun 9 14:04:54 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA00482; Tue, 9 Jun 1998 14:04:51 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA21288; Tue, 9 Jun 1998 13:59:35 -0700 Resent-Date: Tue, 9 Jun 1998 13:59:35 -0700 Date: Tue, 9 Jun 1998 16:39:15 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Snapshots Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cNdxG2.0.WC5.s8QVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2700 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com When will snapshots of the new CVS repositories start? We should at least stop the Dali snaps, so people do not pick up the old code and start working with it only to find it all changed around. (Though they should be able to figure out that a 36 byte diff between snaps probably means it's not the new code :) -- Brian S. Julin From ggi-develop-request@eskimo.com Tue Jun 9 15:17:44 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA00561; Tue, 9 Jun 1998 15:17:39 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA27524; Tue, 9 Jun 1998 15:15:49 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 15:15:49 -0700 (PDT) Date: Tue, 9 Jun 1998 15:46:16 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"_-bnu2.0.rj6.GGRVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2701 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 8 Jun 1998, Michael Krause wrote: > Other than that, I have a comment on the current libGGI discussion (I > hope I'm just misinterpreting things). I remember it's being said > that DirectBuffer use is deprecated. I must strongly object to this, "deprecated" is a strong word for it -- nobody is suggesting removing it. The stark cold reality is though that some targets just don't offer it and when it is used, it may require contortions on the part of the OS/backend when use is attempted in combination with certain other features. So its use is discouraged if cross-platform compatibility is the application's goals. I think it's safe to say too that we encourage cross-plaform compatible applications. And, it is essential. Face it, no one's going to recode every single app that gets ported to GGI to ween it from directbuffer. P.S. As far as GGIputs, I look at that as a debugging convenience function, not a serious part of libGGI. -- Brian S. Julin From ggi-develop-request@eskimo.com Tue Jun 9 15:34:31 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA00597; Tue, 9 Jun 1998 15:34:24 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA28799; Tue, 9 Jun 1998 15:22:47 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 15:22:47 -0700 (PDT) Message-Id: <199806092222.AAA23524@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 10 Jun 1998 00:17:06 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: Re: KGI license? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"kgwwl1.0.k17.oMRVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2702 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi, >"deprecated" is a strong word for it -- nobody is suggesting removing >it. The stark cold reality is though that some targets just don't >offer it and when it is used, it may require contortions on the >part of the OS/backend when use is attempted in combination with >certain other features. So its use is discouraged if cross-platform >compatibility is the application's goals. I think it's safe to say >too that we encourage cross-plaform compatible applications. Eh? DirectBuffer isn't even remotely deprecated, it is a very important feature of libggi, one of the most as far as I'm concerned. Sure it isn't supported by most targets, but so is 3D acceleration, and noone wants that removed. It's all a question of what you are using libggi for - if it's for a game, users can expect directbuffer to fly on KGI and have a reasonable speed on others. If it's a gui application, you're better off using X, or - hurry up guys :) - Berlin. Let's not second guess libggi application programmers - they are the only ones to know what they'll use our features for. -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 9 15:38:01 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA00606; Tue, 9 Jun 1998 15:37:57 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA02348; Tue, 9 Jun 1998 15:37:31 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 15:37:31 -0700 (PDT) Message-Id: <199806092237.AAA23573@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 10 Jun 1998 00:31:50 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: IRC meeting with Berlin next sunday Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"SVA8b.0.Qa.daRVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2705 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello my friends, The IRC session past sunday has been quite a success, thanks to everyone who attended it.. We have solved problems worth a week of ML traffic ;) I hope my html'ized version of the log didn't hurt your eyes too much :) Another IRC session will be held next sunday (14th) at the same time (3 PM GMT, which is 5 PM in Germany and Holland since you people are in GMT+2, just reminding that to a couple of persons who were early ;). Except that this time, we'll be meeting with developers of the Berlin Consortium - we have a lot to talk about; libggi2D and libgwt are two big chunks, but their expectation from us and vice-versa will fill some time too. Please be there :) -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 9 15:38:37 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA00611; Tue, 9 Jun 1998 15:38:35 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA01998; Tue, 9 Jun 1998 15:34:45 -0700 Resent-Date: Tue, 9 Jun 1998 15:34:45 -0700 Message-Id: <199806092211.AAA23507@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 10 Jun 1998 00:06:18 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: ggi-project.org successful move Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"LTDsl1.0._U.5YRVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2704 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello all, This isn't vital information, but I just thought I would keep you informed. The name servers of ggi-project.org have successfully changed, and the new record will be available for whois around 6 AM eastern tomorrow morning. The old nameservers are still up and running, so no disruption will happen. The new primary DNS is degas.ggi-project.org, the machine responsible for the CVS repository and email aliasing as well. It will probably handle some more free projects when I have the occasion (not going to become openprojects.net eh, just a facility that I am able to offer). Secondary DNS resolution is now ensured by Mathieu Guillaume (mat.cythere.com, France) of the GGI project, together with my friends J.S. Connell (ns.canuck.gen.nz - New Zealand, that has been a secondary for us since we got the domain name) and Bruce Ide (greyfox.org, USA) from the undernet #linux channel. I guess we should be real safe with DNS now ;) I just thought I'd mention those persons who took a minute of their time and some of their bandwidth to ensure we keep most of our services and coordination, in case I have a network outage. I'm done, you can wake up :) -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 9 15:39:22 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA00617; Tue, 9 Jun 1998 15:39:20 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA01953; Tue, 9 Jun 1998 15:34:37 -0700 Resent-Date: Tue, 9 Jun 1998 15:34:37 -0700 Message-Id: <199806092202.AAA23460@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 09 Jun 1998 23:56:33 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: Re: Snapshots In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"eHilA3.0.MU.yXRVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2703 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello Brian, I hope I didn't miss too many messages, I've been "unsubscribed" from the list twice in three days, something seems to be wrong at eskimo.. But we won't complain :) >When will snapshots of the new CVS repositories start? We should >at least stop the Dali snaps, so people do not pick up the >old code and start working with it only to find it all changed >around. (Though they should be able to figure out that a 36 byte >diff between snaps probably means it's not the new code :) I have e-mailed John Meacham, Willie Daniel and Todd T. Fries (who will host an anonymous CVS repository mirror in the USA, for your convenience) about snapshot generation; no sign of life yet, but the issue is being taken care of.. I believe it's just a matter of synergy* updating from the new repository.. (though a manual complete recheckout will be needed first). I'll post when it is setup somehow :) -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 9 15:46:07 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA00639; Tue, 9 Jun 1998 15:46:01 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA04040; Tue, 9 Jun 1998 15:45:12 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 15:45:12 -0700 (PDT) From: wlfshmn@ramses.ml.org Date: Wed, 10 Jun 1998 00:37:42 +0200 (CEST) To: ggi-develop@eskimo.com Subject: Re: MGA Impression Chipsets. In-Reply-To: <199806091040.DAA10653@mx2.eskimo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"OUuBk.0.e-.ihRVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2706 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 9 Jun 1998, Kendall Bennett wrote: > > > AFAIK from Matrox only Millennium I/II/AGP and Mytique are in the works. > > > > > > Is documentation for other chipsets available? > > > > > > Hartmut. > > > > This is a matter of definition, I have yet to aquire any kind of assitance > > from Matrox proper, I do have enough information on the IS-ATLAS to write > > working drivers, although not optimally accelerated and I have hopes that > > with such a driver in hand, It will show Matrox that they loose nothing > > from releasing the full specs. Abou the other cards, I have only about 40 > > lines of documentation (A diff more or less to the basic MGA engine) for > > the IS-DUBIC but I have no hardware to test this on, I plan on aquiring a > > few cheap Matrox boards after I get the IS-ATLAS driver to work properly. > > > > Luckily whith the MGA chipsets, they are all base on the same core. So > > alot of what has been written for the Mystique and milleniums, will also > > work on the older chipsets. > > Beware that if you intend to support the MGA-ATLAS and earlier chips > (ie: before the MGA-STORM used in the Millenium chips), that these > devices do not have *any* hardware linear framebuffer. The chips are > similar from the accelerator point of view to the MGA-STORM and > later, however the only direct framebuffer access is via a 7Kb > sliding window (yes, 7Kb, not 64Kb as you would expect!). Hence these > chips are a royal pain to implement support for. > > The one saving grace is that the framebuffer window start can be > aligned to a 4Kb address, and hence you can implement a virtualised > linear framebuffer (but I don't know if KGI is currently designed to > allow a 4Kb window instead of the regular 64Kb window that all other > chips use). > > We don't currently support those chips for this very reason (in > SciTech Display Doctor that is), although one day we might get around > to writing the support (we have all the specs and sample boards to > test with). > > Regards, > > Ok, Your advice is noted and I thank you for it, although, I still thing I will try to write the driver since honestly, I don't have anything else to do ;) and I think it will be a great way of learning more about GGI and programming in general, be it so that I might fail, atleast I'm one experience richer. Good luck with your own implementations of these card. Johan From ggi-develop-request@eskimo.com Tue Jun 9 16:16:19 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA00676; Tue, 9 Jun 1998 16:16:16 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA12129; Tue, 9 Jun 1998 16:22:33 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 16:22:33 -0700 (PDT) From: wlfshmn@ramses.ml.org Date: Wed, 10 Jun 1998 00:43:11 +0200 (CEST) To: ggi-develop@eskimo.com Subject: Re: linux-2.1.103 config specials or 2.1.105 GGI patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"VxzqR.0.Lz2.sESVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2707 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 9 Jun 1998, Rodolphe Ortalo wrote: > Hello, > > I am currently trying to setup a running degas system, but I fall > against an unusual problem: I'm unable to compile a running 2.1.103 > kernel... :-( > There seems to be a problem with IDE disks or DMA for disk or smthing > like that. Is there a known bug to avoid on 2.1.103 systems ? I may > have an incorrect config. > > However, with the same config, I have a running 2.1.105 kernel, therefore > my second question is: does someone plan to update the KGI patch for > 2.1.105 (the current 2.1.103 patch fails). I fear I don't have the > knowledge to do the patch myself (but I may try, I have the motivation > now :-). > > Thank you for any clarification, > > Rodolphe > > I have not tried the EvStacks patch, but with the older KIG patch for 2.1.103, it applied cleanly against 2.1.102, wich also works stably on my IDE system ( I have the same problems with 103) Johan From ggi-develop-request@eskimo.com Tue Jun 9 17:16:41 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA00802; Tue, 9 Jun 1998 17:16:39 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id RAA13917; Tue, 9 Jun 1998 17:17:24 -0700 Resent-Date: Tue, 9 Jun 1998 17:17:24 -0700 Message-ID: <19980609190555.38174@fries.net> Date: Tue, 9 Jun 1998 19:05:55 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: Snapshots References: <199806092202.AAA23460@orb.suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199806092202.AAA23460@orb.suntech.fr>; from Emmanuel Marty on Tue, Jun 09, 1998 at 11:56:33PM +0200 Resent-Message-ID: <"GliaA3.0.DP3.J2TVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2708 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, Jun 09, 1998 at 11:56:33PM +0200, Emmanuel Marty wrote: > I have e-mailed John Meacham, Willie Daniel and Todd T. Fries > (who will host an anonymous CVS repository mirror in the USA, > for your convenience) about snapshot generation; no sign of > life yet, but the issue is being taken care of.. I believe > it's just a matter of synergy* updating from the new > repository.. (though a manual complete recheckout will be needed > first). > > I'll post when it is setup somehow :) My repositories are setup! I announced it like Sunday or Monday, I forget which. Anway, I believe it would be in the project's best interest if I generated snapshots on my local machine and/or you on yours. Reason being that it will not be faster than on localhost :-) I think twice daily mirrors are in order, not just midnight. So I'll do a noon and midnight CDT (not EST as was mentioned on the list earlier). Let me know how things go, -- Todd Fries .. toddf@acm.org P.S. Incase you missed the announcement, the following env vars work: 1. CVSROOT=:pserver:anoncvs@anoncvs.us.ggi-project.org:/cvs - stable CVSROOT=:pserver:anoncvs@anoncvs.us.ggi-project.org:/cvsdevel - development and cvs login as anonvcs: 2. CVS_RSH=ssh and: CVSROOT=anoncvs@anoncvs.us.ggi-project.org:/cvs - stable CVSROOT=anoncvs@anoncvs.us.ggi-project.org:/cvsdevel - development From ggi-develop-request@eskimo.com Tue Jun 9 17:52:48 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA00823; Tue, 9 Jun 1998 17:52:17 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA01660; Tue, 9 Jun 1998 17:58:25 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 17:58:25 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: linux-2.1.103 config specials or 2.1.105 GGI patch ? Date: 10 Jun 1998 00:39:02 GMT Organization: OnTV Pittsburgh, L.P. Lines: 19 Sender: Jason McMullan Distribution: local Message-ID: <6lkkj6$o3g$1@butter.visus.com> References: <6lk4t0$hpi$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"mqpmR1.0.qP.leTVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2709 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Rodolphe Ortalo wrote with confidence: > However, with the same config, I have a running 2.1.105 kernel, therefore > my second question is: does someone plan to update the KGI patch for > 2.1.105 (the current 2.1.103 patch fails). I fear I don't have the > knowledge to do the patch myself (but I may try, I have the motivation > now :-). Yes, there are known bugs in the 2.1.103 implementation of IDE. I'm sucking down 2.1.105 as-we-speak to prepare the patch. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Tue Jun 9 19:03:01 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA00860; Tue, 9 Jun 1998 19:02:59 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA18658; Tue, 9 Jun 1998 19:09:21 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 19:09:21 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Licensing To: ggi-develop@eskimo.com (mailing list GGI) Date: Wed, 10 Jun 1998 00:47:43 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"9q-uz1.0.PZ4.FhUVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2710 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Thanks for all the responses. I am still collecting, but up to now, things seem to converge rather nicely on most points. I am in the process of making a preliminary license document from the answers that should be agreeable by all our developers. It will be something in between BSD and GPL ... I'll probably post tomorrow evening ... Just to keep you updated ... CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 9 21:05:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA00913; Tue, 9 Jun 1998 21:05:50 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA12231; Tue, 9 Jun 1998 21:05:45 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 21:05:45 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: degas.devel commits Date: 10 Jun 1998 04:04:16 GMT Organization: OnTV Pittsburgh, L.P. Lines: 15 Sender: Jason McMullan Message-ID: <6ll0k0$sqj$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"opufJ2.0.z-2.FOWVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2711 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Changes: * More KGI documentation * Changes to KGI to reflect said docs. * GGI Console patch for 2.1.105 -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Tue Jun 9 22:11:45 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA01112; Tue, 9 Jun 1998 22:11:43 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id WAA26076; Tue, 9 Jun 1998 22:13:51 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 22:13:51 -0700 (PDT) Sender: injector@clubneon.dyn.ml.org Message-ID: <357E1545.45EF372A@stu.ac.cc.md.us> Date: Wed, 10 Jun 1998 01:10:29 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Snapshots References: <199806092202.AAA23460@orb.suntech.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FhU8E2.0.FN6.BOXVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2712 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Emmanuel Marty wrote: > > I have e-mailed John Meacham, Willie Daniel and Todd T. Fries > (who will host an anonymous CVS repository mirror in the USA, > for your convenience) about snapshot generation; no sign of > life yet, but the issue is being taken care of.. I believe > it's just a matter of synergy* updating from the new > repository.. (though a manual complete recheckout will be needed > first). > > I'll post when it is setup somehow :) I just now took care of that. Only 1 little problem, the diff wasn't against dali (the diff probally would have been bigger than the full degas snapshot anyway) so I removed it so no one would be temped to try to use it. Tomorrow's diff will be proper agaist today's snapshot. -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Tue Jun 9 22:17:33 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA01117; Tue, 9 Jun 1998 22:17:31 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA23812; Tue, 9 Jun 1998 22:15:01 -0700 Resent-Date: Tue, 9 Jun 1998 22:15:01 -0700 Message-Id: <199806100517.HAA23814@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 10 Jun 1998 07:11:46 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: Re: Snapshots In-Reply-To: <357E1545.45EF372A@stu.ac.cc.md.us> References: <199806092202.AAA23460@orb.suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"1LzsL3.0.tp5.KPXVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2713 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >I just now took care of that. Only 1 little problem, the diff wasn't >against dali (the diff probally would have been bigger than the full degas >snapshot anyway) so I removed it so no one would be temped to try to use >it. Tomorrow's diff will be proper agaist today's snapshot. Ok, so the snapshots are available and you cvs update? Great! Where are you updating from? It would be nice if you updated from Todd's mirror, sometime after it updates from me every night, so that bandwidth remains to the developers.. :) -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 9 22:19:39 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA01129; Tue, 9 Jun 1998 22:19:37 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id WAA27555; Tue, 9 Jun 1998 22:21:43 -0700 (PDT) Resent-Date: Tue, 9 Jun 1998 22:21:43 -0700 (PDT) Message-Id: <199806100522.HAA23823@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 10 Jun 1998 07:16:26 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: Re: Snapshots In-Reply-To: <357E1545.45EF372A@stu.ac.cc.md.us> References: <199806092202.AAA23460@orb.suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"cgqf5.0.Jk6.WVXVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2714 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hmm, snapshots are generated from the 'stable' tree. Could you generate one against the 'devel' one too? I was wondering why the tarball was so small.. :) -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 9 22:42:10 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA01157; Tue, 9 Jun 1998 22:42:08 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA31962; Tue, 9 Jun 1998 22:39:35 -0700 Resent-Date: Tue, 9 Jun 1998 22:39:35 -0700 Sender: injector@clubneon.dyn.ml.org Message-ID: <357E1BCF.3BE8BDED@stu.ac.cc.md.us> Date: Wed, 10 Jun 1998 01:38:23 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Snapshots References: <199806092202.AAA23460@orb.suntech.fr> <199806100517.HAA23814@orb.suntech.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"zIRhl.0.Hp7.NmXVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2715 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Emmanuel Marty wrote: > > Ok, so the snapshots are available and you cvs update? Great! Yeah, I changed the script that was run by cron. > Where are you updating from? It would be nice if you updated from Todd's > mirror, sometime after it updates from me every night, so that bandwidth > remains to the developers.. :) Whoops, it is your site. I'll change that (after I hear back from you on this mail, cause I have a few more questions). [From your other post] > Hmm, snapshots are generated from the 'stable' tree. Could > you generate one against the 'devel' one too? I was wondering > why the tarball was so small.. :) Okay. I'll need to change the naming scheme of the tar and diffs, not a problem. My other questions: Should I wipe out the old Dali snapshots? and It looks like the snapshots just keep being generated and the old ones never removed. Should I be cleaning the old ones off at any point (easy to put that in the update script too)? -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Tue Jun 9 23:00:06 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA01187; Tue, 9 Jun 1998 23:00:05 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA01926; Tue, 9 Jun 1998 22:58:17 -0700 Resent-Date: Tue, 9 Jun 1998 22:58:17 -0700 Message-Id: <199806100600.IAA23869@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 10 Jun 1998 07:55:05 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: Re: Snapshots In-Reply-To: <357E1BCF.3BE8BDED@stu.ac.cc.md.us> References: <199806092202.AAA23460@orb.suntech.fr> <199806100517.HAA23814@orb.suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"FcpXi3.0.zT.u1YVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2716 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello again :) >Yeah, I changed the script that was run by cron. Great, good work. >Whoops, it is your site. I'll change that (after I hear back from you on >this mail, cause I have a few more questions). Ok - I seem to be the only one who missed the post from Todd, I've been thrown off the list 2 times, sob sob :) >My other questions: Should I wipe out the old Dali snapshots? and It >looks like the snapshots just keep being generated and the old ones never >removed. Should I be cleaning the old ones off at any point (easy to put >that in the update script too)? About the Dali snapshots, they are all identical anyway. IMHO, you should keep one (say, the latest, but they are all the same) as the "dali final snapshot" or so, and get rid of all others, diffs included. I suppose that keeping a month worth of snapshots on the site should be enough (and will make the removal command quite simple :).. Do as you wish.. :) -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 9 23:49:57 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA01223; Tue, 9 Jun 1998 23:49:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA16961; Tue, 9 Jun 1998 23:52:21 -0700 Resent-Date: Tue, 9 Jun 1998 23:52:21 -0700 From: Hartmut Niemann Message-Id: <199806100652.IAA21003@cip8.e-technik.uni-erlangen.de> Subject: Re: Snapshots To: ggi-develop@eskimo.com Date: Wed, 10 Jun 1998 08:52:05 +0200 (MESZ) In-Reply-To: <19980609190555.38174@fries.net> from "Todd T. Fries" at Jun 9, 98 07:05:55 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0p04Q1.0.p84.ZqYVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2717 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > My repositories are setup! I announced it like Sunday or Monday, I forget > which. Anway, I believe it would be in the project's best interest if I > generated snapshots on my local machine and/or you on yours. Reason being > that it will not be faster than on localhost :-) That means that the 20July1998 snapshot from Europe can be different from that in USA. I don't know whether that is good... > > I think twice daily mirrors are in order, not just midnight. So I'll do a > noon and midnight CDT (not EST as was mentioned on the list earlier). That gives a a 20Jul98a.tgz and a 20Jul98b.tgz. I don't like that either. Those who need the all-latest changes, should do an up-to-the-minute CVS update. Once a day should be perfect, and I would like it to be done late at night, so that the 20Jul tarball incorporates the changes done that day. So run 23.50 local time :-) And IMHO it could avoid confusion if the snapshots are absolutely identical in Europe and USA. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 10 01:02:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA01386; Wed, 10 Jun 1998 01:02:37 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA24913; Wed, 10 Jun 1998 00:58:48 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 00:58:48 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806100751.JAA22164@cip8.e-technik.uni-erlangen.de> Subject: Libggi error codes? To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Wed, 10 Jun 1998 09:51:25 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"zXQae1.0.856.roZVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2718 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Are there any libggi error codes defined? Or is it just -1=-EITDIDNTWORK? Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 10 01:32:24 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA01447; Wed, 10 Jun 1998 01:32:20 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA26755; Wed, 10 Jun 1998 01:09:54 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 01:09:54 -0700 (PDT) X-Sender: ortalo@poptsf.laas.fr Message-Id: In-Reply-To: <6ll0k0$sqj$1@butter.visus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro F3.1.3 Date: Wed, 10 Jun 1998 10:09:08 +0200 To: ggi-develop@eskimo.com From: Rodolphe Ortalo Subject: Re: degas.devel commits Resent-Message-ID: <"S33n3.0.uX6.FzZVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2719 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >Changes: > * More KGI documentation > * Changes to KGI to reflect said docs. > * GGI Console patch for 2.1.105 Very very nice job. (Who said the development cycle was slow ?!! ;-) I'l try to have a running degas w/ evstack this evening, and then I'll proceed towards making my hardware run (ie: Laguna board, and a SpaceOrb also). Do you still need to comment out "SMP=1" on 2.1.105 ? I guess not. Rodolphe From ggi-develop-request@eskimo.com Wed Jun 10 02:06:59 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA01547; Wed, 10 Jun 1998 02:06:57 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA02891; Wed, 10 Jun 1998 02:04:09 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 02:04:09 -0700 (PDT) Sender: injector@clubneon.dyn.ml.org Message-ID: <357E4B46.23FEF03A@stu.ac.cc.md.us> Date: Wed, 10 Jun 1998 05:00:54 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Snapshots References: <199806092202.AAA23460@orb.suntech.fr> <199806100517.HAA23814@orb.suntech.fr> <199806100600.IAA23869@orb.suntech.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_YUH32.0.2j.6maVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2720 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Emmanuel Marty wrote: > > Great, good work. You think that was great, you should see the stuff now. After a few hours of work the new snapshot system is in place on synergy (and I'm sure they are glad to see me log off, after the pounding I gave the network, cpu, and hard disk :) > Ok - I seem to be the only one who missed the post from Todd, I've been > thrown off the list 2 times, sob sob :) It uses Todd's server. Updating from it at midnight (I think). > About the Dali snapshots, they are all identical anyway. IMHO, you should > keep one (say, the latest, but they are all the same) as the "dali > final snapshot" or so, and get rid of all others, diffs included. ggi-dali-final.tar.gz is it then. > I suppose that keeping a month worth of snapshots on the site should > be enough (and will make the removal command quite simple :).. Do as > you wish.. :) 28 days of snapshots and diffs will be kept. They are in the form of: ggi-stable-(date).tar.gz ggi-stable-(date).diff.gz ggi-devel-(date).tar.gz ggi-devel-(date).diff.gz http://www.ggi-project.org/snapshot.html links to both stable and devel versions (diffs links will be broken for the next 22 hours until the next snapshot is taken). I think that's it. Time to sleep. P.S. Emmanuel get a hold of me about getting the web site into some sort of CVS so we can get the mirrors working. -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Wed Jun 10 03:23:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA01600; Wed, 10 Jun 1998 03:23:51 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA10099; Wed, 10 Jun 1998 03:13:15 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 03:13:15 -0700 (PDT) From: Andrew Apted Message-ID: <19980610200757.54229@ajax.netspace.net.au> Date: Wed, 10 Jun 1998 20:07:57 +1000 To: ggi-develop@eskimo.com Subject: Re: Libggi error codes? Reply-To: ggi-develop@eskimo.com References: <199806100751.JAA22164@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806100751.JAA22164@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Wed, Jun 10, 1998 at 09:51:25AM +0200 Resent-Message-ID: <"ds0201.0.hT2.vmbVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2721 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann writes: > Are there any libggi error codes defined? I don't think so. Perhaps we should stick to the standard errno values (-EINVAL, -ENOTSUP etc...) ? Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Wed Jun 10 05:27:45 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA01685; Wed, 10 Jun 1998 05:27:42 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA23349; Wed, 10 Jun 1998 05:00:38 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 05:00:38 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806101153.NAA27775@cip8.e-technik.uni-erlangen.de> Subject: namespace rules To: becka@sunserver1.rz.uni-duesseldorf.de (Andreas Beck), jmcc@cip8.e-technik.uni-erlangen.de, ggi-develop@eskimo.com (ggi Mailingliste) Date: Wed, 10 Jun 1998 13:53:12 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"B8stV.0.hi5.aLdVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2722 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! I am about to start moving documentation from the chemnitz tree to degas. I transferrend RESERVED_WORDS long ago to namespace.sgml. Now the question: I am going to drom the RESERVED_WORDS file entirely in favour of the almost identival namespace.txt generated from namespace.sgml. OK? There are some 'issues' mentioned, most notably using the Objective C keyword 'id', the word 'new', 'private', 'virtual' and 'bool'. Are these issues already resolved? While we are at redoing so much, we might as well clean that up too. I'll put the namespace.sgml into the devel tree anyway. Please send me comments. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 10 05:55:37 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA01694; Wed, 10 Jun 1998 05:55:34 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA29618; Wed, 10 Jun 1998 05:37:56 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 05:37:56 -0700 (PDT) Message-Id: <199806101238.OAA25108@orb.suntech.fr> X-Sender: core@mail.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 10 Jun 1998 14:34:19 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: Re: namespace rules In-Reply-To: <199806101153.NAA27775@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"i8PDq2.0.fE7.YudVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2723 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >Now the question: I am going to drom the RESERVED_WORDS file entirely >in favour of the almost identival namespace.txt generated from >namespace.sgml. OK? Makes sense. IIRC, this document also lists the problems I had when porting to non-gnu compilers (ie. SGI) ; maybe this should be moved somewhere else? -- Emmanuel From ggi-develop-request@eskimo.com Wed Jun 10 06:14:17 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA01712; Wed, 10 Jun 1998 06:14:01 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA10847; Wed, 10 Jun 1998 06:12:48 -0700 Resent-Date: Wed, 10 Jun 1998 06:12:48 -0700 Date: Wed, 10 Jun 1998 15:12:23 +0200 (DFT) From: Massimiliano Ghilardi To: ggi-develop@eskimo.com Subject: Re: linux-2.1.103 config specials or 2.1.105 GGI patch ? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"oHLfp1.0.If2.FPeVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2724 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 9 Jun 1998, Karsten Petersen wrote: > nope, 2.1.103 can't run on uniprocessor systems, there is a bug in the > apic-init code iirc. This is getting off topic, but I _have_ a 2.1.103 running on a uniprocessor system. I just commented out SMP=1 in tha Makefile and everything went smooth. But it may be because I have an ancient 486 without IDE DMA... Max From ggi-develop-request@eskimo.com Wed Jun 10 06:23:31 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA01717; Wed, 10 Jun 1998 06:23:30 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA12757; Wed, 10 Jun 1998 06:23:31 -0700 Resent-Date: Wed, 10 Jun 1998 06:23:31 -0700 From: Hartmut Niemann Message-Id: <199806101322.PAA29615@cip8.e-technik.uni-erlangen.de> Subject: please remove README.INSTALL To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Wed, 10 Jun 1998 15:22:34 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"LoWdu1.0.D73.IZeVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2725 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com degas/README.INSTALL is obsoleted by degas/doc/install.txt (degas/doc/sgml/install.sgml). If you made changes to this README recently, please tell me; if you didn't and install.txt is still 'current', then could you (i.e. the one who put it there) remove it? I don't want to force my will on you (else I would remove it), but IMHO the doc/install is the more natural place, and README.INSTALL should point the reader only to the sgml file and it's children. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 10 07:15:17 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA01777; Wed, 10 Jun 1998 07:15:16 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA19617; Wed, 10 Jun 1998 07:14:28 -0700 Resent-Date: Wed, 10 Jun 1998 07:14:28 -0700 From: Andrew Apted Message-ID: <19980610223714.08422@ajax.netspace.net.au> Date: Wed, 10 Jun 1998 22:37:14 +1000 To: ggi-develop@eskimo.com Subject: Re: IRC summary (final) Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Steve Cheng on Mon, Jun 08, 1998 at 05:45:07PM -0400 Resent-Message-ID: <"WP5Tc3.0.Po4.3JfVr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2726 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > 1) Multiple buffering > ===================== > > Multi-buffered modes will be done by setting the "frames" member of the > ggi_mode struct and passing that to ggiSetMode(). > > Two manipulte buffers, use: > * SetDisplayedFrame() > * SetDrawingFrame() Just some further thoughts on this. Someone noted that copying _between_ frames is necessary, so here is what I propose : ggiSetDrawingFrames(ggi_visual_t vis, int src_frame, int dest_frame); The source frame is where ggiGetPixel() etc. get their data, and the destination frame is where ggiPutPixel() etc. put their data. It follows from this that ggiCopyBox() and ggiCrossBlit() will always do the right thing. Agreed ? Also, should each frame have it's own DirectBuffer entry ? If not, we need some info on how the frames are arranged in the buffer (e.g. "frame_stride" -- but is that sufficient ?). Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Wed Jun 10 07:40:15 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA01812; Wed, 10 Jun 1998 07:40:14 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA20911; Wed, 10 Jun 1998 07:22:43 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 07:22:43 -0700 (PDT) Date: Wed, 10 Jun 1998 10:25:06 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: Libggi error codes? In-Reply-To: <199806101419.KAA03565@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"_r_nS1.0.Z65.mQfVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2728 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 10 Jun 1998, Andrew Apted wrote: > Hartmut Niemann writes: > > > Are there any libggi error codes defined? > > I don't think so. Perhaps we should stick to the standard errno values > (-EINVAL, -ENOTSUP etc...) ? That'd be useful where practical. Maybe use negative return values for the standard error codes, and positive return values for a few 'custom' error codes as we need them, since standard errno values don't _quite_ cover everything? -=MenTaLguY=- From ggi-develop-request@eskimo.com Wed Jun 10 07:42:05 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA01822; Wed, 10 Jun 1998 07:42:03 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA20400; Wed, 10 Jun 1998 07:19:53 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 07:19:53 -0700 (PDT) From: Andrew Apted Message-ID: <19980611001437.63328@ajax.netspace.net.au> Date: Thu, 11 Jun 1998 00:14:37 +1000 To: ggi-develop@eskimo.com Subject: The "Niggly Args" problem solved Reply-To: ggi-develop@eskimo.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 Resent-Message-ID: <"12ME42.0.b-4.4OfVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2727 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! This is a problem that's been bugging me for ages. Many display targets have a couple of little options that could (optionally) be specified in the target string. The question is how to specify these options in a *nice* way, and remain optional, while not being confused with the main arguments (such as "/dev/fb0" in "fbdev:/dev/fb0"). Example 1: somehow tell the X target to use the "relmouse" feature on startup. Example 2: somehow tell the trueemu target how much dithering to use, and the depth of the parent. Example 3: somehow tell the fbdev target the mouse type and things like DTR and RTS. Here's what I intend to do (for trueemu, monotext and fbdev at least). Options are located at the very front of the display target's argument string, and are just words beginning with '-' (like program options), possibly with value. Multible options are allowed (separated by whitespace or ':'). Options can be abbreviated (right down to a letter). Examples (with and without options) : display-X display-X:-relmouse display-Xlib:-r::1 trueemu:X trueemu:-dither 4 -parent 8:(display-X:-relmouse) fbdev:/dev/fb0 fbdev:-mousetype mousesys -dtr 0:/dev/fb1 monotext:KGI monotext:-accuracy 4:(fbdev:-m mousesys -d 0:/dev/fb1) Comments ? Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Wed Jun 10 08:26:19 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA01873; Wed, 10 Jun 1998 08:26:16 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA01398; Wed, 10 Jun 1998 08:18:21 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 08:18:21 -0700 (PDT) Sender: torgeir@eskimo.com Message-ID: <357EB9B9.64D85E54@vertech.no> Date: Wed, 10 Jun 1998 16:52:09 +0000 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.101 i686) MIME-Version: 1.0 To: Linux GGI Subject: [admin] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"rftCz3.0.iL.wEgVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2729 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com When posting to this list I frequently see a delay of about 24 hours before delivery. Would it be possible to ask why the software in use is so slow? I have experience with qmail in combination with ezmlm, and it performs much better on heavily loaded servers. -- Torgeir Veimo, Vertech AS, email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 From ggi-develop-request@eskimo.com Wed Jun 10 09:27:54 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA01929; Wed, 10 Jun 1998 09:27:46 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA02914; Wed, 10 Jun 1998 09:20:59 -0700 Resent-Date: Wed, 10 Jun 1998 09:20:59 -0700 Date: Wed, 10 Jun 1998 18:20:34 +0200 Message-Id: <199806101620.SAA05674@mat.cythere.com> From: Mathieu Guillaume Subject: Includes problem in libggi Resent-Message-ID: <"ErFzD1.0.Nj.g9hVr"@mx1> To: ggi-develop@eskimo.com Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2730 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi, I may be mistaken, but it seems one has to install KGI to get libggi to compile. Indeed, the compilation process relies on two symlinks: /usr/include/ggi -> $(KERNELSRC)/include/ggi $(KERNELSRC)/include/ggi -> $(INSTALL_ROOT)$(INCLUDE)/ggi The configure program in the main directory only verifies that the first symlink exists. If one doesn't install KGI, the second symlink does not exist, so the required includes are not found. Myself, I'd add a -L../../include in the libggi dir, but of course you can do what you like :) Mat From ggi-develop-request@eskimo.com Wed Jun 10 10:20:19 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA01968; Wed, 10 Jun 1998 10:20:16 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA24533; Wed, 10 Jun 1998 10:19:49 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 10:19:49 -0700 (PDT) Message-ID: <19980610182824.A433@bengburken.dyn.ml.org> Date: Wed, 10 Jun 1998 18:28:24 +0200 From: =?iso-8859-1?Q?Jonas_Borgstr=F6m?= To: ggi-develop@eskimo.com Subject: divide error: 0000 Reply-To: jonas_b@bitsmart.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.91.1 Resent-Message-ID: <"uhdMu3.0.C_5.o0iVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2731 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all, I have just tested the vga driver in degas. Because I have a Matrox Millennium card I can't use the monosync monitor driver (nonstandard boot mode), I need to use a multisync driver instead. After I changed a "/ggi/kgi.h" to "/kgi/kgi.h" it compiled fine. But when I insmoded the module I got this error: Jun 10 18:12:07 bengburken kernel: IBM VGA chipset driver rev $Revision: 1.3 $ Jun 10 18:12:07 bengburken kernel: VGA DAC driver rev. $Revision: 1.3 $ Jun 10 18:12:07 bengburken kernel: VGA clock driver rev $Revision: 1.1 $, common code:$Revision: 1.3 $ Jun 10 18:12:07 bengburken kernel: VGA Graphics Driver loaded Jun 10 18:12:07 bengburken kernel: divide error: 0000 Jun 10 18:12:07 bengburken kernel: CPU: 0 Jun 10 18:12:07 bengburken kernel: EIP: 0010:[] Jun 10 18:12:07 bengburken kernel: EFLAGS: 00010282 Jun 10 18:12:07 bengburken kernel: eax: 00000000 ebx: c2c0be80 ecx: 00000000 edx: 00000000 Jun 10 18:12:07 bengburken kernel: esi: 00000009 edi: c2c0beec ebp: c4856308 esp: c2c0be1c Jun 10 18:12:07 bengburken kernel: ds: 0018 es: 0018 ss: 0018 Jun 10 18:12:07 bengburken kernel: Process insmod (pid: 355, process nr: 18, stackpage=c2c0b000) Jun 10 18:12:07 bengburken kernel: Stack: c2c0be80 00000009 c2c0beec c4856308 c01e96c4 c00b8fa0 00000001 c485128b Jun 10 18:12:07 bengburken kernel: c4856308 c2c0be80 c2c0be68 c4856308 c2c0be80 c2c0be9c ffffffea c2c0be68 Jun 10 18:12:07 bengburken kernel: c01a6a98 c4856308 c2c0be80 00000000 00000000 c4856308 00000001 ffffffea Jun 10 18:12:07 bengburken kernel: Call Trace: [] [] [] [] [] [] [] Jun 10 18:12:07 bengburken kernel: [] [] [] [] [] [] [] [] Jun 10 18:12:07 bengburken kernel: [] [] [] [] [] [] [] [] Jun 10 18:12:07 bengburken kernel: [] [] [] Jun 10 18:12:07 bengburken kernel: Code: f7 7b 4c 89 c7 eb 0e 89 f6 8d bc 27 00 00 00 00 bf ff ff ff I Have kernel version 2.1.105. And for some reson insmod -m doesn't work so I don't know where it crashed. So does anyone have any idea what I should do? -- -------------------------------------- Jonas Borgström From ggi-develop-request@eskimo.com Wed Jun 10 14:28:28 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA02209; Wed, 10 Jun 1998 14:28:22 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA13587; Wed, 10 Jun 1998 14:27:01 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 14:27:01 -0700 (PDT) Date: Wed, 10 Jun 1998 17:24:37 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: IRC summary (final) In-Reply-To: <19980610223714.08422@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"qC0qi1.0.6K3.WelVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2733 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 10 Jun 1998, Andrew Apted wrote: > Just some further thoughts on this. Someone noted that copying _between_ > frames is necessary, so here is what I propose : > > ggiSetDrawingFrames(ggi_visual_t vis, int src_frame, int dest_frame); Yes we need this. Of course, adding ggiSetGetFrame and ggiSetPutFrame in place of ggiSetDraw* would be my preference as it keeps all the functions with the same prototype, but I don't care strongly. > Also, should each frame have it's own DirectBuffer entry ? > If not, we need some info on how the frames are arranged in the buffer > (e.g. "frame_stride" -- but is that sufficient ?). I thought the whole reason for setframe calls was to resolve this -- after a setframe call the two pointers in the db struct should point to the start of the read and write frames. -- Brian S. Julin From ggi-develop-request@eskimo.com Wed Jun 10 14:34:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA02218; Wed, 10 Jun 1998 14:34:47 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA13017; Wed, 10 Jun 1998 14:23:49 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 14:23:49 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: divide error: 0000 Date: 10 Jun 1998 21:22:36 GMT Organization: OnTV Pittsburgh, L.P. Lines: 33 Sender: Jason McMullan Distribution: local Message-ID: <6lmtes$knu$1@butter.visus.com> References: <6lmft8$fhu$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"jjLZr3.0.CB3.YblVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2732 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jonas Borgström wrote with confidence: > Hi all, > I have just tested the vga driver in degas. Because I have a Matrox > Millennium card I can't use the monosync monitor driver (nonstandard boot > mode), I need to use a multisync driver instead. After I changed a > "/ggi/kgi.h" to "/kgi/kgi.h" it compiled fine. > But when I insmoded the module I got this error: > Jun 10 18:12:07 bengburken kernel: IBM VGA chipset driver rev $Revision: 1.3 $ > Jun 10 18:12:07 bengburken kernel: VGA DAC driver rev. $Revision: 1.3 $ > Jun 10 18:12:07 bengburken kernel: VGA clock driver rev $Revision: 1.1 $, common code:$Revision: 1.3 $ > Jun 10 18:12:07 bengburken kernel: VGA Graphics Driver loaded > Jun 10 18:12:07 bengburken kernel: divide error: 0000 > And for some reson insmod -m doesn't work so I don't know where it crashed. > So does anyone have any idea what I should do? I'm working on it - there seems to be a bug in the clock module's check_mode().... -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Wed Jun 10 16:53:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA02300; Wed, 10 Jun 1998 16:53:28 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA10979; Wed, 10 Jun 1998 16:53:40 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 16:53:40 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: GGI License ... proposal ... To: ggi-develop@eskimo.com (mailing list GGI) Date: Thu, 11 Jun 1998 01:41:55 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"ETt1V2.0.Qh2.2onVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2734 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi folks ! Here are the results from my little poll: Total votes received: 12. A. PD parts: A1. Should there be parts, that are marked as public domain (like stubs for creating new drivers and such) ? A1: Votes Y: 11 N: 1 A: - Conclusion : We should mark some parts as being public domain. This should apply to all "sample implementations", core API #includes and core API-docs. A2. Should more than just "sample code" be PD ? A2: Votes Y: 3 N: 9 A: - >From the "Y" votes, most suggested some additional things to be PD like API specifications. As this is how it was meant anyway, see A1 for decision. B. Giving credits: B1. Should redistribution of any GGI code (except such explicitly marked PD) require giving credits to the original authors ? B2. Should "give credits" mean "display them on screen" ? B3. Would it be enough to require to redistribute the text of the license and a list of contributors ? B1: Votes Y: 12 N: - A: - B2: Votes Y: - N: 12 A: - B3: Votes Y: 11 N: 1 A: - We all agree, that we should require credits, but not flashing them over the screen. It is considered to be enough to include the license and the contributor list in the package. We should make sure it isn't in some obscure place, but force it to be as accessible as the packages own copyright notices. C. Source availability: C1. Should the license force redistribution of source for any modification you make to any part of GGI ? C1: Votes Y: 7 N: 3 A: 2 Funnily most people seem to want to force redistribution of modified sources, though this strongly reduces licensing possibilities ... I suggest to limit this to parts that are covered by GPL instead of _any_ part. C2. Should certain parts of LibGGI use GPL ? Which [ ] LibGGI [ ] Extensions [ ] KGI drivers [ ] Linux KGI->OS-interface C2: Votes L: 6 E: 4 I: 6 Looks like LibGGI and maybe some of our extension Libs should be LGPL. The KGI->Linux interface should be GPL. C3. Should we enforce having to give a pointer to the free source the work was derived from ? C3: Votes Y: 11 N: 1 A: - Most agree, that giving credits should include giving a pointer to the free sources of the project. D. Linking: D1. Should programs that are dynamically linked to some part of GGI have any restrictions applied ? Which ? [ ] give credits [ ] release source D1: Votes C: 4 N: 8 All agree, that forcing "release-source" is not reasonable. Most people seem to agree, that giving credits for a dynamically linked program isn't really needed (some comments from the 'N' votes pointed that way, too), because the credits are already present in the installed GGI part. D2. Should programs that are statically linked to some part of GGI have any restrictions applied ? Which ? [ ] give credits [ ] release source [ ] allow relinking D2: Votes C: 4 S: 1 R: 4 [question unclear !] The question was not formulated right in my first message, so the answers are not 100% accurate, though those that have correctly guessed "statically", have usually voted for "give credits". D3. Should static linking be considered "redistribution" ? D3: Votes Y: 8 N: 2 A: 2 Most of us agree, that linking statically could be called redistribution, so the credits rules etc. apply. E. Availability/Cross platform things: E1. Do you want KGI drivers to be useable on any platform ? E1: Votes Y: 9 N: 2 A: 1 Most of us want to have KGI drivers running on any platform. Thus the drivers themselves need to be put under a very free license, where possible. E2. Shall we allow KGI drivers which are under a license that disallows their use on some platforms due to license incompatibilities ? E2: Votes Y: 9 N: 3 A: - Having less free drivers in some cases doesn't seem to pose a problem. E3. As linking non-GPL code with GPL code is said to be impossible, would you accept Linux not being able to incorporate KGI drivers in the kernel itself (module will be o.k.) ? E3: Votes Y: 9 N: 3 A: - It seems o.k. to most, that it might be impossible to link in some drivers into the Linux kernel, if their license conflicts with the Linux kernel. ------------------------------------ O.K. - I tried to make a suitable license for our stuff from that information. It turned out, that it actually only deals with redistribution and protects very basic things like getting credit and keeping pointers to freely available sources, without hindering commercial application. Many parts of GGI should be protected sufficiently by this license, while others might want to use additional licenses. I tried to make the GGI license in a way that does not hinder combination with other licenses. Let me know what you think (in PM at best, to avoid flamewars) ... CU, Andy Bottom line - suggested GGI license: ------------------------------------ The software contained in this package is subject to the license described in this document, except where explicitly stated otherwise in the sources or a file called "LICENSE" or "LICENSE.filename_to_which_it_applies" in the appropriate directory. I. WARRANTY As software under the GGI license can be maintained and altered by anyone who wishes to do so, there is no warranty. In case this software is used to produce a commercial program, the supplier of that program can at his option choose to provide a warranty that will override the regulations below, but only with respect to that particular supplier. 1. The copyright holder(s) make no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. 2. THE COPYRIGHT HOLDER(S) DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. II. Redistribution Redistributing code that is under the GGI license is allowed, as long as the following conditions are met: 1. This file, describing the GGI license and a list of contributors (which should be found in a file called "CREDITS" in the same directory this file resides in) has to be included in the redistribution. 2. Said files have to be placed "at the same place and in the same print" as the copyright regulations of the redistribution. That is : You cannot hide it in some obscure place. 3. The CREDITS file shall contain a pointer to a free distribution of the redistributed code. You may add pointers for sources of your own _below_ the existing list, as long as you state they were added by you and the sources can be freely distributed "as is" (i.e. have no "NODIST" file as described in 5.). 4. If you do not redistribute "as is", but add your own code, modify or remove existing code or otherwise alter the package, you have to state this explicitly in the CREDITS file. 5. To avoid accidental licensing violations from redistributing a package that contains this license, but also other contributions that fall under other licenses or have additional licenses attached, that might eventually hinder "as is"-redistribution, a file called "NODIST" shall be present in any such distribution that cleanly lists all parts of the distribution that cannot be redistributed "as is" within the constrains of this license. Commentary: "Redistribution" includes giving out copies of the covered documents in source or binary form, as part of another document or binary (e.g. by statically linking it in) or any other form. Note, that you can make a modified version of the code covered by this license and distribute it with an additional license as long as the restrictions set up by this license are kept intact and eventual additional licenses that the code in question is under allow it. That is, you can make a binary-only, non-redistributable version of a GGI licensed package, as long as you keep "LICENSE" and "CREDITS", state what you altered and add all files to "NODIST". III. Advertising Names of authors in the CREDITS file, the term "ggi-project" as well as the GGI project logo may not be used to promote a particular package or product, except if you have written permission to do so. Permission can be granted by the individual developers for their respective names, and by the current project leaders of the ggi project for the term "ggi-project" and the logo. The current leaders can be derived from the "Who's who" on the GGI project homepage http://www.ggi-project.org/. IV. Common compatible licenses The GGI license is not very restrictive, what allows to release software under a license, that is a combination of the GGI license and some other license. The implications of doing so will be discussed for a few common licenses that might be used in that context. 1. GPL GPL license enforces redistribution of source code. If a program that is subject to the GGI license is also put under GPL, this means, that you _cannot_ make binary releases anymore without also providing (at least a pointer to) the source. 2. BSDL BSD licensing should be fully compatible with the GGI license. In case the "give credits on screen" rule is in effect, this has to be fulfilled, too. 3. PD PD usually means giving up copyright, which does not allow any other license to be placed on the code. Thus putting a file under PD effectively overrides the GGI license. They should not be used together. 4. Commercial licensing Commercial licenses usually contain one or more of the following regulations: 4.1. Give out binary-only packages. This is o.k. as long as the pointer to the free source the package was derived from is maintained and additional restrictions from other licenses (like making source available for GPLed parts) are observed. 4.2. deny redistribution of the product. The same applies here. Redistribution cannot be denied for GPLed parts. ------------------------------------ -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 10 17:33:13 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA02355; Wed, 10 Jun 1998 17:33:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA17751; Wed, 10 Jun 1998 17:32:58 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 17:32:58 -0700 (PDT) Date: Wed, 10 Jun 1998 20:25:41 -0400 (EDT) From: Steve Cheng Sender: steve@maxt9m47.ipoline.com To: andreas.beck@ggi-project.org cc: GGI Mailing List Subject: Re: GGI License ... proposal ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"90Lcr2.0.FL4.uMoVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2735 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Sorry I don't have enough time to respond to the poll, but I have one comment anyway: On Thu, 11 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > E3. As linking non-GPL code with GPL code is said to be impossible, > would you accept Linux not being able to incorporate KGI drivers > in the kernel itself (module will be o.k.) ? > > E3: Votes Y: 9 N: 3 A: - > > It seems o.k. to most, that it might be impossible to link in some drivers > into the Linux kernel, if their license conflicts with the Linux kernel. Question: The X license allows the code to be "sublicensed". Does this mean that it can be sublicensed as GPL, therefore it is able to link into other GPL code? I don't want to see Yet Another License, possibly with loopholes in it. If the above is possible (crossing my fingers), just add the credits requirement to the X one. -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Wed Jun 10 19:00:48 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA02386; Wed, 10 Jun 1998 19:00:45 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA13822; Wed, 10 Jun 1998 19:05:13 -0700 Resent-Date: Wed, 10 Jun 1998 19:05:13 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: namespace rules To: ggi-develop@eskimo.com Date: Thu, 11 Jun 1998 01:53:30 +0200 (MET DST) In-Reply-To: <199806101153.NAA27775@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at Jun 10, 98 01:53:12 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"uicY8.0.oN3.OjpVr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2737 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I transferrend RESERVED_WORDS long ago to namespace.sgml. > > Now the question: I am going to drom the RESERVED_WORDS file entirely > in favour of the almost identival namespace.txt generated from > namespace.sgml. OK? Yes. > There are some 'issues' mentioned, most notably using the Objective C > keyword 'id', the word 'new', 'private', 'virtual' and 'bool'. > Are these issues already resolved? not perfectly. Virtual should be out. If someone would grep and fix for the rest, I'd be grateful ... CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 10 19:00:56 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA02391; Wed, 10 Jun 1998 19:00:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA13839; Wed, 10 Jun 1998 19:05:14 -0700 Resent-Date: Wed, 10 Jun 1998 19:05:14 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: please remove README.INSTALL To: ggi-develop@eskimo.com Date: Thu, 11 Jun 1998 01:55:19 +0200 (MET DST) In-Reply-To: <199806101322.PAA29615@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at Jun 10, 98 03:22:34 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"H0jd11.0.2O3.PjpVr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2738 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > degas/README.INSTALL > is obsoleted by degas/doc/install.txt (degas/doc/sgml/install.sgml). > > If you made changes to this README recently, please tell me; Yes. I did some minor changes. Please check against the Chemnitz tree. > I don't want to force my will on you (else I would remove it), but > IMHO the doc/install is the more natural place, and README.INSTALL > should point the reader only to the sgml file and it's children. However it will force one to get the doc subtree to install the things ... CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 10 19:01:04 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA02398; Wed, 10 Jun 1998 19:01:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA13745; Wed, 10 Jun 1998 19:04:39 -0700 Resent-Date: Wed, 10 Jun 1998 19:04:39 -0700 From: Andrew Apted Message-ID: <19980611120041.45036@ajax.netspace.net.au> Date: Thu, 11 Jun 1998 12:00:41 +1000 To: ggi-develop@eskimo.com Subject: Re: Includes problem in libggi Reply-To: ggi-develop@eskimo.com References: <199806101620.SAA05674@mat.cythere.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806101620.SAA05674@mat.cythere.com>; from Mathieu Guillaume on Wed, Jun 10, 1998 at 06:20:34PM +0200 Resent-Message-ID: <"XMDOa.0.dM3.sipVr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2736 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Mathieu Guillaume writes: > I may be mistaken, but it seems one has to install KGI to get libggi to > compile. > Indeed, the compilation process relies on two symlinks: > /usr/include/ggi -> $(KERNELSRC)/include/ggi > $(KERNELSRC)/include/ggi -> $(INSTALL_ROOT)$(INCLUDE)/ggi Yes, that's true and we should fix this so that people who only want to use LibGGI don't need *any* kernel sources around. I think it's time that /usr/include/ggi stops being a symlink and is populated directly. Agreed ? Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Wed Jun 10 19:30:36 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA02409; Wed, 10 Jun 1998 19:30:19 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA11056; Wed, 10 Jun 1998 19:35:33 -0700 (PDT) Resent-Date: Wed, 10 Jun 1998 19:35:33 -0700 (PDT) X-Authentication-Warning: yohko.sense.net: ghall owned process doing -bs Date: Wed, 10 Jun 1998 22:27:38 -0400 (EDT) From: giles francis hall X-Sender: ghall@yohko.sense.net To: ggi-develop@eskimo.com Subject: Where Are The Drivers?! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"2IJsU3.0.ci2.o9qVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2739 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com wtf? the drivers are missing: [ghall@host driver]$ pwd /home/ghall/code/degas/kgi/driver [ghall@host driver]$ cd chipset/ [ghall@host chipset]$ ls CVS/ Hercules/ IBM/ Makefile [ghall@host ramdac]$ ls CONTRIB CVS/ IBM/ Makefile none/ [ghall@host graphic]$ ls CONTRIB CVS/ IBM/ Makefile generic/ i remember when there used to be an s3 directory and a matrox directory and some other drivers --> what up? where did they run off to? From ggi-develop-request@eskimo.com Thu Jun 11 01:13:12 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA02725; Thu, 11 Jun 1998 01:13:06 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA10806; Thu, 11 Jun 1998 01:15:30 -0700 Resent-Date: Thu, 11 Jun 1998 01:15:30 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <357F921A.1F72E406@e.kth.se> Date: Thu, 11 Jun 1998 10:15:22 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Where Are The Drivers?! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FBozU1.0.ke2.Y8vVr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2740 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com giles francis hall wrote: > > wtf? the drivers are missing: [snip] > i remember when there used to be an s3 directory and a matrox directory and > some other drivers --> what up? where did they run off to? They haven't been ported to the GGI Console (former EvStack) yet. //Marcus From ggi-develop-request@eskimo.com Thu Jun 11 03:47:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA02876; Thu, 11 Jun 1998 03:47:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA28071; Thu, 11 Jun 1998 03:42:57 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 03:42:57 -0700 (PDT) X-Sender: ortalo@poptsf.laas.fr Message-Id: In-Reply-To: <6lmtes$knu$1@butter.visus.com> References: <6lmft8$fhu$1@butter.visus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro F3.1.3 Date: Thu, 11 Jun 1998 12:42:51 +0200 To: ggi-develop@eskimo.com From: Rodolphe Ortalo Subject: Re: divide error: 0000 Resent-Message-ID: <"q-g0T.0.Vs6.jIxVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2741 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > [Jason wrote:] > I'm working on it - there seems to be a bug in the clock module's >check_mode().... Speaking of clocks: I saw that the programmable clock driver has not yet appeared in degas (subdir prog/). I was using the "pll" stubs written by Steffen Seeger (which was very very convenient for programmable clocks: it took me only 1 hour to have a programmable clock driver last year). Does someone intend to adapt this stub to degas (Steffen?) or should I try to do it when I need it ? Rodolphe PS: I now have a running Linux/KGI-2.1.105 kernel !!!! Yeah. (The cursor is brown now... ;-) From ggi-develop-request@eskimo.com Thu Jun 11 04:06:00 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA02886; Thu, 11 Jun 1998 04:05:58 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA01093; Thu, 11 Jun 1998 04:04:43 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 04:04:43 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: IRC summary (final) To: ggi-develop@eskimo.com Date: Thu, 11 Jun 1998 12:39:47 +0200 (MET DST) In-Reply-To: <19980610223714.08422@ajax.netspace.net.au> from "Andrew Apted" at Jun 10, 98 10:37:14 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"iem2F2.0.vG.9dxVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2742 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Also, should each frame have it's own DirectBuffer entry ? Yes. CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Thu Jun 11 04:09:03 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA02892; Thu, 11 Jun 1998 04:09:02 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA01159; Thu, 11 Jun 1998 04:04:59 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 04:04:59 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Includes problem in libggi To: ggi-develop@eskimo.com Date: Thu, 11 Jun 1998 12:41:44 +0200 (MET DST) In-Reply-To: <199806101620.SAA05674@mat.cythere.com> from "Mathieu Guillaume" at Jun 10, 98 06:20:34 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"4vT6n1.0.uH.MdxVr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2743 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I may be mistaken, but it seems one has to install KGI to get libggi to > compile. > Indeed, the compilation process relies on two symlinks: > /usr/include/ggi -> $(KERNELSRC)/include/ggi > $(KERNELSRC)/include/ggi -> $(INSTALL_ROOT)$(INCLUDE)/ggi What ? LibGGI should compile "in situ" without anything else being linked or copied ... > The configure program in the main directory only verifies that the first > symlink exists. If one doesn't install KGI, the second symlink does not > exist, so the required includes are not found. > Myself, I'd add a -L../../include in the libggi dir, but of course you > can do what you like :) I'll check that. CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Thu Jun 11 04:24:59 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA02927; Thu, 11 Jun 1998 04:24:52 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA06031; Thu, 11 Jun 1998 04:28:29 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 04:28:29 -0700 (PDT) X-Sender: zboszor@mol.hu X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ggi-develop@eskimo.com From: Boszormenyi Zoltan Subject: missing rights, kernel Oops Message-Id: <98Jun11.133417gmt+0100.17933@fw.mol.hu> Date: Thu, 11 Jun 1998 13:34:16 +0100 Resent-Message-ID: <"og9aX1.0.7U1.RzxVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2745 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I tried the ggi-devel-980610 snapshot on a clean 2.1.105 kernel. I found the following errors: 0. All the configure, .configure, etc. scripts are non executable. 1. There is a typo in the Makefile (or in another file, I don't remember exactly) in the directory where the kernel patches are. The variable name that finds the kernel versions 2.1.10[34] is 2.1.103 and the one that finds the kernel versions 2.1.105 is also 2.1.103 instead of 2.1.105. So the automatic patching wanted to use the 2.1.103 patch on the 2.1.105 kernel. 3. In the kgi Makefile the path of the toplevel .version file is incorrect (../.version instead of ../../.version) 4. The content of the mentioned .version file is incorrect. It should say 0.1.0 instead of 0.0.9, shouldn't it? :) 5. Some demos try to #include As I see they should #include Most of demos wouldn't compile. 6. Since the snapshot has only VGA and Matrox drivers, I configured the IBM VGA driver: insmoding it gives me an oops. My machine is a Cyrix 6x86MX-P200/64MB SDRAM, S3 Trio64V+ (Genoa Phantom P64 V2001) The OS is an upgraded RH 5.0, glibc 2.0.7, latest egcs snapshot (980608) Zoltan Boszormenyi From ggi-develop-request@eskimo.com Thu Jun 11 05:04:15 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA02957; Thu, 11 Jun 1998 05:04:13 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA03529; Thu, 11 Jun 1998 04:21:20 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 04:21:20 -0700 (PDT) Sender: duff@eskimo.com Message-ID: <357FBD18.B168CA9F@cip.informatik.uni-erlangen.de> Date: Thu, 11 Jun 1998 13:18:48 +0200 From: Andreas Vogler X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.105 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Includes problem in libggi References: <199806101620.SAA05674@mat.cythere.com> <19980611120041.45036@ajax.netspace.net.au> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mx2.eskimo.com id EAA03493 Resent-Message-ID: <"6HRQz1.0.zs.jsxVr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2744 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andrew Apted wrote: > > Mathieu Guillaume writes: > > > I may be mistaken, but it seems one has to install KGI to get libggi to > > compile. > > Indeed, the compilation process relies on two symlinks: > > /usr/include/ggi -> $(KERNELSRC)/include/ggi > > $(KERNELSRC)/include/ggi -> $(INSTALL_ROOT)$(INCLUDE)/ggi > > Yes, that's true and we should fix this so that people who only want to > use LibGGI don't need *any* kernel sources around. Are you sure. I just compiled LibGGI on a clean system (without KGI) and without the KGI target and it compiles without problems. Or do you mean that one should be able to compile the KGI target without kernel source (wouldn´t make much sense I´d say)? Andreas -- / \ "All that we see or seem \ / / \ is but a dream within a dream" E.A. Poe \ / From ggi-develop-request@eskimo.com Thu Jun 11 07:28:15 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA03157; Thu, 11 Jun 1998 07:28:13 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA07810; Thu, 11 Jun 1998 07:12:07 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 07:12:07 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: missing rights, kernel Oops Date: 11 Jun 1998 14:06:15 GMT Organization: OnTV Pittsburgh, L.P. Lines: 45 Sender: Jason McMullan Distribution: local Message-ID: <6loo8n$a09$1@butter.visus.com> References: <6lofpa$7af$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"A9elW1.0.wv1.rM-Vr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2746 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Boszormenyi Zoltan wrote with confidence: > 1. There is a typo in the Makefile (or in another file, I don't > remember exactly) in the directory where the kernel patches are. > The variable name that finds the kernel versions 2.1.10[34] is > 2.1.103 and the one that finds the kernel versions 2.1.105 is > also 2.1.103 instead of 2.1.105. So the automatic patching wanted > to use the 2.1.103 patch on the 2.1.105 kernel. Fixed. > 3. In the kgi Makefile the path of the toplevel .version file is > incorrect (../.version instead of ../../.version) Got it. > 4. The content of the mentioned .version file is incorrect. > It should say 0.1.0 instead of 0.0.9, shouldn't it? :) Yep. Fixed. > 5. Some demos try to #include > As I see they should #include > Most of demos wouldn't compile. Fixing... > 6. Since the snapshot has only VGA and Matrox drivers, I configured > the IBM VGA driver: insmoding it gives me an oops. My machine is > a Cyrix 6x86MX-P200/64MB SDRAM, S3 Trio64V+ (Genoa Phantom P64 V2001) > The OS is an upgraded RH 5.0, glibc 2.0.7, latest > egcs snapshot (980608) The oops is a known bug (well, at least 24 hours old). Anyhow, see my later post for what I'm gonna do about it.... And other things.. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Thu Jun 11 07:40:41 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA03186; Thu, 11 Jun 1998 07:40:35 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA09797; Thu, 11 Jun 1998 07:24:15 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 07:24:15 -0700 (PDT) Sender: xbouchou@ensibull.imag.fr Message-ID: <357FE769.36009D02@ensimag.imag.fr> Date: Thu, 11 Jun 1998 16:19:21 +0200 From: Xavier Bouchoux X-Mailer: Mozilla 4.03 [en] (X11; I; AIX 4.2) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: IRC summary (final) and libggi3d References: <98Jun11.133417gmt+0100.17933@fw.mol.hu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"YlW_L2.0.vO2.BY-Vr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2747 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! 1) In the IRC summary, there's one point that doesn't seem obvious to me: > Layout of memory visuals > ======================== > > [A bit vague here.] > > Use LibGGI driver libraries (linear-*, etc.) on the memory visual to mimic > the layout of the framebuffer. Copying between the memory visual and > DirectBuffer will be faster -- no CrossBlits. > That may be not so simple: Imagine you want to render some low frame rate effect (5 fps for example), that needs heavy true color calculations (several pixel overdraws and mixing), but you use a 8bit screen, or a true color one with a reversed byte order... if the memory visual in which you make all your calculations is also 8 bit, this will slow your calculations down a lot, and complexify your code... So I think there should be a way to create memory visuals from other visuals (to get the same layout and have fast blits to this visual), but also to create a memory visual by choosing its characteristics.. (Actually I'm quite new to ggi, and this may not be the best way to do this kind of thing...) 2) What is the status of libggi3d & friends? the email in the homepage don't seem to be correct... Is there some design done? even coding? 3) It's a pity you can't post to the list without having subscribed... If you only have one question, checking the archives may be sufficient. Bye! From ggi-develop-request@eskimo.com Thu Jun 11 08:11:25 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA03260; Thu, 11 Jun 1998 08:11:22 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA20273; Thu, 11 Jun 1998 08:15:51 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 08:15:51 -0700 (PDT) Date: Thu, 11 Jun 1998 11:13:35 -0400 (EDT) From: James A Simmons To: ggi-develop@eskimo.com Subject: Re: Libggi error codes? In-Reply-To: <19980610200757.54229@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"1NXZM.0.by4.YI_Vr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2748 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 10 Jun 1998, Andrew Apted wrote: > Hartmut Niemann writes: > > > Are there any libggi error codes defined? > > I don't think so. Perhaps we should stick to the standard errno values > (-EINVAL, -ENOTSUP etc...) ? Yes stay with these. > > Cheers, > _____________________________________________ ____ > \ / > Andrew Apted \/ > > > From ggi-develop-request@eskimo.com Thu Jun 11 08:47:59 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA03294; Thu, 11 Jun 1998 08:47:58 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA23151; Thu, 11 Jun 1998 08:43:13 -0700 Resent-Date: Thu, 11 Jun 1998 08:43:13 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <357FFB0E.2712CFFC@e.kth.se> Date: Thu, 11 Jun 1998 17:43:10 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Portability issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"pGwd11.0.df5.Hi_Vr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2749 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! I just took a quick look at degas, and as I care a lot about portability the first thing I noted was that the toplevel configure script uses /bin/bash as it's shell. That's a no-no. Hopefully I'll have time this weekend to try it on Digital Unix, and I will fix the portability issues that I find. So I'll just give you some issues to consider in order to maintain portability in the future: * If you write shell scripts, always use /bin/sh * As most Linux-systems have /bin/sh symlinked to bash this won't help that much. I suggest that if you want to write/modify scripts you install at least one other Bourne-style shell and test your code with it. * Never make _ANY_ assumptions about the size of datatypes! If your code depends on a datatype being of a certain size, use the [us]int* datatypes. * Do _NOT_ use uchar, ushort, uint or ulong! Those are very non-standard datatypes. Either use one of the GGI datatypes or unsigned . * Don't use gcc specific stuff unless you're writing code that is expected to be compiled with gcc only (ie. Linux kernel code) * //Marcus From ggi-develop-request@eskimo.com Thu Jun 11 09:30:28 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA03331; Thu, 11 Jun 1998 09:30:26 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA31431; Thu, 11 Jun 1998 09:27:26 -0700 Resent-Date: Thu, 11 Jun 1998 09:27:26 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35800569.BAD42CFA@e.kth.se> Date: Thu, 11 Jun 1998 18:27:21 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Libggi error codes? (and required functions) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"o5nz52.0.-g7.jL0Wr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2750 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > On Wed, 10 Jun 1998, Andrew Apted wrote: > > > Hartmut Niemann writes: > > > > > Are there any libggi error codes defined? > > > > I don't think so. Perhaps we should stick to the standard errno values > > (-EINVAL, -ENOTSUP etc...) ? Hmm, I find it quite weird to start _returning_ errno values. If we're going to use standard errno values they should be placed in errno where they belong. But I don't see any need for bloating libggi with errno codes at all. Most functions will either be drawing primitives returning void, or functions returning 0 for success and -1 for not available on this target. There will only be a small number of functions that need more than two returncodes. And speaking of available funcions, we should also decide which functions are mandatory (ie guaranteed to exist on all targets) and which are optional. The ggiGetPixel/[VH]Line/Box for example needs to be optional. If you doubt that you should take a look at the ggiGetPixel implementation on the Xlib target. ;-) //Marcus From ggi-develop-request@eskimo.com Thu Jun 11 10:21:48 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA03389; Thu, 11 Jun 1998 10:21:20 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA15389; Thu, 11 Jun 1998 10:22:29 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 10:22:29 -0700 (PDT) From: wlfshmn@ramses.ml.org Date: Thu, 11 Jun 1998 19:20:05 +0200 (CEST) To: ggi-develop@eskimo.com Subject: 2.1.105 Patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"JKgAV3.0.Gm3.D91Wr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2751 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Is it just me, or is the 2.1.105 patch broken? It fails in: include/config/apm.h include/linux/autoconf.h include/linux/version.h The 2.1.103 patch applies cleanly though on both 2.1.103 and 2.1.102 Johan Karlberg From ggi-develop-request@eskimo.com Thu Jun 11 10:59:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA03441; Thu, 11 Jun 1998 10:59:33 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA22939; Thu, 11 Jun 1998 10:59:31 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 10:59:31 -0700 (PDT) Message-Id: <199806111801.OAA10107@dew.wserv.com> From: "Jordan Mendelson" To: Subject: RE: 2.1.105 Patch Date: Thu, 11 Jun 1998 13:57:09 -0400 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Resent-Message-ID: <"7hyIu2.0.Gc5._h1Wr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2753 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Well there's a buggle, it shouldn't try to patch include/linux/version.h since it doesn't exist in virgin kernels. autoconf.h is generated by 'make config'. Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com > -----Original Message----- > From: wlfshmn@ramses.ml.org [mailto:wlfshmn@ramses.ml.org] > Sent: Thursday, June 11, 1998 1:20 PM > To: ggi-develop@eskimo.com > Subject: 2.1.105 Patch > > > Is it just me, or is the 2.1.105 patch broken? > > It fails in: > > include/config/apm.h > include/linux/autoconf.h > include/linux/version.h > > > The 2.1.103 patch applies cleanly though on both 2.1.103 and 2.1.102 > > Johan Karlberg > From ggi-develop-request@eskimo.com Thu Jun 11 11:02:08 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA03452; Thu, 11 Jun 1998 11:02:01 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA21820; Thu, 11 Jun 1998 10:54:33 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 10:54:33 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Massive KGIm changes... Date: 11 Jun 1998 17:53:33 GMT Organization: OnTV Pittsburgh, L.P. Lines: 202 Sender: Jason McMullan Message-ID: <6lp5it$fsc$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"9P4ni.0.nK5.Nd1Wr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2752 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com As many of you know, there is currently a nigh-undebuggable (because we can't get the insmod(1) map before the oops) problem with the VGA driver. Since we only have the VGA & Herc drivers at this time, hear out my proposition: Proposition: General outline ---------------------------- As I'm debugging the VGA driver, I got to thinking - why can't we do KGI module like the OSS/Lite sound driver - have a `services' module and a bunch of hardware-specific modules that regester with it. That way `building' a display from multiple hardware modules is just a matter of telling the service module what hardware is attached to waht display. Also, we can now do auto-detection on ISA cards - just load each chipset in turn, and when one detects itself it'll also load in it's appropriate clock, ramdac, etc. Also, I want to get as far away as possible from having the words `clock, ramdac, chipset', etc. embedded in the framework code. Ie, what if someones needs to have a graphics-2d and graphics-3d module? Or wants to add a mpeg-decoder? So I'm proposing a class/instance system. See below. Proposition: New KGIm modules ----------------------------- A new struct defines the modules. The only symbols the modules can export (non-static) are init_module() and cleanup_module() typedef struct kgim_module { uint32 version; /* Magic version number, ** set to KGIM_VERSION */ const char *type; /* Type of module */ const char *name; /* Hardware name */ struct kgi_display *dpy; /* Active display. Set up ** if attached to a display, ** null if otherwise */ void *priv; /* per-instance private data */ int init(struct kgim_module *module,struct kgim_card *card); void done(struct kgim_module *module); int reset(struct kgim_module *module); int check_mode(struct kgim_module *module, struct kgi_mode *mode,enum kgi_tm_cmd *cmd); int set_mode(struct kgim_module *module,struct kgi_mode *mode); void free_mode(struct kgim_module *module,struct kgi_mode *mode); int command(struct kgim_module *module,uint cmd, long arg); } kgim_module; All KGI modules (KGIm) will do only one thing on module-load: register the hardware module with kgim_register_module(). Hardware detection is done when init() is called for an instance of the module. (this way we can support hot-swap hardware in the future with statically built kernels) Instance vs. Class: The KGI module registers a class - ie, all the functions are filled out, version is set to KGIM_VERSION, name and type are set, and dpy and priv are both set to NULL. EXAMPLE CODE: kgi/drivers/ramdac/IBM/vga.c ------------- static kgim_module vga_ramdac={NULL}; int init_module(void) { vga_ramdac.version = KGIM_VERSION; vga_ramdac.type = "ramdac"; vga_ramdac.name = "IBM-vga"; vga_ramdac.init = vga_init; vga_ramdac.done = vga_done; vga_ramdac.reset= NULL; /* Not needed */ vga_ramdac.check_mode = vga_check_mode; vga_ramdac.set_mode = NULL; /* Not needed */ vga_ramdac.free_mode = NULL; /* Not needed */ return kgim_register_module(&vga_ramdac); } void cleanup_module(void) { kgim_unregister_module("ramdac","IBM-vga"); } -------------- When an instance of that module is created (usually with kgim_acquire_module) these steps are performed: 1) A new kgim_module struct is allocated 2) A copy of the class kgi_module struct is placed into the new struct 3) The new struct's init() is called on itself. (HINT - please call MOD_INC_USE_COUNT in your init!) 4) If init() is successful, the new struct is returned, otherwise the new struct is freed and NULL is returned. On destruction (kgim_release_module): 1) free_mode() is called on any mode that is active via set_mode(). 1) The instance's done() method is called (HINT - please call MOD_DEC_USE_COUNT in your done!) 2) The instance is freed. Proposition: New KGIm Linux host interface ------------------------------------------ The `kgi/driver/kernel/linux/i386.c' module now become the `kgi/driver/host/linux/kgim.c' module. The KGIm driver on load time _does_not_ auto-install a display driver. It creates a /proc/sys/console/kgim/ directory, and does some initialization. Also, it exports these functions: int kgim_register_module(struct kgim_module *class); Registers a module class with the KGIm subsystem. int kgim_unregister_module(const char *type,const char *name); Release the module class. int kgim_append_module(struct kgi_display *dpy,const char *type,const char *name); Adds a module to a display. By convention, kgim_append_module will attempt to look for modules with name = "custom-" before trying the given name. This way the system administrator can ovverride any chipset auto-detection. Proposition: New KGIm life cycle: 1) Load the KGI Host Interface module (kgim.o) 2) Load any chipset drivers you think you might need 3) Load any monitor drivers you might need 4) Create a display, ie: a) fd=open("/dev/display/0"); ioctl(fd,KGIM_APPEND_MODULE,"chipset","S3-Virge"); ioctl(fd,KGIM_APPEND_MODULE,"monitor","monosync"); OR b) echo "append 0 chipset S3-Virge" >/proc/sys/kgim/control echo "append 0 monitor monosync" >/proc/sys/kgim/control 5) When the chipset module is added to the display (handled by the KGIm module), the module's init() method is called. The hardware detection of the the chipset should be used to load the proper ramdac, clock, etc. into the display EXAMPLE CODE: vga_chipset.c --------------------------- int vga_chipset_init(struct kgi_module *module) { int err; /* Only one VGA per machine... */ if (MOD_USE_COUNT > 0) return -EBUSY; err=vga_detect(); if (err) return err; /* For VGA, we always assume standard components. ** For other chipsets, load what you can detect. */ kgim_append_module(module->dpy,"clock","IBM-vga"); kgim_append_module(module->dpy,"ramdac","IBM-vga"); kgim_append_module(module->dpy,"graphic","IBM-vga"); MOD_INC_USE_COUNT; return EOK; } ---------------------------- 6) When chipset done() is called, assume that the Host Interface will take care of removing any additional modules that you have loaded. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Thu Jun 11 19:09:35 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA03926; Thu, 11 Jun 1998 19:09:31 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA04222; Thu, 11 Jun 1998 19:08:34 -0700 (PDT) Resent-Date: Thu, 11 Jun 1998 19:08:34 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Libggi error codes? (and required functions) To: ggi-develop@eskimo.com Date: Thu, 11 Jun 1998 23:27:20 +0200 (MET DST) In-Reply-To: <35800569.BAD42CFA@e.kth.se> from "Marcus Sundberg" at Jun 11, 98 06:27:21 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"iK7pT.0.m11.Vs8Wr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2754 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > I don't think so. Perhaps we should stick to the standard errno values > > > (-EINVAL, -ENOTSUP etc...) ? > > Hmm, I find it quite weird to start _returning_ errno > values. If we're going to use standard errno values > they should be placed in errno where they belong. NO. We shouldn't emulate braindamage. Think about the weird implications of using errno in threaded applications. > primitives returning void, or functions returning 0 > for success and -1 for not available on this target. > There will only be a small number of functions that > need more than two returncodes. Yes. Usually we can live with 0=o.k., <0 error and eventually >0 for returning some value or indicating "done, though not in the standard way" (e.g. ggiExit() hasn't really removed all because the recursion counter hasn't reached 0). CU, ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 12 01:05:54 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA04185; Fri, 12 Jun 1998 01:05:52 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA14696; Fri, 12 Jun 1998 01:02:45 -0700 (PDT) Resent-Date: Fri, 12 Jun 1998 01:02:45 -0700 (PDT) From: Steffen Seeger Message-Id: <199806120800.KAA00770@mclane.physik.tu-chemnitz.de> Subject: Re: S3/Virge Question To: ggi-develop@eskimo.com Date: Fri, 12 Jun 1998 10:00:00 +0200 (MET DST) In-Reply-To: <524299DFAB41D11193EF00805F8598024F6654@brekka.ch2m.com> from "Fulgham, Brent/SCO" at May 27, 98 09:50:15 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"OfQRB2.0.Vb3.Y2EWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2755 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > This message is aimed at Jan or Teunis, but input from anyone would be > appreciated: > > Can anyone suggest why my S3/Virge driver works when compiled using the > SVGA monosync monitor data from the distribution, but when I use my own > monitor values from the mfr. literature my system locks up when I insmod > the driver? I think I've ruled out a typo in the kgi_monitor structure > I created, but you never know... > > If anyone has experience resolving this kind of problem, please respond. > > Thanks, > > -Brent Try to enable kernel logging and check the logfiles. Make sure you log debug messages also. Turning on debugging in the kernel driver gives some more output on what's going on. Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- From ggi-develop-request@eskimo.com Fri Jun 12 05:57:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA04314; Fri, 12 Jun 1998 05:57:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA17244; Fri, 12 Jun 1998 05:52:41 -0700 (PDT) Resent-Date: Fri, 12 Jun 1998 05:52:41 -0700 (PDT) From: Steffen Seeger Message-Id: <199806121247.OAA00910@mclane.physik.tu-chemnitz.de> Subject: Re: KGI license? To: ggi-develop@eskimo.com Date: Fri, 12 Jun 1998 14:47:34 +0200 (MET DST) In-Reply-To: <19980606013506.14815@fries.net> from "Todd T. Fries" at Jun 6, 98 01:35:06 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"v9AjK2.0.GD4.MIIWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2756 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > On Fri, Jun 05, 1998 at 11:47:01AM -0400, MenTaLguY wrote: > > On Thu, 4 Jun 1998, Todd T. Fries wrote: > > > It is quite an interesting statement. I made many contributions to > > > libggi, infact, the makefile system currently in place! And nowhere did > > > I ever put the GPL license. Somehow, though, in Makefiles all over sprung > > > up a GPL license. > > > > That's bad. If you had the copyright to the code, you should have been > > asked. Of course, it's also your responsibility to put appropriate copyright > > notices in the code you write. > > *sigh*. I must always learn the hard way. I am now very interested in > getting access to the old cvs repository to see exactly what it was that > I did commit originally. Not that I'm going to make any issue out of it > but just for idle curiousity. You can still get the last valid tar of the whole tree from my homepage. Actually, I feel this might have been my fault, so please anyone immediately scream if (s)he feels his/her copyright 'violated'. Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- ----------------- http: http://www.tu-chemnitz.de/~sse ----------------- From ggi-develop-request@eskimo.com Fri Jun 12 07:57:54 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA04435; Fri, 12 Jun 1998 07:57:52 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA27229; Fri, 12 Jun 1998 07:54:48 -0700 Resent-Date: Fri, 12 Jun 1998 07:54:48 -0700 From: Steffen Seeger Message-Id: <199806121454.QAA01090@mclane.physik.tu-chemnitz.de> Subject: Re: KGI license? To: ggi-develop@eskimo.com Date: Fri, 12 Jun 1998 16:54:27 +0200 (MET DST) In-Reply-To: <199806092038.WAA06084@zafir.e.kth.se> from "Marcus Sundberg" at Jun 9, 98 10:38:30 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8b7Hx1.0.Ef6.t4KWr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2758 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > I remember it's being said > > that DirectBuffer use is deprecated. I must strongly object to this, > > Huh? I really hope that you got that wrong... > Could someone please deny this! > > //Marcus You should be aware of the consequences (e.g. that you may become hardware or system dependent). Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- From ggi-develop-request@eskimo.com Fri Jun 12 08:03:57 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA04445; Fri, 12 Jun 1998 08:03:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA10404; Fri, 12 Jun 1998 07:56:02 -0700 (PDT) Resent-Date: Fri, 12 Jun 1998 07:56:02 -0700 (PDT) From: Steffen Seeger Message-Id: <199806121453.QAA01079@mclane.physik.tu-chemnitz.de> Subject: Re: KGI license? To: ggi-develop@eskimo.com Date: Fri, 12 Jun 1998 16:53:34 +0200 (MET DST) In-Reply-To: from "Stefan Mars" at Jun 9, 98 10:17:45 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BqyTX1.0.MY2.y5KWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2757 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > On Mon, 8 Jun 1998, Michael Krause wrote: > > > Oh, just let me drop in here. I just noticed I never mentioned > > officially on this list that XGGI isn't being worked on by me any > > more. I've decided that this beast is a bit too large for me, and > > because of that I'm not particularly thrilled by the thought of being > > mentioned as the maintainer. XGGI is a kind of core application for > > GGI, and it deserves a more enthusiastic maintainer :) It's just > > strange that noone seems to be seriously interested in it. > > Sad to see you leave.. I wonder who will maintain it now. I am working on incorporating XAA into it, and it compiles smoothly already. However, much of XGGI may need a rewrite, but Michael deserves ton's of credits getting the first thing to run. I use it, as I didn't manage to get the XSuSE to work last time I tried (I have to admit I haven't put much work into it), and as I work on GGI anyways... :-) Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- ------------- The GGI Project: http://www.ggi-project.org ------------- ----------------- http: http://www.tu-chemnitz.de/~sse ----------------- From ggi-develop-request@eskimo.com Fri Jun 12 08:44:16 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA04477; Fri, 12 Jun 1998 08:44:14 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA15076; Fri, 12 Jun 1998 08:17:20 -0700 (PDT) Resent-Date: Fri, 12 Jun 1998 08:17:20 -0700 (PDT) From: Steffen Seeger Message-Id: <199806121514.RAA01130@mclane.physik.tu-chemnitz.de> Subject: Re: KGI license To: ggi-develop@eskimo.com Date: Fri, 12 Jun 1998 17:14:57 +0200 (MET DST) Cc: becka@sunserver1.rz.uni-duesseldorf.de (Andreas Beck) In-Reply-To: <199806081150.NAA10675@sunserver1.rz.uni-duesseldorf.de> from "becka@rz.uni-duesseldorf.de" at Jun 8, 98 01:50:11 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"prSAu1.0.Qh3.zPKWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2759 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andy wrote: > P.S.: You might have noticed that I want a license, that allows KGI drivers > to run on _every_ system. Any licensing scheme that will inhibit using KGI > drivers on any system will lock me out of the project. > > -- > Andreas Beck | Email : Same for me. But this caueses us quite some legal trouble that should be sorted out once and for all. Andrew Shuttlewood wrote: > > Ok, we can still fix bugs ourselves too, but to a large extend > > DisplayWorks has taken control of GGI/KGI now. The Graphics board > > vendors may chose to deal with them rather than us, simply because > > they are used to making deals with software companies. At best > > we now have two forks of the work, at worst DisplayWorks may start > > to make incompatible changes, locking the rest of us out. > > Is it impossible to make a license which prohibits people from making > API changes without consent from the internet community, but allowing > them to alter the code as they see fit? > > Then any company could use the KGI/GGI code as they saw fit, not > necessarily needing to release the changes necessary to work with > their "proprietary" hardware, but they would be prevented from > changing the core API and thus forking development and leaving > free software high and dry > > Is this totally unrealistic? Or is possible to some degree? It seems > to be the best workaround to the problem in the long run... > > -- > Andrew Shuttlewood DISCLAIMER: The stuff below gives my understanding of the OpenGL licencing and is based on my (maybe bad) memory on the subject mixed with my opinions/assumptions. If you know better or that something is actually wrong, please correct. This seems much as the OpenGL situation to me. Actually SGI did not release a OpenGL *Implementation* but a specification of the underlying graphics system model and the API. This is what they call the OpenGL *Architecture*. This abstract model can be realized in many different ways, hardware in combination with software or pure software, etc. The *Architecture* itself is 'free' as to the fact that you can get the specification freely, make suggestions for enhancements to the 'Authors' etc. (If they get accepted is another issue). However, a particular *Implementation* may not be free. (Think of SGI's OpenGL, Microsofts MCD kit and MESA). I think we should do something similar for KGI. Specify the programming models, and the interfaces between the modules. (BTW, this gives good documentation too.) If some vendor thinks he can do better than our sample implementation and invests time and resources on it, he may choose to sell them. If it is better, he will get it sold, if not, he will not make much of a point. As of drivers, I consider them part of the hardware, that is the vendor has to supply it - not neccessarily in source form. You won't get the VHDL sources for the chipset either. Maybe interface specs, but not more. However, in order not to split OpenGL development, SGI forces vendors to to mark 'improved' sections as proprietary (using the extension schemes found in OpenGL) and they must pass a compliance test to be allowed to distribute it as 'OpenGL'. Of course they charge for this to get some income finally, but it can just be seen as a way to enforce compatiblity. So, if there is a well defined set of programs that test a particular implementation on 'compliance' with the architecture, anyone can run the test and blame vendor DisplayWorks if the DisplayNotWorks software he sold as KGI is not KGI-compliant. The more I think about this, the more I like it. My suggestion is: * we should put the KGI architecture, API interface specification, etc under GPL. This ensures that a vendor making changes to (internal) API's is enforced to release his changes in source form. There is one central instance that decides if these changes become part of KGI or not - the main developer(s). (See Eric Raymonds article quoted earlier). This may include stub drivers that are used by a lot of drivers. These may be under a 'kind of LGPL' that allows 'linking' but not distribution of modified code. * the KGI implementation, as far as I am concerned, should go under the copyright of the particular operating system it is implemented on. There is a 'problem' with code of the sample implementation that may be shared among architectures, but the look on GPL/LGPL/*BSD/anyLicense as an 'per-instance' license should solve that. Simply distribute in separate packages. How they are produced is another issue. As for supporting services (Makefiles, config stuff, tools, ...), they should be GPLed, in order force people to contribute enhancements/fixes. (I dunno if the BSD people would complain about GPL Makefiles...) * any drivers/modules/add-ons etc. that pass conformance tests may be under whatever copyright desired by the authors. However, I don't know how to allow these to be linked with a particular implementation. E.g. if the driver is GPL, and the KGI stuff is *BSD, can one link the driver and the KGI stuff? Technically yes, but it legally? Is the driver a 'own piece of work' or is it a derived work as it needs to be linked with the kernel? For a 'get started driver' I would suggest PD (do what you what, but give credits). So, what's the opinion about that? It sounds to me being a resonable approach, as we will force something back on the stuff that matters (the architecture, the sample implementation on 'our favourite OS', ...) I don't care about drivers for hardware that renders obsolete within 1.5 years, as long as the vendor gives me support. Of course we have to make sure that the interface is well designed so we can use binary only drivers at its capabilites lateron. This allows people to port it to other architectures, and do what they think fits them best. It's a religious issue, and I will not force my to others. But I will force them to contribute their thoughts. Comments? Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- ----------------- http: http://www.tu-chemnitz.de/~sse ----------------- Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- ------------- The GGI Project: http://www.ggi-project.org ------------- ----------------- http: http://www.tu-chemnitz.de/~sse ----------------- From ggi-develop-request@eskimo.com Fri Jun 12 08:48:35 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA04486; Fri, 12 Jun 1998 08:48:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA05439; Fri, 12 Jun 1998 08:34:40 -0700 Resent-Date: Fri, 12 Jun 1998 08:34:40 -0700 From: Steffen Seeger Message-Id: <199806121534.RAA01215@mclane.physik.tu-chemnitz.de> Subject: Re: Portability issues To: ggi-develop@eskimo.com Date: Fri, 12 Jun 1998 17:34:25 +0200 (MET DST) In-Reply-To: <357FFB0E.2712CFFC@e.kth.se> from "Marcus Sundberg" at Jun 11, 98 05:43:10 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"wEPD93.0.sK1.FgKWr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2760 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Could you just give some more pointers on that and make up a file that is to be placed in the doc/ directory? (Portability hints,...) Then send it to the Doc people for inclusion please. Thanks, Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- From ggi-develop-request@eskimo.com Fri Jun 12 08:55:14 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA04496; Fri, 12 Jun 1998 08:55:08 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA06794; Fri, 12 Jun 1998 08:46:49 -0700 Resent-Date: Fri, 12 Jun 1998 08:46:49 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35814D65.7B1EB5DE@e.kth.se> Date: Fri, 12 Jun 1998 17:46:45 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: KGI license? References: <199806121454.QAA01090@mclane.physik.tu-chemnitz.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"a7PBP1.0.2g1.erKWr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2761 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Steffen Seeger wrote: > > > > > I remember it's being said > > > that DirectBuffer use is deprecated. I must strongly object to this, > > > > Huh? I really hope that you got that wrong... > > Could someone please deny this! > > > > //Marcus > > You should be aware of the consequences (e.g. that you may become hardware > or system dependent). Hardware/system dependencies has nothing to do with DirectBuffer, it's entirely proportional to the lazyness/stupidness of the application coder. If an app would profit from DB, it should certainly use it. But of course there needs to be a fallback to the ggiPut* functions, just as any decent app should support at least 8/15/16/24/32 bpp. //Marcus From ggi-develop-request@eskimo.com Fri Jun 12 10:22:57 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA04546; Fri, 12 Jun 1998 10:22:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA21250; Fri, 12 Jun 1998 10:19:09 -0700 Resent-Date: Fri, 12 Jun 1998 10:19:09 -0700 From: Steffen Seeger Message-Id: <199806121622.SAA28647@shubashi.physik.tu-chemnitz.de> Subject: Re: KGI license? In-Reply-To: <35814D65.7B1EB5DE@e.kth.se> from Marcus Sundberg at "Jun 12, 98 05:46:45 pm" To: ggi-develop@eskimo.com Date: Fri, 12 Jun 1998 18:22:09 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"tSvFf1.0.rB5.CCMWr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2762 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Marcus wrote: > Steffen Seeger wrote: > > > > I remember it's being said > > > > that DirectBuffer use is deprecated. I must strongly object to this, > > > > > > Huh? I really hope that you got that wrong... > > > Could someone please deny this! > > > > > > //Marcus > > > > You should be aware of the consequences (e.g. that you may become hardware > > or system dependent). > > Hardware/system dependencies has nothing to do with DirectBuffer, > it's entirely proportional to the lazyness/stupidness of the > application coder. > > If an app would profit from DB, it should certainly use it. But > of course there needs to be a fallback to the ggiPut* functions, > just as any decent app should support at least 8/15/16/24/32 bpp. > > //Marcus But programmers tend to be lazy, so they might focus on the DB implementation first and then (read: never) do the Put* version. So, this is just to tell them it's not good only to rely on DB being available. Thus loosing e.g. networktransparency... Nothing to make a big discussion of ;-) Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- ----------------- http: http://www.tu-chemnitz.de/~sse ----------------- From ggi-develop-request@eskimo.com Fri Jun 12 11:15:09 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA04578; Fri, 12 Jun 1998 11:15:07 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA28270; Fri, 12 Jun 1998 11:08:20 -0700 Resent-Date: Fri, 12 Jun 1998 11:08:20 -0700 Message-Id: <199806121808.UAA06401@prague.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: ggi-develop@eskimo.com Subject: Re: KGI license? In-reply-to: Your message of "Fri, 12 Jun 1998 18:22:09 +0200." <199806121622.SAA28647@shubashi.physik.tu-chemnitz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Jun 1998 20:08:02 +0200 From: Marcus Sundberg Resent-Message-ID: <"3env4.0.bv6.JwMWr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2763 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Hardware/system dependencies has nothing to do with DirectBuffer, > > it's entirely proportional to the lazyness/stupidness of the > > application coder. > > > > If an app would profit from DB, it should certainly use it. But > > of course there needs to be a fallback to the ggiPut* functions, > > just as any decent app should support at least 8/15/16/24/32 bpp. > > > > //Marcus > > But programmers tend to be lazy, so they might focus on the DB implementation > first and then (read: never) do the Put* version. So, this is just > to tell them it's not good only to rely on DB being available. Thus loosing > e.g. networktransparency... Nothing to make a big discussion of ;-) *grin* Well, as we're making our own license we might as well add a clause saying that every program linked against libggi must be portable and stable... :-) Or we'll just make a dbemu target and get rid of the problem... //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Fri Jun 12 12:35:10 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA04707; Fri, 12 Jun 1998 12:35:02 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA09587; Fri, 12 Jun 1998 12:37:11 -0700 (PDT) Resent-Date: Fri, 12 Jun 1998 12:37:11 -0700 (PDT) Date: Fri, 12 Jun 1998 15:34:45 -0400 (EDT) From: Steve Cheng Sender: steve@maxt7m05.ipoline.com To: ggi-develop@eskimo.com Subject: Re: KGI license? In-Reply-To: <199806121808.UAA06401@prague.e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"e2wHz.0.aL2.ZDOWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2764 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 12 Jun 1998, Marcus Sundberg wrote: > Well, as we're making our own license we might as well add a clause > saying that every program linked against libggi must be portable > and stable... :-) It must work in all resolutions and color depths too ... > Or we'll just make a dbemu target and get rid of the problem... 'Tis this old issue again ... it's better if the target emulates DB itself. Because some non-DB targets use a backing store, you don't have to copy the framebuffer twice this way. Emulating DB should be optional, however, at the implementor's discretion. Of course, applications should ideally make do without DB if possible, but isn't libggi supposed to be something for everyone? ;-) -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Fri Jun 12 14:36:35 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA04793; Fri, 12 Jun 1998 14:36:32 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA24129; Fri, 12 Jun 1998 14:27:57 -0700 Resent-Date: Fri, 12 Jun 1998 14:27:57 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Extension scheme ... need some help ... To: ggi-develop@eskimo.com (mailing list GGI) Date: Fri, 12 Jun 1998 22:58:32 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"REzoK3.0.nu5.RrPWr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2765 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi folks ! I have checked in the extension scheme and modified a few of the targets (X and memory in particular) to support the new ggiGetAPI call. Could some people check if everything works as expected (I know, there are a few unresolved issues about extension module unloading) and change the other targets accordingly ? I can't test many of them, so any help is appreciated. Please check out the code from the stable repository (it should be stable, despite the changes - if not, tell me ...) and send me diffs. CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 12 16:05:10 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA04840; Fri, 12 Jun 1998 16:05:09 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA04419; Fri, 12 Jun 1998 16:00:59 -0700 Resent-Date: Fri, 12 Jun 1998 16:00:59 -0700 Date: Fri, 12 Jun 1998 18:12:11 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: sint16 or ggi_s16 ??? In-Reply-To: <357FFB0E.2712CFFC@e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"VhHvb2.0.w41.fCRWr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2766 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 11 Jun 1998, Marcus Sundberg wrote: > * Never make _ANY_ assumptions about the size of datatypes! > If your code depends on a datatype being of a certain size, > use the [us]int* datatypes. OK, way long ago the first "degas" tree started to define things as "ggi_u8" for unsigned char and such. The current sources use uint8. What will be the final form? (I kinda liked the former.) -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 12 17:35:27 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA04945; Fri, 12 Jun 1998 17:35:16 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA10281; Fri, 12 Jun 1998 17:36:33 -0700 (PDT) Resent-Date: Fri, 12 Jun 1998 17:36:33 -0700 (PDT) Date: Fri, 12 Jun 1998 18:53:32 -0400 (EDT) From: Steve Cheng Sender: steve@maxt3m13.ipoline.com To: andreas.beck@ggi-project.org cc: GGI Mailing List Subject: Re: Extension scheme ... need some help ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"58GOH3.0.WW2.EcSWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2767 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 12 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Hi folks ! > > I have checked in the extension scheme and modified a few of the targets > (X and memory in particular) to support the new ggiGetAPI call. Ok, seen it. Looks easy :) Some questions: Should we move some things like _GGIgetlinearsugstr to display/common/ ? Why does ggiGetAPI take num,apiname,arguments rather than a single ggi_suggest? Or am I confusing those two, since display/memory/mode.c uses a ggi_suggest to getAPI()? I think ggi_suggest is easier since you won't forget to allocate the memory for the strings then :) I haven't seen any changes in X target, so I suppose the modifications in the memory target are what is needed? > Could some people check if everything works as expected (I know, there are a > few unresolved issues about extension module unloading) and change the > other targets accordingly ? Will do. > I can't test many of them, so any help is appreciated. > > Please check out the code from the stable repository (it should be stable, > despite the changes - if not, tell me ...) and send me diffs. Oh stupid me. I got display/memory changes from devel, is the X target changes only in stable? Don't forget Murphy's law. Anyway, I committed some AA compile fixes to devel. -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Fri Jun 12 18:11:22 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA04973; Fri, 12 Jun 1998 18:11:19 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA17046; Fri, 12 Jun 1998 18:05:03 -0700 Resent-Date: Fri, 12 Jun 1998 18:05:03 -0700 Date: Fri, 12 Jun 1998 20:44:47 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Open Source Certification (yet more licensing comments) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"poyVJ3.0.9A4.-0TWr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2768 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Before we formalize the GGI license with a vote or something, we might want to mail the questionaire results, and proposed license to Bruce Perens of the Debian Linux project as a check to see that it satisfies the definition of "Open Source" and solicit comments. It looks like it does, with the sole sticking point being whether we require modifications to the code to be distributed in source form. The Open Source standards are sufficiently vague that I do not know if it matters if we did not (though the vote was that we do and GPL is considered an open-source license.) BTW, this point (forcing open source licensing of modicifications) is actually the most contested point on the questionairre results, and perhaps a mini-questionairre followup might help us reach a compromise position (please don't post or mail answers to these unless/until Andy says so; I'll collect and tally if Andy wants me to since I wrote the following mess.) Yes/No 1) Binary software products which contain GGI code modified by a vendor or other third party should be accompanied with a disclaimer that the software has been modified from the original open source, such as to indicate that the software may not function in all respects similar to binaries generated from the original open source. 2) Software products which include source code based on GGI code which has been modified should put a disclaimer about the modifications in each affected file, such as to point out that the file should not be used to assess the coding technique or style of the original author. 3) Binary software products which contain GGI code modified by a vendor or other third party should be accompanied with a short description of each change made. 4) Source code products which contain GGI code modified by a vendor or other third party should be accompanied with a short description of each change made and a list of the affected files. 5) Compiled software products which contain GGI code modified by a vendor or other third party should be accompanied with full source code of the modifications in patch or patched forms. 6) As 5), but the source of the modifications must be licensed open. [ Note I think this 5) is how things now stand if I interperated the questionairre correctly ] [ Note ...the following is unrelated but I think an important concept from Larry Wall's ARTISTIC.] 7) Any software (binary or source) based on GGI code and containing modifications must rename binary libraries and executables such that they do not conflict with those which may be installed based on the original open source. This can simply mean putting them in different directories with the same names, as long as, say, the original is first in the $PATH or $LD_LIBRARY_PATH. A script may be provided to overwrite the original binaries or make the modified version the system default, but must only do so if explictly requested by the user through an interactive prompt or through execution of the script. Said script must contain documentation describing what it does in the prompt, or if no prompt is issued, in the script body or manual page. For this purpose, modifications do nothing other than simply change the location of the installation of the original source code do not qualify (thus it is OK to alter GGI just to fit a system's file system standard and have this runtime copy be defaulted to.) Other comments: We may want to require that any comments in source files denoted as a "copyright" or "credit" must not be removed, rather than merely protecting the license files themselves. The license should maybe be a bit more explicit in warning that a CVS download or patch may contain files that are under stricter, separate licenses, so redistributers should remove said material if it would cause them grief. We may also want a things-that-might-appease-us-if-you-do-something- bordering-on-violating-this-license appendix chock full of things we would like people to do but don't want to require them to do. Not that we have many lawyers, but... (Plus it might add a little humor without making the document frivolous :) And links to persuasive open source documentation to encourage people to make their changes public. Finally just to volunteer for something I probably will regret, I'm no lawyer but I am pretty good at putting a formalized gloss on stuff and doing techy->lawyer translation so I can do so to the license text if requested, and can write the above into it also if desired. It's already pretty good as it stands but could use a tweak here or there. /me discards broken wetmop handle and looks around for something which will not snap when thwapped repeatedly against a horse carcass. Brian P.S. The Open Source stuff is at: http://www.opensource.org (naturally :) -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 12 21:29:34 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA05069; Fri, 12 Jun 1998 21:29:32 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id VAA09575; Fri, 12 Jun 1998 21:26:16 -0700 Resent-Date: Fri, 12 Jun 1998 21:26:16 -0700 Date: Sat, 13 Jun 1998 00:31:40 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: Libggi error codes? (and required functions) In-Reply-To: <199806121502.LAA18328@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"jVv-J.0.UL2.dzVWr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2769 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 11 Jun 1998, Marcus Sundberg wrote: > > On Wed, 10 Jun 1998, Andrew Apted wrote: > > > > > Hartmut Niemann writes: > > > > > > > Are there any libggi error codes defined? > > > > > > I don't think so. Perhaps we should stick to the standard errno values > > > (-EINVAL, -ENOTSUP etc...) ? > > Hmm, I find it quite weird to start _returning_ errno > values. If we're going to use standard errno values > they should be placed in errno where they belong. It's not quite so weird as all that -- it's the POSIX way :) Anyhow, if you're dealing with situations where the code needs to be reentrant, it makes more sense to pass error codes in return values than it does to try and play the funky (and slightly expensive) games needed to fake a reentrant global variable like errno. > But I don't see any need for bloating libggi with errno > codes at all. Most functions will either be drawing > primitives returning void, or functions returning 0 > for success and -1 for not available on this target. > There will only be a small number of functions that > need more than two returncodes. How about -ENOTSUP for not supported by the target? -1 collides with -EPERM... -=MenTaLguY=- From ggi-develop-request@eskimo.com Fri Jun 12 22:10:22 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA05084; Fri, 12 Jun 1998 22:10:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id WAA06124; Fri, 12 Jun 1998 22:13:32 -0700 (PDT) Resent-Date: Fri, 12 Jun 1998 22:13:32 -0700 (PDT) Message-Id: <199806130513.WAA06094@mx2.eskimo.com> From: "Kendall Bennett" Organization: SciTech Software, Inc. To: ggi-develop@eskimo.com Date: Fri, 12 Jun 1998 22:11:20 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Open Source Certification (yet more licensing comments) Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.01a) Resent-Message-ID: <"F8w_w.0.YV1.wfWWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2770 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com From: Brian Julin > Before we formalize the GGI license with a vote or something, > we might want to mail the questionaire results, and > proposed license to Bruce Perens of the Debian Linux project > as a check to see that it satisfies the definition of "Open Source" > and solicit comments. I think that would be an excellent idea. One point of contention that I have is that I think it would be a bad idea to create yet another Open Source software license agreement. In the case of GGI, I would strongly recommend that you guys seriously consider the option of using the Mozilla Public License (a derivative to change to the GGI Public License since the names have to change). The main reason for this is that you can then simply tell people that the GGI license is the same as the Mozilla Public License. It is beneficial for everyone involved in Open Source Software development to re-use well know licenses, so we all know how they fit together. It would worry me that GGI creates it's own license, if this license has not been put through the process of public scrutinisation and especially passed before the lawyers. The last thing you want is a license that has some nasty legal loophole in it that was not noticed because none of us are lawyers. In the case of the Mozilla Public License, it has already been devoured by Netscapes lawyers as well as publicly discussed over a lengthy period of time on netscapes newsgroups, and it has already passed the Debian definition of 'Open Source'. On top of that mozilla.org contains a good 'annotated' version of the license that explains in plain english the meaning of the legal mumbo-jumbo, helping developers and end user understand the nuances of the license. You might also be interested that at SciTech we have used a modified version of the Mozilla Public License for our SciTech MGL Public License. The only modification we made was an ammendment at the end that states that SciTech has the extra right to reuse any of the 'original' contributed code for internal projects without that code falling under the public license. ie: we can reuse all our own code for other projects, but any contributed code must remain free. Of course all the source we have release free and any new source we develop and release under the free license will forever remain free. It might also be interesting that our lawyers have been over this license with a fine toothed comb (as have myself and others in our comany) and I would give it a hearty blessing. In the case of GGI, this restriction would not be necessary since there is no one entity donating the original contribution to the Open Source community. The model of the Mozilla Public License is that any modifications to the code *must* be returned to the Open Source community, however the mechanism for doing this may be as simple as having posted a patch/modifed sources on a well known newsgroup, or uploading a patch/modified sources to a well known ftp site, or making the source available on the comany ftp/web sites. I personally think that a modified Mozilla Public License would be the best for the GGI Public License, and I implore the GGI developer community to take a serious look at it. People can identify with this license, and if they have already taken the time to understand it then they will automatically understand the GGI Public License. Best Regards, +--------------------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +--------------------------------------------------------------------------+ | Kendall Bennett | Email: KendallB@scitechsoft.com | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +--------------------------------------------------------------------------+ From ggi-develop-request@eskimo.com Fri Jun 12 22:59:27 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA05094; Fri, 12 Jun 1998 22:59:25 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id XAA13904; Fri, 12 Jun 1998 23:04:02 -0700 (PDT) Resent-Date: Fri, 12 Jun 1998 23:04:02 -0700 (PDT) From: Andrew Apted Message-ID: <19980613155749.43707@ajax.netspace.net.au> Date: Sat, 13 Jun 1998 15:57:49 +1000 To: ggi-develop@eskimo.com Subject: Re: IRC summary (final) Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Steve Cheng on Mon, Jun 08, 1998 at 05:45:07PM -0400 Resent-Message-ID: <"EAxA81.0.8P3.GPXWr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2771 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > display- prefix on target names > =============================== > > e.g. "display-memory" vs. "memory" > > "Have both by using /etc/ggi/libggi.conf set up accordingly. Official > version as used in overriding libs and such is display-*". I've just committed to cvsdevel an updated template/libggi.conf.templ file which accomplishes this. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Sat Jun 13 00:46:30 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA05226; Sat, 13 Jun 1998 00:46:28 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA24886; Sat, 13 Jun 1998 00:51:56 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 00:51:56 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <35822F24.1539C1EE@cistron.nl> Date: Sat, 13 Jun 1998 09:49:56 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Open Source Certification (yet more licensing comments) References: <199806130513.WAA06094@mx2.eskimo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"dLwv_1.0.j46.O-YWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2774 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Kendall Bennett wrote: > You might also be interested that at SciTech we have used a modified > version of the Mozilla Public License for our SciTech MGL Public > License. The only modification we made was an ammendment at the end > that states that SciTech has the extra right to reuse any of the > 'original' contributed code for internal projects without that code > falling under the public license. ie: we can reuse all our own code > for other projects, but any contributed code must remain free. Of Hmm. This seems competely unnecessary from the info you give. YOU made the code, you can put it under NPL, but also use it anywhere else for whatever purpose under whatever license (i.e. the original code (and derivativions by you), not the altered version when others hack it). > The model of the Mozilla Public License is that any modifications to > the code *must* be returned to the Open Source community, however the > mechanism for doing this may be as simple as having posted a > patch/modifed sources on a well known newsgroup, or uploading a > patch/modified sources to a well known ftp site, or making the source > available on the comany ftp/web sites. This is still not good for *BSD. Also it should be made clear that this license is incompatible with the GPL/LGPL (unless the GPL's have changed by now (which they should btw)). [Btw, andy's propsed license is also incompatible with the GPL. Hence I still prefer 2 clause BSD .. ] Btw2: with incompatible I mean you can't compile source files under under license and others under the other into one program without breaking some rules. Wouter From ggi-develop-request@eskimo.com Sat Jun 13 00:46:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA05231; Sat, 13 Jun 1998 00:46:32 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA24851; Sat, 13 Jun 1998 00:51:46 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 00:51:46 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <358188BD.260C7F95@cistron.nl> Date: Fri, 12 Jun 1998 21:59:57 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.33 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: KGI license? References: <199806121454.QAA01090@mclane.physik.tu-chemnitz.de> <35814D65.7B1EB5DE@e.kth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"WWkcn.0.946.G-YWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2773 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Marcus Sundberg wrote: > Hardware/system dependencies has nothing to do with DirectBuffer, > it's entirely proportional to the lazyness/stupidness of the > application coder. > If an app would profit from DB, it should certainly use it. But > of course there needs to be a fallback to the ggiPut* functions, Not if speed degrades badly (which it does in various cases, at least when I experimented end of last year). > just as any decent app should support at least 8/15/16/24/32 bpp. Not for full screen use. Wouter From ggi-develop-request@eskimo.com Sat Jun 13 00:50:10 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA05239; Sat, 13 Jun 1998 00:50:09 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA24835; Sat, 13 Jun 1998 00:51:42 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 00:51:42 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <3581605F.408DF89C@cistron.nl> Date: Fri, 12 Jun 1998 19:07:43 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: KGI license References: <199806121514.RAA01130@mclane.physik.tu-chemnitz.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"dwFEA.0.q36.B-YWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2772 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Steffen Seeger wrote: > * the KGI implementation, as far as I am concerned, should go > under the copyright of the particular operating system > it is implemented on. There is a 'problem' with code of the > sample implementation that may be shared among architectures, > but the look on GPL/LGPL/*BSD/anyLicense as an 'per-instance' > license should solve that. Simply distribute in separate > packages. How they are produced is another issue. > As for supporting services (Makefiles, config stuff, tools, > ...), they should be GPLed, in order force people to contribute > enhancements/fixes. (I dunno if the BSD people would > complain about GPL Makefiles...) Makefiles and shell scripts should really be PD. I think you cannot enforce copyrights on Makefiles in most cases anyway (too small, too similar to other makefiles out there) and there's no profit to be made from any of this stuff anyway (so contributing back improvements would be natural). Copyrighting even the smallest pieces of code is actually rather irritating as you can then not use stuff to get you started with your own programs (grab a makefile as a template, ditto for a shell script etc) without immediately having someone else's restrictions in your code [ a really bad one is a book where the the example programs are GPL. That's just silly. ] Wouter PS 1) I'm putting all scripts and Makefiles I use in GSI under PD (in releases 0.1-0.6, no license is mentioned in them) 2) I think include files can not be copyrighted in large part (all structure, enum's definitions etc, but things like text in a header can be copyrighted). I read something about this a long time ago, but can't remember where. From ggi-develop-request@eskimo.com Sat Jun 13 02:01:24 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA05372; Sat, 13 Jun 1998 02:01:22 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA03417; Sat, 13 Jun 1998 02:06:46 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 02:06:46 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <358240A8.49B819EE@cistron.nl> Date: Sat, 13 Jun 1998 11:04:40 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com CC: andreas.beck@ggi-project.org Subject: Re: Open Source Certification (yet more licensing comments) References: <199806130513.WAA06094@mx2.eskimo.com> <35822F24.1539C1EE@cistron.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"6sqo51.0.Hr.a4aWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2775 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com A few notes: W. Scholten wrote: [about NPL] > Also it should be made clear that this license is incompatible with the > GPL/LGPL (unless the GPL's have changed by now (which they should btw)). > > [Btw, andy's propsed license is also incompatible with the GPL. Hence I > still prefer 2 clause BSD .. ] > > Btw2: with incompatible I mean you can't compile source files under > under license and others under the other into one program without > breaking some rules. Which means these licenses should be used with a dual license approach (with GPL/LGPL) if at all. [ Andy's GGI-license ] becka@rz.uni-duesseldorf.de wrote: > IV. Common compatible licenses > > The GGI license is not very restrictive, what allows to release software > under a license, that is a combination of the GGI license and some other > license. The implications of doing so will be discussed for a few common > licenses that might be used in that context. > > 1. GPL > > GPL license enforces redistribution of source code. If a program that is > subject to the GGI license is also put under GPL, this means, that you > _cannot_ make binary releases anymore without also providing (at least > a pointer to) the source. GPL is not compatible because of your clause 2 (perhaps more, haven't checked everything). Wouter From ggi-develop-request@eskimo.com Sat Jun 13 02:20:14 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA05381; Sat, 13 Jun 1998 02:19:56 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA05277; Sat, 13 Jun 1998 02:25:47 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 02:25:47 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Open Source Certification (yet more licensing comments) To: ggi-develop@eskimo.com Date: Sat, 13 Jun 1998 11:21:01 +0200 (MET DST) In-Reply-To: from "Brian Julin" at Jun 12, 98 08:44:47 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Be9VH2.0.KI1.QMaWr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2776 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > Before we formalize the GGI license with a vote or something, > we might want to mail the questionaire results, and > proposed license to Bruce Perens of the Debian Linux project > as a check to see that it satisfies the definition of "Open Source" > and solicit comments. Definitely ... > BTW, this point (forcing open source licensing of modicifications) > is actually the most contested point on the questionairre results, > and perhaps a mini-questionairre followup might help us reach a > compromise position (please don't post or mail answers to these > unless/until Andy says so; I'll collect and tally if Andy wants > me to since I wrote the following mess.) O.K. - I will do so myself, as I have a bit more data (i.e. still can associate names with answers), that I do not want to distribute without all voters' permissions ... > 1) Binary software products which contain GGI code modified by a > vendor or other third party should be accompanied with a disclaimer > that the software has been modified from the original open source, > such as to indicate that the software may not function in all respects > similar to binaries generated from the original open source. This is taken care of by paragraph II.4. I assume we all agree on that. However your vote is welcome ... :-). > 2) Software products which include source code based on GGI code > which has been modified should put a disclaimer about the modifications > in each affected file, such as to point out that the file should > not be used to assess the coding technique or style of the original > author. O.K. - I have changed II.4 to 4. If you do not redistribute "as is", but add your own code, modify or remove existing code or otherwise alter the package, you have to state this explicitly in the CREDITS file as well as in each modified file that is distributed. Your votes ? > 3) Binary software products which contain GGI code modified by a > vendor or other third party should be accompanied with a short > description of each change made. I think that is asking a bit much for a binary release ... Votes ? > 4) Source code products which contain GGI code modified by a > vendor or other third party should be accompanied with a short > description of each change made and a list of the affected files. I'd rather stick to 2), but ... Votes ? > 5) Compiled software products which contain GGI code modified by a > vendor or other third party should be accompanied with full source > code of the modifications in patch or patched forms. Votes ? > 6) As 5), but the source of the modifications must be licensed open. Votes ? > [ Note I think this 5) is how things now stand if I interperated the > questionairre correctly ] This is how many voted. However I strongly oppose this point. Noone will make commercial products if he has to release sources he needed to patch in order to make something work e.g.. We can make certail parts (L)GPL which enforces source redistribution. However I wouldn't like that as a general scheme. The idea is, that if a vendor adds some good value to some GGI code, he should be allowed to make some money from it. If his change is good, we can still analyze it and add the same functionality to our own code. Or we might gain the source later, after the vendor has recovered its expenses and made a reasonable profit. > 7) Any software (binary or source) based on GGI code and containing > modifications must rename binary libraries and executables such that > they do not conflict with those which may be installed based on the > original open source. This can simply mean putting them in different > directories with the same names, as long as, say, the original is > first in the $PATH or $LD_LIBRARY_PATH. A script may be provided > to overwrite the original binaries or make the modified version > the system default, but must only do so if explictly requested by > the user through an interactive prompt or through execution of the script. > Said script must contain documentation describing what it does in > the prompt, or if no prompt is issued, in the script body or manual page. > For this purpose, modifications do nothing other than simply change > the location of the installation of the original source code do > not qualify (thus it is OK to alter GGI just to fit a system's file system > standard and have this runtime copy be defaulted to.) Uh - should we really care about such details ? If they install something incompatible, they'll get beaten by angry users anyway ... And if they install an enhanced version - so who cares ? > We may want to require that any comments in source files > denoted as a "copyright" or "credit" must not be removed, rather than > merely protecting the license files themselves. Copyright entries auto-protect themselves (at least here). > The license should maybe be a bit more explicit in warning that > a CVS download or patch may contain files that are under stricter, > separate licenses, so redistributers should remove said material > if it would cause them grief. This is why I made regulations about the filenames for licenses and the NODIST file. > Finally just to volunteer for something I probably will regret, > I'm no lawyer but I am pretty good at putting a formalized gloss > on stuff and doing techy->lawyer translation so I can do so to the license > text if requested, and can write the above into it also if desired. > It's already pretty good as it stands but could use a tweak here or there. O.K. - I'll attach the latest version below, so all can look at it and you can apply a soft toothbrush to it :-). CU,ANdy GGI license: ------------ Preamble The software contained in this package is subject to the license described in this document, except where explicitly stated otherwise in the sources or a file called "LICENSE" or "LICENSE.filename_to_which_it_applies" in the appropriate directory. I. WARRANTY As software under the GGI license can be maintained and altered by anyone who wishes to do so, there is no warranty. In case this software is used to produce a commercial program, the supplier of that program can at his option choose to provide a warranty that will override the regulations below, but only with respect to that particular supplier. 1. The copyright holder(s) make no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. 2. THE COPYRIGHT HOLDER(S) DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. II. Redistribution Redistributing code that is under the GGI license is allowed, as long as the following conditions are met: 1. This file, describing the GGI license and a list of contributors (which should be found in a file called "CREDITS" in the same directory this file resides in) has to be included in the redistribution. 2. Said files have to be placed "at the same place and in the same print" as the copyright regulations of the redistribution. That is : You cannot hide it in some obscure place. 3. The CREDITS file shall contain a pointer to a free distribution of the redistributed code. You may add pointers for sources of your own _below_ the existing list, as long as you state they were added by you and the sources can be freely distributed "as is" (i.e. have no "NODIST" file as described in 5.). 4. If you do not redistribute "as is", but add your own code, modify or remove existing code or otherwise alter the package, you have to state this explicitly in the CREDITS file as well as in each modified file that is distributed. 5. To avoid accidental licensing violations from redistributing a package that contains this license, but also other contributions that fall under other licenses or have additional licenses attached, that might eventually hinder "as is"-redistribution, a file called "NODIST" shall be present in any such distribution that cleanly lists all parts of the distribution that cannot be redistributed "as is" within the constrains of this license. Commentary: "Redistribution" includes giving out copies of the covered documents in source or binary form, as part of another document or binary (e.g. by statically linking it in) or any other form. Note, that you can make a modified version of the code covered by this license and distribute it with an additional license as long as the restrictions set up by this license are kept intact and eventual additional licenses that the code in question is under allow it. That is, you can make a binary-only, non-redistributable version of a GGI licensed package, as long as you keep "LICENSE" and "CREDITS", state what you altered and add all files to "NODIST". III. Advertising Names of authors in the CREDITS file, the term "ggi-project" as well as the GGI project logo may not be used to promote a particular package or product, except if you have written permission to do so. Permission can be granted by the individual developers for their respective names, and by the current project leaders of the ggi project for the term "ggi-project" and the logo. The current leaders can be derived from the "Who's who" on the GGI project homepage http://www.ggi-project.org/. IV. Relicensing and compatible licenses 1. GPL GPL licensing enforces redistribution of source code. As source code contains the credits, it is permissible to re-license any source available under the GGI license (without additional restrictions added inside the file or in some LICENSE document) under the GPL. However you are requested to include a pointer to the original package with the less strict GGI licensing. 2. BSDL BSD licensing should be fully compatible with the GGI license. In case the "give credits on screen" rule is in effect, this has to be fulfilled, too. 3. PD PD usually means giving up copyright, which does not allow any other license to be placed on the code. PD code within an otherwise GGI licensed package needs to be marked as such as described in the preamble. 4. Commercial licensing Commercial licenses usually contain one or more of the following regulations: 4.1. Give out binary-only packages. This is o.k. as long as the pointer to the free source the package was derived from is maintained and additional restrictions from other licenses (like making source available for GPLed parts) are observed. 4.2. Deny redistribution of the product. The same applies here. Redistribution cannot be denied for GPLed parts and pointers to the original sources need to be included. 4.3. Distributing a modified product. GGI licensed files may be modified and still distributed. However due to II.4 you are required to state this and keep pointers to the original source. ------------------------------------ -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 13 05:05:42 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA05497; Sat, 13 Jun 1998 05:05:41 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA01262; Sat, 13 Jun 1998 05:01:04 -0700 Resent-Date: Sat, 13 Jun 1998 05:01:04 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: IRC summary (final) To: ggi-develop@eskimo.com Date: Sat, 13 Jun 1998 11:36:05 +0200 (MET DST) In-Reply-To: <19980613155749.43707@ajax.netspace.net.au> from "Andrew Apted" at Jun 13, 98 03:57:49 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Tr3oy2.0.cJ._dcWr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2777 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > e.g. "display-memory" vs. "memory" > > "Have both by using /etc/ggi/libggi.conf set up accordingly. Official > > version as used in overriding libs and such is display-*". > I've just committed to cvsdevel an updated template/libggi.conf.templ > file which accomplishes this. Thanks. Have imported to stable with slight additions. Will show up soon. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 13 05:07:57 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA05502; Sat, 13 Jun 1998 05:07:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA21204; Sat, 13 Jun 1998 05:03:26 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 05:03:26 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Open Source Certification (yet more licensing comments) To: ggi-develop@eskimo.com Date: Sat, 13 Jun 1998 11:52:20 +0200 (MET DST) In-Reply-To: <358240A8.49B819EE@cistron.nl> from "W. Scholten" at Jun 13, 98 11:04:40 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"QLzwc2.0.AB5.CgcWr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2778 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > [Btw, andy's propsed license is also incompatible with the GPL. Hence I > > still prefer 2 clause BSD .. ] > > > > Btw2: with incompatible I mean you can't compile source files under > > under license and others under the other into one program without > > breaking some rules. I have received more comments about this and changed the latest version accordingly : IV. Relicensing and compatible licenses 1. GPL GPL licensing enforces redistribution of source code. As source code contains the credits, it is permissible to re-license any source available under the GGI license (without additional restrictions added inside the file or in some LICENSE document) under the GPL. However you are requested to include a pointer to the original package with the less strict GGI licensing. 2. BSDL BSD licensing should be fully compatible with the GGI license. In case the "give credits on screen" rule is in effect, this has to be fulfilled, too. 3. PD PD usually means giving up copyright, which does not allow any other license to be placed on the code. PD code within an otherwise GGI licensed package needs to be marked as such as described in the preamble. 4. Commercial licensing Commercial licenses usually contain one or more of the following regulations: 4.1. Give out binary-only packages. This is o.k. as long as the pointer to the free source the package was derived from is maintained and additional restrictions from other licenses (like making source available for GPLed parts) are observed. 4.2. Deny redistribution of the product. The same applies here. Redistribution cannot be denied for GPLed parts and pointers to the original sources need to be included. 4.3. Distributing a modified product. GGI licensed files may be modified and still distributed. However due to II.4 you are required to state this and keep pointers to the original source. > > This should take care of GPL. We release files under GGI license, and allow to relicense them to GPL if so desired. This, together with credits also being in the individual files and the hope anyone relicensing the code will fulfill the request for the pointer should keep the same level of protection with the GPLed code. Point 4. should allow any desireable commercial license without too many restrictions ... Comments ? CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 13 13:48:41 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA05902; Sat, 13 Jun 1998 13:48:38 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA15290; Sat, 13 Jun 1998 13:53:00 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 13:53:00 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <35825563.54AA3AF9@cistron.nl> Date: Sat, 13 Jun 1998 12:33:07 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: andreas.beck@ggi-project.org CC: ggi-develop@eskimo.com Subject: Re: Open Source Certification (yet more licensing comments) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"vyc9S1.0.ok3.hQkWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2779 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com becka@rz.uni-duesseldorf.de wrote: > I. WARRANTY > > As software under the GGI license can be maintained and altered by anyone > who wishes to do so, there is no warranty. Hey, I recognize this sentence from another license :) > In case this software is used to produce a commercial program, the supplier > of that program can at his option choose to provide a warranty that will > override the regulations below, but only with respect to that particular > supplier. This one too (expanded) :) > IV. Relicensing and compatible licenses > > 1. GPL > > GPL licensing enforces redistribution of source code. As source code contains > the credits, it is permissible to re-license any source available under > the GGI license (without additional restrictions added inside the file > or in some LICENSE document) under the GPL. > > However you are requested to include a pointer to the original package > with the less strict GGI licensing. > > 2. BSDL > > BSD licensing should be fully compatible with the GGI license. In case the > "give credits on screen" rule is in effect, this has to be fulfilled, too. > > 3. PD > > PD usually means giving up copyright, which does not allow any other license > to be placed on the code. Not true. PD means you can whatever you want with it, incorporate in your own programs etc. And hence also relicense it. scenario: delete a space, add a space and you've made a new file (exactly the same as before!) that is/contains work by you, hence copyrightable (but not enforcable as being your work until you make a lot of changes/additions). I think section IV should be changed IV. COMBINING LICENSES: - allowed as long as the conditions do not contrdict any of the conditions in this license. eg.IV.1 BSD eg.IV.2 PD V. RELICENSING IS ALLOWED TO: V.1 GPL/LGPL Wouter From ggi-develop-request@eskimo.com Sat Jun 13 15:32:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA05982; Sat, 13 Jun 1998 15:32:09 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA05340; Sat, 13 Jun 1998 15:30:09 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 15:30:09 -0700 (PDT) Message-Id: <199806132230.PAA05310@mx2.eskimo.com> From: "Kendall Bennett" Organization: SciTech Software, Inc. To: ggi-develop@eskimo.com Date: Sat, 13 Jun 1998 15:13:14 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Open Source Certification (yet more licensing comments) Priority: normal In-reply-to: <35822F24.1539C1EE@cistron.nl> X-mailer: Pegasus Mail for Win32 (v3.01a) Resent-Message-ID: <"3V-t_3.0.HJ1.krlWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2780 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com From: "W. Scholten" > Kendall Bennett wrote: > > > You might also be interested that at SciTech we have used a modified > > version of the Mozilla Public License for our SciTech MGL Public > > License. The only modification we made was an ammendment at the end that > > states that SciTech has the extra right to reuse any of the 'original' > > contributed code for internal projects without that code falling under > > the public license. ie: we can reuse all our own code for other > > projects, but any contributed code must remain free. Of > > Hmm. This seems competely unnecessary from the info you give. YOU made the > code, you can put it under NPL, but also use it anywhere else for whatever > purpose under whatever license (i.e. the original code (and derivativions > by you), not the altered version when others hack it). Well that is how I saw it also, but the lawyers did not see it that way. They said that once we released the code to the public, all that code would be bound by the MGL Public License, and hence if we re- used any of the original code we would have to re-distribute modifications also. The reason for this clause is that it is not explicity stated in the license that we may do so; hence we explicitly stated this to keep the lawyers happy. Also I doubt anyone would complain about this particular clause, since we don't plan to re-use modifications without returning changes back to the developer community. > > The model of the Mozilla Public License is that any modifications to the > > code *must* be returned to the Open Source community, however the > > mechanism for doing this may be as simple as having posted a > > patch/modifed sources on a well known newsgroup, or uploading a > > patch/modified sources to a well known ftp site, or making the source > > available on the comany ftp/web sites. > > This is still not good for *BSD. Can you tell me specifically why this is the case? > Also it should be made clear that this license is incompatible with the > GPL/LGPL (unless the GPL's have changed by now (which they should btw)). It is incompatible with GPL/LPGL in that none of the code in the MGL can be re-used and combined with GPL'ed projects because doing so would add new restrictions not present in the MGL Public License. GPL projects *can* use any of the MGL code if the code is used as a library that falls under the SciTech MGL Public License. Hence if GGI used the Mozilla Public License, it would also work fine in GPL environments provided the code is used as a library or as the intended driver interface. I too believe that the GPL should change. There should be no reason why the GPL should not allow code developed under a different license to be used with a GPL'ed product, provided the modules that are re- used from the code that was under a different license *remain* under that license. Ie: you could then add KGI to the Linux Kernal, and the KGI could would not have to become GPL'ed but it can be used with the remainder of the Linux Kernal code that may well be GPL'ed. In my opinion this achieved the goals of Open Source Software very well, since Open Source Software is all about sharing. BSD is all about sharing. GPL in my mind is RMS trying to be a dictator to the rest of the Open Source world. > [Btw, andy's propsed license is also incompatible with the GPL. Hence I > still prefer 2 clause BSD .. ] > > Btw2: with incompatible I mean you can't compile source files under > under license and others under the other into one program without > breaking some rules. Yep, damned GPL. Regards, +--------------------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +--------------------------------------------------------------------------+ | Kendall Bennett | Email: KendallB@scitechsoft.com | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +--------------------------------------------------------------------------+ From ggi-develop-request@eskimo.com Sat Jun 13 16:40:47 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA06127; Sat, 13 Jun 1998 16:40:45 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA18634; Sat, 13 Jun 1998 16:44:46 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 16:44:46 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <35830E3B.4BB61741@cistron.nl> Date: Sun, 14 Jun 1998 01:41:47 +0200 From: "W. Scholten" Organization: Gambiet software X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Open Source Certification (yet more licensing comments) References: <199806132230.PAA05310@mx2.eskimo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"JT8973.0.0Z4.hxmWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2781 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Kendall Bennett wrote: > > > You might also be interested that at SciTech we have used a modified > > > version of the Mozilla Public License for our SciTech MGL Public > > > License. The only modification we made was an ammendment at the end that > > > states that SciTech has the extra right to reuse any of the 'original' > > > contributed code for internal projects without that code falling under > > > the public license. ie: we can reuse all our own code for other > > > projects, but any contributed code must remain free. Of > > > > Hmm. This seems competely unnecessary from the info you give. YOU made the > > code, you can put it under NPL, but also use it anywhere else for whatever > > purpose under whatever license (i.e. the original code (and derivativions > > by you), not the altered version when others hack it). > > Well that is how I saw it also, but the lawyers did not see it that > way. They said that once we released the code to the public, all that > code would be bound by the MGL Public License, and hence if we re- > used any of the original code we would have to re-distribute > modifications also. The reason for this clause is that it is not > explicity stated in the license that we may do so; hence we > explicitly stated this to keep the lawyers happy. Also I doubt anyone > would complain about this particular clause, since we don't plan to > re-use modifications without returning changes back to the developer > community. Well, this is simply NOT correct. This would mean for example that I can never change the license for software, that I cannot reuse my own code that I give away. That's silly and not what copyright law is about. Copyright conditions are for those who receive things, not for those who create things. If this were true, then I cannot make a commercial derivative of a program I put under GPL for example (which I know I can). To prove it, this should suffice: I never send myself my own code under a license. Therefore I'm not bound by any license, therefore I can do whatever I want with it, including distribute it under a license, and use it as a base for other stuff which I distribute under another license. And I do object to adding such a clause, as it seems to indicate that anyone else loses all rights to software (other than the license used) after distributing if they don't add such clauses. The only case where there's more to it, is where you sell your copyright (e.g. a book, the publisher obtains the rights) but then, the code is not YOURS anymore, it's shared or someone elses. Another point is the actual legal process if what your lawyers say is true (it cannot be but lets see): Who is going to sue you for illegal use of the code? You are the copyright holder so you are the only one who can sue someone for illegal use of the code. Are you going to sue yourself? > > > The model of the Mozilla Public License is that any modifications to the > > > code *must* be returned to the Open Source community, however the > > > mechanism for doing this may be as simple as having posted a > > > patch/modifed sources on a well known newsgroup, or uploading a > > > patch/modified sources to a well known ftp site, or making the source > > > available on the comany ftp/web sites. > > > > This is still not good for *BSD. > > Can you tell me specifically why this is the case? Giving back all changes is not liked. This means anything like using pieces inline in programs (for speed eg) is not possible without giving away source. Also there are considerations like 'make a quick fix for a bug; it seems to work but we need to test some more'. Then you don't want to distribute 'maybe fixes it' source but you may still want to distribute binaries using the fix until you can really solve the problem. Wouter From ggi-develop-request@eskimo.com Sat Jun 13 18:44:59 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA06244; Sat, 13 Jun 1998 18:44:57 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA10104; Sat, 13 Jun 1998 18:51:02 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 18:51:02 -0700 (PDT) Message-Id: <199806140150.SAA10069@mx2.eskimo.com> From: "Kendall Bennett" Organization: SciTech Software, Inc. To: ggi-develop@eskimo.com Date: Sat, 13 Jun 1998 18:49:20 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Open Source Certification (yet more licensing comments) Priority: normal In-reply-to: <35830E3B.4BB61741@cistron.nl> X-mailer: Pegasus Mail for Win32 (v3.01a) Resent-Message-ID: <"5DfQh1.0.kT2.4ooWr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2782 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com From: "W. Scholten" > Kendall Bennett wrote: > > > > Hmm. This seems competely unnecessary from the info you give. YOU made > > > the code, you can put it under NPL, but also use it anywhere else for > > > whatever purpose under whatever license (i.e. the original code (and > > > derivativions by you), not the altered version when others hack it). > > > > Well that is how I saw it also, but the lawyers did not see it that way. > > They said that once we released the code to the public, all that code > > would be bound by the MGL Public License, and hence if we re- used any > > of the original code we would have to re-distribute modifications also. > > The reason for this clause is that it is not explicity stated in the > > license that we may do so; hence we explicitly stated this to keep the > > lawyers happy. Also I doubt anyone would complain about this particular > > clause, since we don't plan to re-use modifications without returning > > changes back to the developer community. > > Well, this is simply NOT correct. This would mean for example that I can > never change the license for software, that I cannot reuse my own code > that I give away. That's silly and not what copyright law is about. > Copyright conditions are for those who receive things, not for those who > create things. If this were true, then I cannot make a commercial > derivative of a program I put under GPL for example (which I know I can). This is the way you think, and this is the way I think. However in the eyes of the law this is not the way things work. Suffice to say that if this *was* the case, then Netscape would not have had to add similar ammendments to their Netscape Public License (the Mozilla PL is the non-ammended version and is currently only for new contributions). The sad fact is that half the time lawyers are dealing with stuff to make sure you cover your butt's in case some other unscrupulous soul wants to take you to task. > And I do object to adding such a clause, as it seems to indicate that > anyone else loses all rights to software (other than the license used) > after distributing if they don't add such clauses. That would appear to be what the lawyers believe to be the case with giving away commercial code to the Open Source Community (the Netscape PL is testament to this). > Another point is the actual legal process if what your lawyers say is true > (it cannot be but lets see): Who is going to sue you for illegal use of > the code? You are the copyright holder so you are the only one who can sue > someone for illegal use of the code. Are you going to sue yourself? Ok, the scenario is as follows. Just say that we re-used the SciTech MGL original source code for another product which we decided to release as commercial code. Because of the way the licensing works *everyone* is bound to contribute changes back to the developer community at large, *even* the original contributor. Hence we would be legally bound to release the modified code from the commercial product to the Open Source Community. Now obviously we are not going to sue ourselves, but some *other* company may decide that 'hey, this stuff is cool; we should sue SciTech so we can get free access to it'. To avoid this potential problem, we had to add an ammendment to the license. Believe me, I argued that this should not be necessary since IMHO as the original copyright holder we should have additional rights, but the lawyers said that unless you *specify* those additional rights, you lose them. > > > > The model of the Mozilla Public License is that any modifications to > > > > the code *must* be returned to the Open Source community, however > > > > the mechanism for doing this may be as simple as having posted a > > > > patch/modifed sources on a well known newsgroup, or uploading a > > > > patch/modified sources to a well known ftp site, or making the > > > > source available on the comany ftp/web sites. > > > > > > This is still not good for *BSD. > > > > Can you tell me specifically why this is the case? > > Giving back all changes is not liked. This means anything like using > pieces inline in programs (for speed eg) is not possible without giving > away source. Also there are considerations like 'make a quick fix for a > bug; it seems to work but we need to test some more'. Then you don't want > to distribute 'maybe fixes it' source but you may still want to distribute > binaries using the fix until you can really solve the problem. I disagree with this. If you wanted to use a portion of the code inline in another program, make sure the code you want is in a completely separate header file that falls under the correct license that the original code came from. Then you can use that code in other projects that are under a different license without a problem. Just because code is in a header file does not mean that the code that uses the header file must fall under the same license. Witness the DJGPP C runtime library, which falls under the GNU LGPL. Just because I include the DJGPP C runtime library include files (which do include inlined code BTW) does not mean that *my* code now has to be GPL'ed. On top of that it is comaptible with the license agreement to simply post a patch to the appropriate newsgroup for your changes to the code to comply with the license agreement. The way I understand it is that unless you release binaries of any code that uses the Mozilla PL to other people, you don't have to distribute any soure code (ie: you can do bug fixes etc as long as you like, and until you distribute a binary you are OK). Regards, +--------------------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +--------------------------------------------------------------------------+ | Kendall Bennett | Email: KendallB@scitechsoft.com | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +--------------------------------------------------------------------------+ From ggi-develop-request@eskimo.com Sat Jun 13 21:44:56 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA06372; Sat, 13 Jun 1998 21:44:42 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA02782; Sat, 13 Jun 1998 21:48:40 -0700 (PDT) Resent-Date: Sat, 13 Jun 1998 21:48:40 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: sint16 or ggi_s16 ??? Date: 14 Jun 1998 04:48:18 GMT Organization: OnTV Pittsburgh, L.P. Lines: 16 Sender: Jason McMullan Distribution: local Message-ID: <6lvkmi$uch$1@butter.visus.com> References: <6lsdp9$o46$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"_Unu41.0.Mh.cOrWr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2783 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Brian Julin wrote with confidence: > OK, way long ago the first "degas" tree started to define things as > "ggi_u8" for unsigned char and such. The current sources use > uint8. What will be the final form? (I kinda liked the former.) Actually, I prefer the latter... -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Sun Jun 14 07:30:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA06921; Sun, 14 Jun 1998 07:30:36 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA07854; Sun, 14 Jun 1998 07:34:14 -0700 (PDT) Resent-Date: Sun, 14 Jun 1998 07:34:14 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: doc im stable tree To: ggi-develop@eskimo.com Date: Sun, 14 Jun 1998 16:27:20 +0200 (MET DST) In-Reply-To: <199805190926.LAA07128@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at May 19, 98 11:26:34 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Ze-XC1.0.aw1.VzzWr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2785 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! Da docs eigentlich immer "stable" sein sollten - koenntest Du die docs auch in den "stable tree" commiten ? TNX, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 14 07:38:03 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA06927; Sun, 14 Jun 1998 07:38:01 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA07836; Sun, 14 Jun 1998 07:34:11 -0700 (PDT) Resent-Date: Sun, 14 Jun 1998 07:34:11 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Open Source Certification (yet more licensing comments) To: ggi-develop@eskimo.com Date: Sun, 14 Jun 1998 13:24:47 +0200 (MET DST) In-Reply-To: <35825563.54AA3AF9@cistron.nl> from "W. Scholten" at Jun 13, 98 12:33:07 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"QUMNg2.0.Ew1.RzzWr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2784 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi Wouter ! > > I. WARRANTY > > > > As software under the GGI license can be maintained and altered by anyone > > who wishes to do so, there is no warranty. > > Hey, I recognize this sentence from another license :) *grin* Yes - shamelessly stolen from yours ... I hope you do not mind ... > > 3. PD > > > > PD usually means giving up copyright, which does not allow any other license > > to be placed on the code. > > Not true. PD means you can whatever you want with it, incorporate in > your own programs etc. And hence also relicense it. What I meant is "at the same time". I will clarify this: 3. PD PD means giving up copyright, which allows relicensing to anything you like - especially to GPL,BSDL and the GGI license. PD code within an otherwise GGI licensed package needs to be marked as such as described in the preamble to allow contributors to take advantage of the additional freedom PD gives. As the GGI license protects the package as a whole, the regulations of II still apply if you redistribute a GGI-licensed package with modified PD parts. Better ? CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 14 08:15:48 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA06957; Sun, 14 Jun 1998 08:15:47 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA13521; Sun, 14 Jun 1998 08:14:32 -0700 (PDT) Resent-Date: Sun, 14 Jun 1998 08:14:32 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: doc im stable tree To: ggi-develop@eskimo.com (mailing list GGI) Date: Sun, 14 Jun 1998 17:09:13 +0200 (MET DST) In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jun 14, 98 04:27:20 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"TMm8l.0.9J3.LZ-Wr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2786 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Da docs eigentlich immer "stable" sein sollten - koenntest Du die docs auch > in den "stable tree" commiten ? Sorry - this was meant to be PM. To all who wonder: I asked Hartmut to commit docs to the stable tree also, as docs are supposed to be stable anyway ... Sorry, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 14 08:24:12 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA06962; Sun, 14 Jun 1998 08:24:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA14123; Sun, 14 Jun 1998 08:19:06 -0700 (PDT) Resent-Date: Sun, 14 Jun 1998 08:19:06 -0700 (PDT) Date: Sun, 14 Jun 1998 16:12:23 +0200 (CEST) From: Emmanuel Marty X-Sender: core@gate.local To: ggi-develop@eskimo.com cc: design@berlin-consortium.org Subject: irc session now Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"GcENg2.0.ZS3.dd-Wr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2787 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all, Where are you? :) Can't be a time problem, a lot of people were there last week at the same time. The IRC session is happening now, on irc.ggi-project.org, ports 6660-6679, channel #ggi. -- Emmanuel From ggi-develop-request@eskimo.com Sun Jun 14 14:56:13 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA07328; Sun, 14 Jun 1998 14:56:11 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA23567; Sun, 14 Jun 1998 14:57:43 -0700 (PDT) Resent-Date: Sun, 14 Jun 1998 14:57:43 -0700 (PDT) Message-Id: <199806142155.XAA14570@prague.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: ggi-develop@eskimo.com Subject: Re: KGI license? In-reply-to: Your message of "Fri, 12 Jun 1998 15:34:45 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Jun 1998 23:55:17 +0200 From: Marcus Sundberg Resent-Message-ID: <"1f4t31.0.vl5.LT4Xr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2788 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Or we'll just make a dbemu target and get rid of the problem... > > 'Tis this old issue again ... it's better if the target emulates DB itself. > Because some non-DB targets use a backing store, you don't have to copy > the framebuffer twice this way. Emulating DB should be optional, however, at > the implementor's discretion. No! We should not design libggi for braindead apps. Emulating a DB is not the job of individual targets. (Except for some very special cases) //Marcus From ggi-develop-request@eskimo.com Sun Jun 14 19:16:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA07525; Sun, 14 Jun 1998 19:16:45 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA09752; Sun, 14 Jun 1998 19:21:37 -0700 (PDT) Resent-Date: Sun, 14 Jun 1998 19:21:37 -0700 (PDT) Date: Wed, 10 Jun 1998 20:41:23 -0700 (MST) From: teunis To: ggi Mailingliste Subject: Re: libggi: Alpha values In-Reply-To: <199806050847.KAA25331@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"wL1wA2.0.EO2.kK8Xr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2789 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 5 Jun 1998, Hartmut Niemann wrote: > Hi! > > There was the suggestion to enhance ggi_color, which currently holds > > three shorts for r,g, and b, with an additional alpha value > > (transparency). Chris Meadors asked this recently again. > > The discussion seems not to be whether or not to support alpha > values, but where and how. > Some people argued that it would be necessary to change ggi_color, > some others support moving a ggi_rgba_color and alpha-aware > drawing functions to some libggi2d. > > My concern is that having (software) Alpha support in each and every > graphics routine will slow that down. > Most applications won't need Alpha support, like graphical > desktops or CAD. > I would like not to include alpha support in our base library. > > The discussion is open, the decision won't be made in Erlangen anyway ... Alpha -> ggi_colour... Doesn't making a structure a std. block-size make it -FASTER-? You can just ignore alpha if you choose not to support it..... (as per most platforms) ggi_colour currently: 3*sizeof(unsigned short) == 48 bits with alpha:4*sizeof(unsigned short) == 64 bits BTW : alpha is not transparency.... (but I can't remember why) Alpha-shading is a handy thing to have even in non-alpha-typical stuff like (umm.. thinking. Nope - can't think of anything) Guess my thinking's too biased - I use alpha-code -everywhere- I can get away with *grin* Being able to alpha-mark a frame would be nice too - so you could fade in/out an entire window (GGI context?) at once.... but AFAIK that support's already present in libGGI2D. Incidentally, most hardware these days supports alpha on a per-pixel level. Just something to think about.... G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Mon Jun 15 02:31:02 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA07918; Mon, 15 Jun 1998 02:30:56 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA10689; Mon, 15 Jun 1998 02:12:16 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 02:12:16 -0700 (PDT) From: Steffen Seeger Message-Id: <199806150909.LAA01675@mclane.physik.tu-chemnitz.de> Subject: Re: KGI license To: ggi-develop@eskimo.com Date: Mon, 15 Jun 1998 11:09:10 +0200 (MET DST) In-Reply-To: <3581605F.408DF89C@cistron.nl> from "W. Scholten" at Jun 12, 98 07:07:43 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"4n2Dv1.0.vc2.lLEXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2790 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Wouter wrote: > Makefiles and shell scripts should really be PD. I think you cannot > enforce copyrights on Makefiles in most cases anyway (too small, too > similar to other makefiles out there) and there's no profit to be made > from any of this stuff anyway (so contributing back improvements would > be natural). Good point. I was thinking of getting bugfixes and enhancements back. Anyway, for the 'support' stuff I don't really care as it's for internal use mostly. > PS > 2) I think include files can not be copyrighted in large part (all > structure, enum's definitions etc, but things like text in a header can > be copyrighted). I read something about this a long time ago, but can't > remember where. Any chance you can find out again? Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- From ggi-develop-request@eskimo.com Mon Jun 15 02:31:46 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA07927; Mon, 15 Jun 1998 02:31:45 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA11481; Mon, 15 Jun 1998 02:24:29 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 02:24:29 -0700 (PDT) From: Steffen Seeger Message-Id: <199806150919.LAA01745@mclane.physik.tu-chemnitz.de> Subject: Re: Linux, DMA, and KGI ? To: ggi-develop@eskimo.com Date: Mon, 15 Jun 1998 11:19:12 +0200 (MET DST) In-Reply-To: <199805180811.KAA01527@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at May 18, 98 10:11:27 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"cs4VW3.0.Hp2.BXEXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2791 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > I wasn't thinking so much graphics when I read that article, because > I use currently DMA somewhere else, but it looks like such a kernel > interface for allocating (unswappable) memory with physical properties > like continuosness will be necessary for textures and the like, so for > a fullfledged 3D driver for an AGP card, this would be essential. > > Who volunteers to code that? > > The original posting had some interesting replies, Linus and Robert(?) > exchanged several messages. It's already in. kmalloc gives you chunks of up to PGAE_SIZE*2^NR_MEM_LISTS bytes of contigous memory, if it is free in kernel space. You just have to lock them down and then you are fine. However, what could be of use is a kind of decent garbage collector/compression scheme to avoid fragmentation. > Hartmut. > -- > Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de > http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- From ggi-develop-request@eskimo.com Mon Jun 15 02:41:34 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA07950; Mon, 15 Jun 1998 02:41:32 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA12412; Mon, 15 Jun 1998 02:37:54 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 02:37:54 -0700 (PDT) Sender: torgeir@eskimo.com Message-ID: <35850614.259977EB@vertech.no> Date: Mon, 15 Jun 1998 11:31:32 +0000 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Linux, DMA, and KGI ? References: <199806150919.LAA01745@mclane.physik.tu-chemnitz.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"pphP62.0.l13.ljEXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2792 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Steffen Seeger wrote: > > Hartmut Niemann wrote: > > > I wasn't thinking so much graphics when I read that article, because > > I use currently DMA somewhere else, but it looks like such a kernel > > interface for allocating (unswappable) memory with physical properties > > like continuosness will be necessary for textures and the like, so for > > a fullfledged 3D driver for an AGP card, this would be essential. > > > > Who volunteers to code that? > > > > The original posting had some interesting replies, Linus and Robert(?) > > exchanged several messages. > > It's already in. kmalloc gives you chunks of up to PGAE_SIZE*2^NR_MEM_LISTS > bytes of contigous memory, if it is free in kernel space. You just > have to lock them down and then you are fine. Simon @ SuSE have done a prototype implementation. I forwarded the post to this list about two weeks ago. I can resend it to those interested. With Alan's minor adjustments, it might even be in kernel 2.3.*. -- Torgeir Veimo, Vertech AS, email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 From ggi-develop-request@eskimo.com Mon Jun 15 03:40:14 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA07960; Mon, 15 Jun 1998 03:40:11 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id DAA30391; Mon, 15 Jun 1998 03:33:21 -0700 Resent-Date: Mon, 15 Jun 1998 03:33:21 -0700 From: Steffen Seeger Message-Id: <199806151031.MAA02088@mclane.physik.tu-chemnitz.de> Subject: fork(), exec() and clone() To: ggi-develop@eskimo.com (GGI GGI) Date: Mon, 15 Jun 1998 12:31:16 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"fMe6b3.0.gQ7.mXFXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2794 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi, I have a solution to the fork() bug bothering us with the 0.0.9 KGI. However, it will cause the child / executed process loose access to memory mapped resources. Thus the library/driver may need to be 'reinitialized' after a fork(). Can this cause trouble we can't handle? I haven't found much documentation on clone(), so does anyone know what it does exactly, what stuff is inherited/changed/copied on write, etc? Thanks for the info, Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- From ggi-develop-request@eskimo.com Mon Jun 15 03:45:58 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA07965; Mon, 15 Jun 1998 03:45:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA16190; Mon, 15 Jun 1998 03:29:12 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 03:29:12 -0700 (PDT) From: Steffen Seeger Message-Id: <199806151026.MAA02078@mclane.physik.tu-chemnitz.de> Subject: Re: Linux, DMA, and KGI ? To: ggi-develop@eskimo.com Date: Mon, 15 Jun 1998 12:26:03 +0200 (MET DST) In-Reply-To: <35850614.259977EB@vertech.no> from "Torgeir Veimo" at Jun 15, 98 11:31:32 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hClv12.0.ry3.rTFXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2793 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Torgeir Veimo wrote: > Steffen Seeger wrote: > > > > Hartmut Niemann wrote: > > > > > I wasn't thinking so much graphics when I read that article, because > > > I use currently DMA somewhere else, but it looks like such a kernel > > > interface for allocating (unswappable) memory with physical properties > > > like continuosness will be necessary for textures and the like, so for > > > a fullfledged 3D driver for an AGP card, this would be essential. > > > > > > Who volunteers to code that? > > > > > > The original posting had some interesting replies, Linus and Robert(?) > > > exchanged several messages. > > > > It's already in. kmalloc gives you chunks of up to PGAE_SIZE*2^NR_MEM_LISTS > > bytes of contigous memory, if it is free in kernel space. You just > > have to lock them down and then you are fine. > > Simon @ SuSE have done a prototype implementation. I forwarded the post > to this list about two weeks ago. I can resend it to those interested. > With Alan's minor adjustments, it might even be in kernel 2.3.*. This (as far as I read it) does simply allocate the buffers, lock them and does allow to map them to user space. It doesn't solve the fragmentation problem. I have almost finished a rewrite of our /dev/graphic code, allowing multiple open, arbitraty sized ping-pong (including multiple buffers and each mapping having it's own context) which will implement our needs in terms of hardware accel virtualization. Some problems remain (policy on fork(), exec(), clone()) and it has to be tested, but I am making good progress. > Torgeir Veimo, Vertech AS, > email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 BTW, Torgeir, if you find some time please prepare your the 500TX sources to be able to set a stable picture and write some code that does context initialization/saving/restoring for the 500TX accel. You will need it soon ;-) Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- From ggi-develop-request@eskimo.com Mon Jun 15 05:01:35 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA08064; Mon, 15 Jun 1998 05:01:33 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA25224; Mon, 15 Jun 1998 05:00:26 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 05:00:26 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806151155.NAA06520@sunserver1.rz.uni-duesseldorf.de> Subject: Re: fork(), exec() and clone() In-Reply-To: <199806151031.MAA02088@mclane.physik.tu-chemnitz.de> from Steffen Seeger at "Jun 15, 98 12:31:16 pm" To: ggi-develop@eskimo.com Date: Mon, 15 Jun 1998 13:55:23 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Juk273.0.0A6.OpGXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2795 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I have a solution to the fork() bug bothering us with the 0.0.9 KGI. > > However, it will cause the child / executed process loose access to > memory mapped resources. What is the default/documented/POSIX behaviour of mmap() in that respect ? > Thus the library/driver may need to be 'reinitialized' after a fork(). > Can this cause trouble we can't handle? Might be. If e.g. the for happens in some external module or similar ... Couldn't we just fake a remap at fork() ? CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 15 06:04:56 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08114; Mon, 15 Jun 1998 06:04:53 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA04157; Mon, 15 Jun 1998 06:03:45 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 06:03:45 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35851B22.75E43F7A@e.kth.se> Date: Mon, 15 Jun 1998 15:01:22 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Request for system information. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BlpaK2.0.q01.kkHXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2796 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! If you have access to any machine(s) that doesn't run Linux, then this message is for you. In order to make libggi as portable as possible I need information about every possible system. The information I need is: 1. Output of 'uname -a' 2. Size of basic datatypes. (Compile this program and send me the output (comment out the last two lines if they won't compile)) #include #include int main(void) { printf("char: %d\n", sizeof(char)); printf("short: %d\n", sizeof(short)); printf("int: %d\n", sizeof(int)); printf("long: %d\n", sizeof(long)); printf("float: %d\n", sizeof(float)); printf("double: %d\n", sizeof(double)); printf("long long: %d\n", sizeof(long long)); printf("long double: %d\n", sizeof(long double)); return 0; } 3. What does the compiler define by default? (If you're running GCC, run 'gcc -v' which will output something like: Reading specs from foo gcc version bar Send me the file "foo". For other compilers you'll have to RTFM.) Please send the above information to marcus@ggi-project.org Thanks for your help in making libggi truly multiplatform, //Marcus From ggi-develop-request@eskimo.com Mon Jun 15 06:40:18 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08147; Mon, 15 Jun 1998 06:40:10 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA08734; Mon, 15 Jun 1998 06:31:55 -0700 Resent-Date: Mon, 15 Jun 1998 06:31:55 -0700 X-Sender: ortalo@poptsf.laas.fr Message-Id: In-Reply-To: <199806151031.MAA02088@mclane.physik.tu-chemnitz.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro F3.1.3 Date: Mon, 15 Jun 1998 15:34:01 +0200 To: ggi-develop@eskimo.com From: Rodolphe Ortalo Subject: Re: fork(), exec() and clone() Resent-Message-ID: <"Y-50p2.0.M82.A9IXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2797 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello Steffen, >I haven't found much documentation on clone(), so does anyone know >what it does exactly, what stuff is inherited/changed/copied on write, >etc? I am not sure at all of what I say now, but: clone() is targeted at multithreading, and I think it is pretty low level. In my opinion, it simply creates a new execution-context for the CPU (oversimplifying: a new program counter [1]). Any memory-related thing is probably left out of the scope of clone(). [2] This is why clone() is not really usable alone, you need a thread library to protect signals, protect semaphores and mutexes (which, themselves, must be protected because they contain meta-data such as thread lists) etc. So in my opinion, you can probably rely on the fact that both threads created by clone() have exactly the same vision of the process memory space. Wrt memory-mapping (which is surely your concern), in my opinion, both control-flows (the original one and the one created by clone()) have similar access to mmapped regions. (In fact, similar MMU settings.) Therefore, it is the job of the library to provide access control. I.e.: we need a lock on the framebuffer when doing multi-threading access (or, alternatively, we need to be very careful: we may produce a bad display, but we may also have poor performance, e.g. if one thread writes and the other thread reads "simultaneously" and this prevents efficient DMA). Rodolphe [1]: This is not a big simplification, you only need to save the CPU registers also, stack pointer, and test-regs. On uni-processors of course. [2]: And, in fact, memory-related things are the hard things to set up properly when doing multi-processing. So, it was probably pretty easy to add the clone() syscall. POST-SCRIPTUM: a nearly-{on,off}-topic piece of the linuxthreads FAQ: (see at http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html) E.7: LinuxThreads does not implement process-shared mutexes, conditions, and semaphores. Why? This is another optional component of the POSIX standard. Portable applications should test _POSIX_THREAD_PROCESS_SHARED before using this facility. The goal of this extension is to allow different processes (with different address spaces) to synchronize through mutexes, conditions or semaphores allocated in shared memory (either SVR4 shared memory segments or mmap()ed files). The reason why this does not work in LinuxThreads is that mutexes, conditions, and semaphores are not self-contained: their waiting queues contain pointers to linked lists of thread descriptors, and these pointers are meaningful only in one address space. Matt Messier and I spent a significant amount of time trying to design a suitable mechanism for sharing waiting queues between processes. We came up with several solutions that combined two of the following three desirable features, but none that combines all three: allow sharing between processes having different UIDs supports cancellation supports pthread_cond_timedwait We concluded that kernel support is required to share mutexes, conditions and semaphores between processes. That's one place where Linus Torvalds's intuition that "all we need in the kernel is clone()" fails. [NB: And this is why I think clone() is a simple CPU context duplication syscall -- ortalo] Until suitable kernel support is available, you'd better use traditional interprocess communications to synchronize different processes: System V semaphores and message queues, or pipes, or sockets. From ggi-develop-request@eskimo.com Mon Jun 15 07:07:34 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA08163; Mon, 15 Jun 1998 07:07:32 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA11493; Mon, 15 Jun 1998 07:00:12 -0700 Resent-Date: Mon, 15 Jun 1998 07:00:12 -0700 Sender: torgeir@eskimo.com Message-ID: <358543F9.4E8430F7@vertech.no> Date: Mon, 15 Jun 1998 15:55:37 +0000 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fork(), exec() and clone() References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9O6Hp2.0.Op2.iZIXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2798 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Rodolphe Ortalo wrote: > > I.e.: we need a lock on the framebuffer when doing multi-threading > access (or, alternatively, we need to be very careful: we may produce > a bad display, but we may also have poor performance, e.g. if one thread > writes and the other thread reads "simultaneously" and this prevents > efficient DMA). Simple fix: when doing dma transfers, if another process is accessing the mmio area where the dma transfer initiate registers resides in, let it get a page fault, which isn't resolved until the transfer is complete. The kernel will then halt the faulted thread until the area is available after the transfer is complete. This relies on the fact that the thread doing the reading must first check the dma byte count register which is usually located right after the initiate dma transfer register and is protected by the same mmio page. The issue of multiple threads accessing the card simultanously is a bit more complicated than this. I have an idea for a pending dma transfer table, but it might be too complicated for the kgi. -- Torgeir Veimo, Vertech AS, email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 From ggi-develop-request@eskimo.com Mon Jun 15 07:08:07 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA08168; Mon, 15 Jun 1998 07:08:06 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA11617; Mon, 15 Jun 1998 07:00:31 -0700 Resent-Date: Mon, 15 Jun 1998 07:00:31 -0700 Sender: core@orb.suntech.fr Message-ID: <358528E8.1CBB2F3B@suntech.fr> Date: Mon, 15 Jun 1998 14:00:08 +0000 From: Emmanuel Marty Reply-To: core@suntech.fr Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Request for system information. References: <35851B22.75E43F7A@e.kth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ZSrpI1.0.Or2.-ZIXr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2799 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi, I suppose I needn't give you an output of my Alpha or my O2.. :) Here are the results on an Ultrasparc 2 entreprise under Solaris 2.5: SunOS crit1.univ-montp2.fr 5.5.1 Generic_103640-20 sun4u sparc SUNW,Ultra-2 char:1 short:2 int:4 float:4 double:8 long long:8 long double:16 gcc version 2.7.2.1 Why don't you just use, when __gcc__ is defined, the following: typedef int myshort __attribute__ ((mode(HI)); typedef int myint __attribute__ ((mode(SI)); typedef int mylonglong __attribute__ ((mode(DI)); Should be easier :) -- Emmanuel From ggi-develop-request@eskimo.com Mon Jun 15 07:45:32 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA08201; Mon, 15 Jun 1998 07:45:29 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA23262; Mon, 15 Jun 1998 07:41:40 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 07:41:40 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35853205.D04FBAC9@e.kth.se> Date: Mon, 15 Jun 1998 16:39:01 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: core@suntech.fr, ggi-develop@eskimo.com Subject: Re: Request for system information. References: <35851B22.75E43F7A@e.kth.se> <358528E8.1CBB2F3B@suntech.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"AfqPm1.0.Kh5.XAJXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2801 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Emmanuel Marty wrote: > > Hi, > > I suppose I needn't give you an output of my Alpha or my O2.. :) Well, if the Alpha runs Linux I'm interested (unless Andy beats you to it ;) as I only has access to Digital Unix machines. And the O2 I'm surely interested in. > Here are the results on an Ultrasparc 2 entreprise under Solaris 2.5: > > SunOS crit1.univ-montp2.fr 5.5.1 Generic_103640-20 sun4u sparc SUNW,Ultra-2 > > char:1 short:2 int:4 float:4 double:8 long long:8 long double:16 You forgot "long" ;) > gcc version 2.7.2.1 > > Why don't you just use, when __gcc__ is defined, the following: > > typedef int myshort __attribute__ ((mode(HI)); > typedef int myint __attribute__ ((mode(SI)); > typedef int mylonglong __attribute__ ((mode(DI)); > > Should be easier :) Hmm, HI=HalfInt, SI=SingleInt and DI=DoubleInt ? Is this guaranteed to work on all platforms gcc is available on? Even it int != 32 bits ? //Marcus From ggi-develop-request@eskimo.com Mon Jun 15 07:48:03 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA08208; Mon, 15 Jun 1998 07:47:59 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA20876; Mon, 15 Jun 1998 07:28:53 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 07:28:53 -0700 (PDT) Message-Id: <199806151428.KAA16716@dew.wserv.com> From: "Jordan Mendelson" To: , Subject: RE: sint16 or ggi_s16 ??? Date: Mon, 15 Jun 1998 10:26:29 -0400 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <6lvkmi$uch$1@butter.visus.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Resent-Message-ID: <"FvLbQ2.0.465.Z-IXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2800 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Brian Julin wrote with confidence: > > OK, way long ago the first "degas" tree started to define things as > > "ggi_u8" for unsigned char and such. The current sources use > > uint8. What will be the final form? (I kinda liked the former.) > > Actually, I prefer the latter... I thought: u_int8_t int8_t u_int16_t int16_t u_int32_t int32_t u_int64_t int64_t were POSIX 1003.1g. -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From ggi-develop-request@eskimo.com Mon Jun 15 07:53:31 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA08214; Mon, 15 Jun 1998 07:53:05 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA25976; Mon, 15 Jun 1998 07:55:59 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 07:55:59 -0700 (PDT) Message-Id: <199806151455.KAA17230@dew.wserv.com> From: "Jordan Mendelson" To: Subject: RE: Request for system information. Date: Mon, 15 Jun 1998 10:53:30 -0400 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <35853205.D04FBAC9@e.kth.se> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Resent-Message-ID: <"w5E1Y3.0.gL6.xNJXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2802 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > gcc version 2.7.2.1 > > > > Why don't you just use, when __gcc__ is defined, the following: > > > > typedef int myshort __attribute__ ((mode(HI)); > > typedef int myint __attribute__ ((mode(SI)); > > typedef int mylonglong __attribute__ ((mode(DI)); > > > > Should be easier :) > > Hmm, HI=HalfInt, SI=SingleInt and DI=DoubleInt ? > Is this guaranteed to work on all platforms gcc is available on? > Even it int != 32 bits ? I double checked and POSIX 1003.1g does seem to define the types u_int#_t and int#_t (u_int32_t for example). These seem to be in both Glibc and Hjl Libc on Linux. I assume that any POSIX compliant OS would have them as well. POSIX 1003.1g if memory serves deals mainly with socket programming, but since the types *ARE* defined... we might as well use them. They should be in or Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From ggi-develop-request@eskimo.com Mon Jun 15 08:32:25 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA08232; Mon, 15 Jun 1998 08:32:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA19944; Mon, 15 Jun 1998 08:27:13 -0700 Resent-Date: Mon, 15 Jun 1998 08:27:13 -0700 From: Steffen Seeger Message-Id: <199806151524.RAA02363@mclane.physik.tu-chemnitz.de> Subject: Re: fork(), exec() and clone() To: ggi-develop@eskimo.com Date: Mon, 15 Jun 1998 17:24:42 +0200 (MET DST) In-Reply-To: from "Rodolphe Ortalo" at Jun 15, 98 03:34:01 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"XJo-r2.0.Vt4.GrJXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2803 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi Rodolphe, > >I haven't found much documentation on clone(), so does anyone know > >what it does exactly, what stuff is inherited/changed/copied on write, > >etc? > > I am not sure at all of what I say now, but: clone() is targeted > at multithreading, and I think it is pretty low level. In my opinion, > it simply creates a new execution-context for the CPU (oversimplifying: > a new program counter [1]). > > Any memory-related thing is probably left out of the scope of clone(). [2] > This is why clone() is not really usable alone, you need a thread > library to protect signals, protect semaphores and mutexes (which, > themselves, must be protected because they contain meta-data such > as thread lists) etc. > So in my opinion, you can probably rely on the fact that both threads > created by clone() have exactly the same vision of the process memory space. Mhmmm.... The clone() man page says: If COPYVM is set, child pages are copy-on-write images of the parent pages. If COPYVM is not set, the child process shares the same pages as the parent, and both parent and child may write on the same data. If not set, we are fine, if it is, the child will loose access to mmaped resources (frame buffer, accels, ...). If COPYFD is set, the child's file descriptors are copies of the parent's file descriptors. If COPYFD is not set, the child's file descriptors are shared with the parent. This seems to be ok so far, it's just as if the process had opened the file with open/reopen(). I don't know if the close-on-exec flag takes effect here too... So, this _may_ cause the child to loose access to the mmap()ed resources. At least the accelerator mappings will be lost. > Wrt memory-mapping (which is surely your concern), in my opinion, > both control-flows (the original one and the one created by clone()) > have similar access to mmapped regions. (In fact, similar MMU settings.) Similar or _same_ (as long as non-swappable regions are concerned)? Is there any way I can get a little program going that calls clone() and executes e.g. two printf()s and a sleep()? e.g. would the following work? switch (clone(..)) { case -1: error; exit(1); case 0: printf("child got here"); break; default: sleep(2); printf("parent got here"); } > Therefore, it is the job of the library to provide access control. > I.e.: we need a lock on the framebuffer when doing multi-threading > access (or, alternatively, we need to be very careful: we may produce > a bad display, but we may also have poor performance, e.g. if one thread > writes and the other thread reads "simultaneously" and this prevents > efficient DMA). Accessing the frame buffer is concurrently is not a problem from the hardware size, (dunno SMP however). Accessing it concurrently to the accel _might_ be depending on the chipset. > Rodolphe Thanks for the explanations, Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- From ggi-develop-request@eskimo.com Mon Jun 15 08:45:07 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA08241; Mon, 15 Jun 1998 08:45:01 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA03417; Mon, 15 Jun 1998 08:33:27 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 08:33:27 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35853D0F.6E798330@e.kth.se> Date: Mon, 15 Jun 1998 17:26:07 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: sint16 or ggi_s16 ??? References: <199806151428.KAA16716@dew.wserv.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"iVpgG3.0.Gr.2xJXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2804 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jordan Mendelson wrote: > > > Brian Julin wrote with confidence: > > > OK, way long ago the first "degas" tree started to define things as > > > "ggi_u8" for unsigned char and such. The current sources use > > > uint8. What will be the final form? (I kinda liked the former.) > > > > Actually, I prefer the latter... > > I thought: > > u_int8_t > int8_t > u_int16_t > int16_t > u_int32_t > int32_t > u_int64_t > int64_t > > were POSIX 1003.1g. Maybe, but libggi is supposed to run on systems that aren't POSIX 1003.1g compliant too, that's why we define out own types. As for the original issue I tend to think that ggi_u* and ggi_s* is preferable, because they're less likely to clash with any other library a libggi app may be linked to. //Marcus From ggi-develop-request@eskimo.com Mon Jun 15 09:59:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA08319; Mon, 15 Jun 1998 09:58:54 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA22378; Mon, 15 Jun 1998 10:01:37 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 10:01:37 -0700 (PDT) Date: Mon, 15 Jun 1998 12:59:04 -0400 (EDT) From: Jonathan C Day X-Sender: j.c.day@express.larc.nasa.gov To: ggi-develop@eskimo.com Subject: Cyrix MediaGX query Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"z915g3.0.WT5.iDLXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2805 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi, Once upon a time, GGI had a driver for the Cyrix MediaGX. Looking at the mailing list archives, it sounds as though there's been some internal changes to GGI, which resulted in that (and various other graphics drivers) to be pulled until fixed for the changes. Does anyone know when the MediaGX will be returning? Or is this one of those times where it's better to step back a few Linux kernels? Oh, and one other thing - I can't see any mention of the drivers being absent, either in the "What's New" or "GGI Today" web pages. Other than occasionally grabbing the development distribution, is there any way of finding out the current status of the drivers? Jonathan Day From ggi-develop-request@eskimo.com Mon Jun 15 12:03:46 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA08414; Mon, 15 Jun 1998 12:03:43 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA22369; Mon, 15 Jun 1998 12:03:52 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 12:03:52 -0700 (PDT) Date: Mon, 15 Jun 1998 15:01:08 -0400 (EDT) From: James A Simmons To: ggi-develop@eskimo.com Subject: Re: sint16 or ggi_s16 ??? In-Reply-To: <35853D0F.6E798330@e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"XOmQ63.0.IT5.H0NXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2806 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 15 Jun 1998, Marcus Sundberg wrote: > Jordan Mendelson wrote: > > > > > Brian Julin wrote with confidence: > > > > OK, way long ago the first "degas" tree started to define things as > > > > "ggi_u8" for unsigned char and such. The current sources use > > > > uint8. What will be the final form? (I kinda liked the former.) > > > > > > Actually, I prefer the latter... > > > > I thought: > > > > u_int8_t > > int8_t > > u_int16_t > > int16_t > > u_int32_t > > int32_t > > u_int64_t > > int64_t > > > > were POSIX 1003.1g. > > Maybe, but libggi is supposed to run on systems that aren't > POSIX 1003.1g compliant too, that's why we define out own > types. > > As for the original issue I tend to think that ggi_u* and ggi_s* > is preferable, because they're less likely to clash with any > other library a libggi app may be linked to. > > //Marcus > > This is easy to deal with. Take a look at the Xmd.h. This file is the the header file of X windows the copes with different types. From ggi-develop-request@eskimo.com Mon Jun 15 12:14:31 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA08425; Mon, 15 Jun 1998 12:14:28 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA25581; Mon, 15 Jun 1998 12:19:08 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 12:19:08 -0700 (PDT) Message-Id: <199806151919.VAA31690@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 15 Jun 1998 21:13:56 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: Re: Cyrix MediaGX query In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"brnVq1.0.YF6.dENXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2807 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello Jonathan, > Once upon a time, GGI had a driver for the Cyrix MediaGX. >Looking at the mailing list archives, it sounds as though >there's been some internal changes to GGI, which resulted >in that (and various other graphics drivers) to be pulled >until fixed for the changes. GGI does have a driver for the MediaGX - if you grab the "dali-final" snapshot from our FTP servers, you'll notice it's there. What's happening right now is that we are putting things back together again, in the new CVS repository. First came libggi, then the GGI console (previously EvStack). The GGI console and new KGI subsystem have modified a bit the driver API (for the best) - therefore, the drivers haven't been checked in yet as they need slight changes to work with the new API. >Does anyone know when the >MediaGX will be returning? Or is this one of those times >where it's better to step back a few Linux kernels? I will port the MediaGX driver to the new KGI interface as soon as it is publicly defined by Jason and Steffen (as all drivers authors will do, I guess).. That should be quick, but in the meantime, I would be interested if you tried the driver in the "dali" snapshot (the latest one in the ggi-snapshots directory, not the official (earlier) dali distribution, which contains an outdated driver) and tell me how it works on your system - together with what kind of cpu/chipset (GX/GXi/GXM, 5510/5520) pair you have - so that I can fix possible bugs. Thanks :) -- Emmanuel From ggi-develop-request@eskimo.com Mon Jun 15 12:32:18 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA08455; Mon, 15 Jun 1998 12:31:36 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA26360; Mon, 15 Jun 1998 12:26:59 -0700 Resent-Date: Mon, 15 Jun 1998 12:26:59 -0700 Message-Id: <199806151929.VAA31702@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 15 Jun 1998 21:23:24 +0200 To: Marcus Sundberg From: Emmanuel Marty Subject: Re: Request for system information. Cc: ggi-develop@eskimo.com In-Reply-To: <35853205.D04FBAC9@e.kth.se> References: <35851B22.75E43F7A@e.kth.se> <358528E8.1CBB2F3B@suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"lXvoA1.0.cR6.2MNXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2808 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Marcus Sundberg did write : [I did] >> I suppose I needn't give you an output of my Alpha or my O2.. :) > >Well, if the Alpha runs Linux I'm interested (unless Andy beats >you to it ;) as I only has access to Digital Unix machines. I got enough of Digital Unix and NT, so of course I run Linux :-) Linux alpha.local 2.0.33 #8 Sat Feb 21 00:32:50 CET 1998 alpha unknown char: 1 short: 2 int: 4 long: 8 float: 4 double: 8 long long: 8 long double: 8 Reading specs from /usr/lib/gcc-lib/alpha-linux/2.7.2.1/specs gcc version 2.7.2.1 I know, surprising results. > And the O2 I'm surely interested in. Well, there already was an entry for IRIX 32-bit systems in system.h - are you rewriting it or something? :) >> SunOS crit1.univ-montp2.fr 5.5.1 Generic_103640-20 sun4u sparc SUNW,Ultra-2 >> >> char:1 short:2 int:4 float:4 double:8 long long:8 long double:16 > >You forgot "long" ;) Oops, sorry. Stupid cut-paste wouldn't work there :) long: 4 >Hmm, HI=HalfInt, SI=SingleInt and DI=DoubleInt ? >Is this guaranteed to work on all platforms gcc is available on? >Even it int != 32 bits ? Hrmm, that's a good question. I assumed that, because ELF headers use that on both 32 and 64-bit platforms, but actually the int size is 32-bit on both. So now you put the doubt in me :) -- Emmanuel From ggi-develop-request@eskimo.com Mon Jun 15 15:18:55 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA08622; Mon, 15 Jun 1998 15:18:52 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA11269; Mon, 15 Jun 1998 15:20:35 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 15:20:35 -0700 (PDT) Message-Id: <199806152213.AAA18982@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: CVS stuff Date: Tue, 16 Jun 1998 00:13:06 +0200 From: Marcus Sundberg Resent-Message-ID: <"9TeQb2.0.ul2.kuPXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2809 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Argh! Is there ANY reason to have the docs in all formats in the CVS tree? For the devel branch I can't see any point in having anything other than the SGML source in CVS. Having other formats are just more to download. And speaking of the CVS repository, am I the only one experiencing extreme slowness? (old repository) ----samson.hrz.tu-chemnitz.de PING Statistics---- 21 packets transmitted, 21 packets received, 0% packet loss round-trip (ms) min/avg/max = 51/57/63 ms (some presumably heavy loaded sites oversea) ----ftp.mozilla.org PING Statistics---- 21 packets transmitted, 21 packets received, 0% packet loss round-trip (ms) min/avg/max = 160/163/169 ms ----tsx-11.mit.edu PING Statistics---- 22 packets transmitted, 22 packets received, 0% packet loss round-trip (ms) min/avg/max = 121/124/141 ms And the new repository ----cvs.ggi-project.org PING Statistics---- 21 packets transmitted, 16 packets received, 23% packet loss round-trip (ms) min/avg/max = 359/465/591 ms These ping-times indicate that something is very wrong with the new repository. Emmanuel? //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan/ Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Mon Jun 15 15:30:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA08629; Mon, 15 Jun 1998 15:30:30 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA12231; Mon, 15 Jun 1998 15:25:08 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 15:25:08 -0700 (PDT) Date: Mon, 15 Jun 1998 18:22:52 -0400 (EDT) From: Brian Julin To: Marcus Sundberg cc: ggi-develop@eskimo.com Subject: Re: Request for system information. In-Reply-To: <35851B22.75E43F7A@e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Pl7qh1.0.--2.1zPXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2810 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Have fun... OSF1 alpha.dpc.umassp.edu V4.0 386 alpha (gcc) char: 1 short: 2 int: 4 long: 8 float: 4 double: 8 long long: 8 long double: 8 bash$ cc typeinfo.c -o typeinfo bash$ ./typeinfo char: 1 short: 2 int: 4 long: 8 float: 4 double: 8 long long: 8 long double: 8 bash$ which cc /usr/bin/cc bash$ which gcc /usr/local/bin/gcc ------- [bri@mgt2 bri]$ ./typeinfo char: 1 short: 2 int: 4 long: 4 float: 4 double: 8 long long: 8 long double: 16 [bri@mgt2 bri]$ which gcc /usr/local/opt/GCC2721/bin/gcc [bri@mgt2 bri]$ which cc [bri@mgt2 bri]$ uname -a SunOS mgt2 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-1 [bri@mgt2 bri]$ ------- mighty 24: uname -a HP-UX mighty A.09.05 A 9000/715 2009123546 two-user license mighty 25: cc typeinfo.c -o typeinfo cc: "typeinfo.c", line 4: error 1705: Function prototypes are an ANSI feature. cc: "typeinfo.c", line 13: error 1642: Duplicate type specifier "long": ignored.cc: "typeinfo.c", line 14: error 1709: Long double is an ANSI feature. mighty 26: gcc typeinfo.c -o typeinfo mighty 27: ./typeinfo char: 1 short: 2 int: 4 long: 4 float: 4 double: 8 long long: 8 long double: 8 mighty 28: ------- -- Brian S. Julin From ggi-develop-request@eskimo.com Mon Jun 15 16:04:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA08643; Mon, 15 Jun 1998 16:04:32 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA20878; Mon, 15 Jun 1998 16:06:21 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 16:06:21 -0700 (PDT) Date: Mon, 15 Jun 1998 18:31:24 -0400 (EDT) From: Steve Cheng Sender: steve@elmert To: ggi-develop@eskimo.com Subject: Re: CVS stuff In-Reply-To: <199806152213.AAA18982@zafir.e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"AEz8T1.0.265.fZQXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2811 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 16 Jun 1998, Marcus Sundberg wrote: > For the devel branch I can't see any point in having anything > other than the SGML source in CVS. > Having other formats are just more to download. Agreed. > And speaking of the CVS repository, am I the only one > experiencing extreme slowness? May be. But it was my modem's fault... Anyway, libggi compile in the devel tree is currently broken. It doesn't seem to set $LIBGGI_TOPLEVEL / $TOPLEVEL correctly. Could someone please fix that? -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Mon Jun 15 18:23:51 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA08745; Mon, 15 Jun 1998 18:23:28 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA20509; Mon, 15 Jun 1998 18:29:14 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 18:29:14 -0700 (PDT) Date: Mon, 15 Jun 1998 21:31:56 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: GGI GGI Subject: Re: fork(), exec() and clone() In-Reply-To: <199806160110.VAA05609@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"PpzbS.0.H05.cfSXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2812 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 15 Jun 1998, Steffen Seeger wrote: > I have a solution to the fork() bug bothering us with the 0.0.9 KGI. > > However, it will cause the child / executed process loose access to > memory mapped resources. Thus the library/driver may need to be > 'reinitialized' after a fork(). Can this cause trouble we can't > handle? > > I haven't found much documentation on clone(), so does anyone know > what it does exactly, what stuff is inherited/changed/copied on write, > etc? clone() is basically the same as fork(), except you can specify flags to indicate precisely what is shared between the two processes. Current flags are (at least in 2.0.33): #define CSIGNAL 0x000000ff /* signal mask to be sent at exit */ #define CLONE_VM 0x00000100 /* set if VM shared between processes */ #define CLONE_FS 0x00000200 /* set if fs info shared between processes */ #define CLONE_FILES 0x00000400 /* set if open files shared between processes */ #define CLONE_SIGHAND 0x00000800 /* set if signal handlers shared */ #define CLONE_PID 0x00001000 /* set if pid shared */ fork() is functionally equivalent to clone(0, CLONE_FILES|SIGCLD), I _think_ ... -=MenTaLguY=- From ggi-develop-request@eskimo.com Mon Jun 15 18:46:03 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA08763; Mon, 15 Jun 1998 18:46:01 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA22764; Mon, 15 Jun 1998 18:40:54 -0700 Resent-Date: Mon, 15 Jun 1998 18:40:54 -0700 Date: Mon, 15 Jun 1998 21:45:55 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: fork(), exec() and clone() In-Reply-To: <199806160110.VAA05654@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"qIQx63.0.VZ5.aqSXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2813 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 15 Jun 1998, Steffen Seeger wrote: > Hi Rodolphe, > > > I am not sure at all of what I say now, but: clone() is targeted > > at multithreading, and I think it is pretty low level. In my opinion, > > it simply creates a new execution-context for the CPU (oversimplifying: > > a new program counter [1]). > Mhmmm.... The clone() man page says: > > If COPYVM is set, child pages are copy-on-write images of > the parent pages. If COPYVM is not set, the child process > shares the same pages as the parent, and both parent and > child may write on the same data. > > If not set, we are fine, if it is, the child will loose access to mmaped > resources (frame buffer, accels, ...). > > If COPYFD is set, the child's file descriptors are copies > of the parent's file descriptors. If COPYFD is not set, > the child's file descriptors are shared with the parent. > > This seems to be ok so far, it's just as if the process had opened > the file with open/reopen(). I don't know if the close-on-exec > flag takes effect here too... The flags seem rather different from what I gleaned from the kernel source ... maybe the C library wrapper is rather different somehow; I don't know. In any case, I think clone's behavior is basically identical to that of fork() (they are implemented by the same routine in the kernel, do_fork()), so I don't think the close-on-exec flag would take effect on clone(). > Is there any way I can get a little program going that calls clone() and > executes e.g. two printf()s and a sleep()? > > e.g. would the following work? > > switch (clone(..)) { > > case -1: > error; > exit(1); > > case 0: > printf("child got here"); > break; > > default: > sleep(2); > printf("parent got here"); > } Only problem is that the C library would need to be reentrant -- I don't think libc6 is. At the very least, you'd need to define _REENTRANT before including any of the header files, and also provide an implementation for whatever hook function it is that's used to give a thread-specific errno. You may also need threadsafe wrappers for some of the library functions, too. LinuxThreads does all of that for you, but afaiK you need to use clone() indirectly through the POSIX interface it provides if you do use it. -=MenTaLguY=- From ggi-develop-request@eskimo.com Mon Jun 15 18:48:10 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA08768; Mon, 15 Jun 1998 18:48:07 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA26391; Mon, 15 Jun 1998 18:54:13 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 18:54:13 -0700 (PDT) X-Authentication-Warning: mir.inazuma.dyn.ml.org: tetron owned process doing -bs Date: Mon, 15 Jun 1998 22:00:32 -0400 (EDT) From: Peter Amstutz X-Sender: amstpi@mir.inazuma.dyn.ml.org Reply-To: amstpi@freenet.tlh.fl.us To: ggi-develop@eskimo.com Subject: Re: fork(), exec() and clone() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"q10uy1.0.7S6.21TXr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2814 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 15 Jun 1998, MenTaLguY wrote: > Only problem is that the C library would need to be reentrant -- I don't > think libc6 is. At the very least, you'd need to define _REENTRANT before libc.5.4.x and all libc6 (glibc2) is compiled reentrant. Better threading support is part of the whole *reason* libc6 is such a major upgrade. On the other hand, other major libraries may not be. Xlib 3.2.2 is compiled reentrant in the glibc binaries, but not the libc5 binaries. A slight problem for threading when using the X target... Peter Amstutz /* E-mail: amstpi@freenet.tlh.fl.us Home Page: http://www.freenet.tlh.fl.us/~amstpi/ Geek Code: (see http://www.geekcode.com/ for decoding instructions) GCS d- s:+ a--- C++>$ UL++++>$ P+(++) L++>$ E W++ N+ !o K w-- !O M-() !V PS+(++) PE-(--) Y+ PGP t 5++ X+ R tv b+ DI+ D++ G e h */ From ggi-develop-request@eskimo.com Mon Jun 15 19:00:59 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA08775; Mon, 15 Jun 1998 19:00:51 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA29616; Mon, 15 Jun 1998 19:06:54 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 19:06:54 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: GGI license - draft #4 To: ggi-develop@eskimo.com (mailing list GGI) Date: Mon, 15 Jun 1998 19:59:51 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"OJhMd.0.dE7.xCTXr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2815 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com HI folks ! I made a few improvements to the proposed GGI license, and would like you all to have another look and send me comments. After this round, I will send a commented version to Bruce Perens and Eric S. Raymond, and ask them for their opinions. So please make sure that I don't have to apologize for sending them something with a gaping hole in it ... :-). CU,Andy Suggested GGI license: ----------------------- Preamble The software contained in this package is subject to the license described in this document, except where explicitly stated otherwise in the sources or a file called "LICENSE" or "LICENSE.filename_to_which_it_applies" in the appropriate directory. I. WARRANTY As software under the GGI license can be maintained and altered by anyone who wishes to do so, there is no warranty. In case this software is used to produce a commercial program, the supplier of that program can at his option choose to provide a warranty that will override the regulations below, but only with respect to that particular supplier. 1. The copyright holder(s) make no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. 2. THE COPYRIGHT HOLDER(S) DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. II. Redistribution Redistributing code that is under the GGI license is allowed, as long as the following conditions are met: 1. This file, describing the GGI license and a list of contributors (which should be found in a file called "CREDITS" in the same directory this file resides in) has to be included in the redistribution. 2. Said files have to be placed "at the same place and in the same print" as the copyright regulations of the redistribution. That is : You cannot hide it in some obscure place. 3. The CREDITS file shall contain a pointer to a free distribution of the redistributed code. You may add pointers for sources of your own _below_ the existing list, as long as you state they were added by you and the sources can be freely distributed "as is" (i.e. have no "NODIST" file as described in 5.). 4. If you do not redistribute "as is", but add your own code, modify or remove existing code or otherwise alter the package, you have to state this explicitly in the CREDITS file as well as in each modified file that is distributed. 5. To avoid accidental licensing violations from redistributing a package that contains this license, but also other contributions that fall under other licenses or have additional licenses attached, that might eventually hinder "as is"-redistribution, a file called "NODIST" shall be present in any such distribution that cleanly lists all parts of the distribution that cannot be redistributed "as is" within the constrains of this license. Commentary: "Redistribution" includes giving out copies of the covered documents in source or binary form, as part of another document or binary (e.g. by statically linking it in) or any other form. Note, that you can make a modified version of the code covered by this license and distribute it with an additional license as long as the restrictions set up by this license are kept intact and eventual additional licenses that the code in question is under allow it. That is, you can make a binary-only, non-redistributable version of a GGI licensed package, as long as you keep "LICENSE" and "CREDITS", state what you altered and add all files to "NODIST". III. Advertising Names of authors in the CREDITS file, the term "ggi-project" as well as the GGI project logo may not be used to promote a particular package or product, except if you have written permission to do so. Permission can be granted by the individual developers for their respective names, and by the current project leaders of the ggi project for the term "ggi-project" and the logo. The current leaders can be derived from the "Who's who" on the GGI project homepage http://www.ggi-project.org/. IV. Relicensing and compatible licenses 1. GPL GPL licensing enforces redistribution of source code. As source code contains the credits, it is permissible to re-license any source available under the GGI license (without additional restrictions added inside the file or in some LICENSE document) under the GPL. However you are requested to include a pointer to the original package with the less strict GGI licensing. 2. BSDL BSD licensing should be fully compatible with the GGI license. In case the "give credits on screen" rule is in effect, this has to be fulfilled, too. 3. PD PD means giving up copyright, which allows relicensing to anything you like - especially to GPL,BSDL and the GGI license. PD code within an otherwise GGI licensed package needs to be marked as such as described in the preamble to allow contributors to take advantage of the additional freedom PD gives. As the GGI license protects the package as a whole, the regulations of II still apply if you redistribute a GGI-licensed package with modified PD parts. 4. Commercial licensing Commercial licenses usually contain one or more of the following regulations: 4.1. Give out binary-only packages. This is o.k. as long as the pointer to the free source the package was derived from is maintained and additional restrictions from other licenses (like making source available for GPLed parts) are observed. 4.2. Deny redistribution of the product. The same applies here. Redistribution cannot be denied for GPLed parts and pointers to the original sources need to be included. 4.3. Distributing a modified product. GGI licensed files may be modified and still distributed. However due to II.4 you are required to state this and keep pointers to the original source. ------------------------------------ -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 15 20:55:15 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA08852; Mon, 15 Jun 1998 20:55:12 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id UAA11653; Mon, 15 Jun 1998 20:47:35 -0700 Resent-Date: Mon, 15 Jun 1998 20:47:35 -0700 X-Authentication-Warning: mir.inazuma.dyn.ml.org: tetron owned process doing -bs Date: Mon, 15 Jun 1998 23:56:00 -0400 (EDT) From: Peter Amstutz X-Sender: amstpi@mir.inazuma.dyn.ml.org Reply-To: amstpi@freenet.tlh.fl.us To: ggi-develop@eskimo.com Subject: little bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"l5V0B.0.zr2.MhUXr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2816 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com degas/lib/libggi/extensions/misc/display/svgalib/mode.c defines GGIwaitraypos. I don't think it goes here, it's suppose to be in another library, right? Anyway, it's currently tripping up compilation of libggi, and should be moved or commented out. Peter Amstutz /* E-mail: amstpi@freenet.tlh.fl.us Home Page: http://www.freenet.tlh.fl.us/~amstpi/ Geek Code: (see http://www.geekcode.com/ for decoding instructions) GCS d- s:+ a--- C++>$ UL++++>$ P+(++) L++>$ E W++ N+ !o K w-- !O M-() !V PS+(++) PE-(--) Y+ PGP t 5++ X+ R tv b+ DI+ D++ G e h */ From ggi-develop-request@eskimo.com Mon Jun 15 23:30:45 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA09000; Mon, 15 Jun 1998 23:30:43 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id XAA18980; Mon, 15 Jun 1998 23:32:24 -0700 (PDT) Resent-Date: Mon, 15 Jun 1998 23:32:24 -0700 (PDT) Message-Id: <199806160628.IAA32016@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 16 Jun 1998 08:22:20 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: Re: CVS stuff In-Reply-To: <199806152213.AAA18982@zafir.e.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"qglqO2.0.Se4.s5XXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2817 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >----cvs.ggi-project.org PING Statistics---- >21 packets transmitted, 16 packets received, 23% packet loss >round-trip (ms) min/avg/max = 359/465/591 ms Yes, this happens more than I would want it to, lately. Looks like a couple of primary upstream links down - it works now. :) -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 16 00:39:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA09190; Tue, 16 Jun 1998 00:39:40 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA25882; Tue, 16 Jun 1998 00:40:09 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 00:40:09 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806160732.JAA03565@cip8.e-technik.uni-erlangen.de> Subject: Re: CVS stuff To: ggi-develop@eskimo.com Date: Tue, 16 Jun 1998 09:32:51 +0200 (MESZ) In-Reply-To: <199806152213.AAA18982@zafir.e.kth.se> from "Marcus Sundberg" at Jun 16, 98 00:13:06 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lPhtV2.0.DK6.M5YXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2818 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Argh! > > Is there ANY reason to have the docs in all formats in the > CVS tree? > For the devel branch I can't see any point in having anything > other than the SGML source in CVS. > Having other formats are just more to download. > > //Marcus Yes there are two. 1) nobody complained when I asked what to commit. Most of them should not show up in the tarballs, I hope. 2) There are some bugs in sgml-tools, at least two of which are fixed in the version I use ( in section headlines in sgml2txt, in tex/dvi/ps). Maybe the fixes make it into 1.0.7 3) I planned looking into the new DocBook-based sgml-tools 1.1 as soon as they look stable, at that point you couln't expect anybody to download and install them. 4) I don't want to force anybody to download and install yet another package jsut to format and read the documentation. Sometimes the only way for getting feedback is simply to do it and wait for the complaints ... Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Tue Jun 16 01:51:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA09407; Tue, 16 Jun 1998 01:51:36 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA07977; Tue, 16 Jun 1998 01:46:41 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 01:46:41 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35863068.FF687D71@e.kth.se> Date: Tue, 16 Jun 1998 10:44:24 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: CVS stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KdNAw3.0.Vy1.m3ZXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2819 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Steve Cheng wrote: > Anyway, libggi compile in the devel tree is currently broken. It doesn't > seem to set $LIBGGI_TOPLEVEL / $TOPLEVEL correctly. Could someone please > fix that? Yes, I forgot to change TOPLEVEL -> LIBGGI_TOPLEVEL in config/rules/Linux. I tried to commit a fix together with some other stuff last night, but after waiting 30 minutes for the commit to finish i gave up. I really hope the CVS server feels better tonight... //Marcus From ggi-develop-request@eskimo.com Tue Jun 16 02:20:37 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA09534; Tue, 16 Jun 1998 02:20:29 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA11630; Tue, 16 Jun 1998 02:08:07 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 02:08:07 -0700 (PDT) X-Sender: ortalo@poptsf.laas.fr Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Eudora Pro F3.1.3 Date: Tue, 16 Jun 1998 11:08:13 +0200 To: ggi-develop@eskimo.com From: Rodolphe Ortalo Subject: LibGGI on M$-Win Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mx2.eskimo.com id CAA11606 Resent-Message-ID: <"mCm7w3.0.br2.rNZXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2820 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello, I've been contacted by someone who might be interested in (and has the knowledge to work on) a port of libggi to the M$-Win target. If I remember well, someone once told about a port of libggi to DirectX, etc... Could you indicate me the people I should indicate to this person (whose name is Robert M. Münch ) ? Thanks, Rodolphe From ggi-develop-request@eskimo.com Tue Jun 16 03:16:08 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA09712; Tue, 16 Jun 1998 03:16:04 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA17160; Tue, 16 Jun 1998 03:09:39 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 03:09:39 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806161007.MAA28203@sunserver1.rz.uni-duesseldorf.de> Subject: Re: LibGGI on M$-Win In-Reply-To: from Rodolphe Ortalo at "Jun 16, 98 11:08:13 am" To: ggi-develop@eskimo.com Date: Tue, 16 Jun 1998 12:07:02 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"MI-th3.0.zB4.XHaXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2822 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I've been contacted by someone who might be interested in (and has > the knowledge to work on) a port of libggi to the M$-Win target. Hey Macrena :-) ! > If I remember well, someone once told about a port of libggi to > DirectX, etc... Could you indicate me the people I should indicate > to this person (whose name is Robert M. Münch ) ? You can name me for answering questions regarding LibGGI. I think Stefan or Marcus were also involved, plus I think Thomas ... Get him on board - I _waaaant_ that target desperately ... CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Tue Jun 16 03:29:06 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA09746; Tue, 16 Jun 1998 03:29:03 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA16563; Tue, 16 Jun 1998 03:07:05 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 03:07:05 -0700 (PDT) From: Steffen Seeger Message-Id: <199806161002.MAA14204@shubashi.physik.tu-chemnitz.de> Subject: Re: CVS stuff In-Reply-To: <199806160732.JAA03565@cip8.e-technik.uni-erlangen.de> from Hartmut Niemann at "Jun 16, 98 09:32:51 am" To: ggi-develop@eskimo.com Date: Tue, 16 Jun 1998 12:02:23 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uBlxn3.0.h24.7FaXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2821 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Argh! > > > > Is there ANY reason to have the docs in all formats in the > > CVS tree? > > For the devel branch I can't see any point in having anything > > other than the SGML source in CVS. > > Having other formats are just more to download. > > > > //Marcus > > Yes there are two. > 1) nobody complained when I asked what to commit. > Most of them should not show up in the tarballs, I hope. > 2) There are some bugs in sgml-tools, at least two of which are > fixed in the version I use ( in section headlines in sgml2txt, > in tex/dvi/ps). Maybe the fixes make it into 1.0.7 > 3) I planned looking into the new DocBook-based sgml-tools 1.1 as > soon as they look stable, at that point you couln't expect > anybody to download and install them. > 4) I don't want to force anybody to download and install yet another > package jsut to format and read the documentation. > Sometimes the only way for getting feedback is simply to do it > and wait for the complaints ... > > Hartmut. > -- > Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de > http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] AFAIR (As far as I remember) we agreed to *only* have sgml sources in the repository. CVS is for developers, and I expect them to have the neccessary tools installed. Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- ------------- The GGI Project: http://www.ggi-project.org ------------- ----------------- http: http://www.tu-chemnitz.de/~sse ----------------- From ggi-develop-request@eskimo.com Tue Jun 16 04:30:41 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA09959; Tue, 16 Jun 1998 04:30:35 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA25018; Tue, 16 Jun 1998 04:12:03 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 04:12:03 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3586524F.12B25D56@e.kth.se> Date: Tue, 16 Jun 1998 13:09:03 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: CVS stuff References: <199806161002.MAA14204@shubashi.physik.tu-chemnitz.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"vQDLn2.0.m66.1CbXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2823 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Steffen Seeger wrote: > AFAIR (As far as I remember) we agreed to *only* have sgml sources in > the repository. CVS is for developers, and I expect them to have the > neccessary tools installed. Yes, that was my thought too. Having the plaintext version might be ok as it won't take much space and may come in handy if you want to check some topic you're not familiar with, but that's it. I almost fell of my chair when I found DVI and PS versions in the repository yesterday. ;) //Marcus From ggi-develop-request@eskimo.com Tue Jun 16 04:33:24 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA09966; Tue, 16 Jun 1998 04:33:20 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA27741; Tue, 16 Jun 1998 04:28:49 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 04:28:49 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35865671.6F0B084E@e.kth.se> Date: Tue, 16 Jun 1998 13:26:41 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: LibGGI on M$-Win References: <199806161007.MAA28203@sunserver1.rz.uni-duesseldorf.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"sVypG3.0.Jn6.kRbXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2824 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com becka@rz.uni-duesseldorf.de wrote: > > Hi ! > > > I've been contacted by someone who might be interested in (and has > > the knowledge to work on) a port of libggi to the M$-Win target. > > Hey Macrena :-) ! > > > If I remember well, someone once told about a port of libggi to > > DirectX, etc... Could you indicate me the people I should indicate > > to this person (whose name is Robert M. Münch ) ? > > You can name me for answering questions regarding LibGGI. > > I think Stefan or Marcus were also involved, plus I think Thomas ... Stefan started on a DirectX wrapper for libggi some months ago but IIRC he hasn't had any more time to work on it. I made libggi compile in the CYGWIN32 environment some months ago, but there's some trouble with dynamic loading. Actually I'm planning to fix this now, if I only could get my boot.ini right so I don't have to reinstall NT... Anyone now what /dev/hdd5 is supposed to be translated to in NT's boot.ini ? (Partition is F: in NT, I also have a /dev/hda HD and a /dev/hdc CDROM, I have a /dev/hdd2 FAT partition also) Hmm, wasn't Thomas the one that worked on a DOS port ? //Marcus From ggi-develop-request@eskimo.com Tue Jun 16 04:46:46 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA09996; Tue, 16 Jun 1998 04:46:43 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA28412; Tue, 16 Jun 1998 04:34:40 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 04:34:40 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <358657AA.29A4936B@e.kth.se> Date: Tue, 16 Jun 1998 13:31:54 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: andreas.beck@ggi-project.org, ggi-develop@eskimo.com Subject: Re: GGI license - draft #4 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"IbKzq1.0.qx6.EXbXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2825 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com becka@rz.uni-duesseldorf.de wrote: > 4. Commercial licensing > > Commercial licenses usually contain one or more of the following regulations: > > 4.1. Give out binary-only packages. > > This is o.k. as long as the pointer to the free source the package was > derived from is maintained and additional restrictions from other licenses > (like making source available for GPLed parts) are observed. > > 4.2. Deny redistribution of the product. > > The same applies here. Redistribution cannot be denied for GPLed parts > and pointers to the original sources need to be included. I've been quite busy lately and havent really kept up with the license debate, so what is going to be covered by the GGI license? I certainly don't want to release code I have written under that license. I don't having anything aginst commercial apps using libggi, and binary HW drivers are ok, although not preferable. But I definitely don't want vendor Foo to take code I have written parts of, add some proprietary stuff, and release a commercial libggi PLUS, which from there of most applications will take advantage of (maybe beacause that it contains som small patented algorithm that makes it faster)! For libggi I'd like people to be able to link their code both static and dynamic to an _unmodifed_ library, and distribute it under something like the above license. But as soon as they start modifying the actual libggi code I see no reason they shouldn't release the source. //Marcus From ggi-develop-request@eskimo.com Tue Jun 16 04:57:00 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA10035; Tue, 16 Jun 1998 04:56:56 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA12863; Tue, 16 Jun 1998 04:41:32 -0700 Resent-Date: Tue, 16 Jun 1998 04:41:32 -0700 From: Hartmut Niemann Message-Id: <199806161141.NAA10275@cip8.e-technik.uni-erlangen.de> Subject: Re: CVS stuff To: ggi-develop@eskimo.com Date: Tue, 16 Jun 1998 13:40:54 +0200 (MESZ) In-Reply-To: <199806161002.MAA14204@shubashi.physik.tu-chemnitz.de> from "Steffen Seeger" at Jun 16, 98 12:02:23 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"LarsA2.0.t83.idbXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2826 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > > > Argh! > > > > > > Is there ANY reason to have the docs in all formats in the > > > CVS tree? > > > For the devel branch I can't see any point in having anything > > > other than the SGML source in CVS. > > > Having other formats are just more to download. > > > > > > //Marcus > > > > Yes there are two. > > 1) nobody complained when I asked what to commit. > > Most of them should not show up in the tarballs, I hope. > > 2) There are some bugs in sgml-tools, at least two of which are > > fixed in the version I use ( in section headlines in sgml2txt, > > in tex/dvi/ps). Maybe the fixes make it into 1.0.7 > > 3) I planned looking into the new DocBook-based sgml-tools 1.1 as > > soon as they look stable, at that point you couln't expect > > anybody to download and install them. > > 4) I don't want to force anybody to download and install yet another > > package jsut to format and read the documentation. > > Sometimes the only way for getting feedback is simply to do it > > and wait for the complaints ... > > > > Hartmut. > > -- > > Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de > > http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] > > AFAIR (As far as I remember) we agreed to *only* have sgml sources in > the repository. CVS is for developers, and I expect them to have the > neccessary tools installed. > > > Steffen > Of course we can remove everything but the sgml sources. Just Steffen, Emmanuel and Andy you have to agree on what to do, and do it, or I'll do it. (But please tell me.) But don't complain too loudly if you can't get it to convert properly ... or if people start asking the same old questions over and over again. Just a reminder: sgmltools 1.0 requires perl 5.004. Did you ever wonder how the Linux HOWTOs are made? did you ever convert one yourself? I didn't. And I wouldn't want to require that from GGI users and/or developers. I do think it is reasonable that a GGI developer has gcc installed, but i don't think it is reasonable to assume that a ggi developer has sgml-tools, a new perl and teTeX installed just to get a postscript version of a document. I thought /doc is my playground and that I *had* asked for input often enough. Slightly disappointed, Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Tue Jun 16 06:39:58 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA10425; Tue, 16 Jun 1998 06:39:54 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA17130; Tue, 16 Jun 1998 06:33:22 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 06:33:22 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: I'll be gone for a bit... Date: 16 Jun 1998 13:28:17 GMT Organization: OnTV Pittsburgh, L.P. Lines: 14 Sender: Jason McMullan Message-ID: <6m5rth$c6i$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.32 (i586)) Resent-Message-ID: <"4WcSg.0.WB4.VGdXr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2827 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I will be gone for a bit. My marriage just shot itself all to hell. I hope to be back in a few weeks. God is a comedian. God is not funny. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Tue Jun 16 06:40:29 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA10431; Tue, 16 Jun 1998 06:40:21 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA17719; Tue, 16 Jun 1998 06:35:57 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 06:35:57 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35867308.7D019EA5@e.kth.se> Date: Tue, 16 Jun 1998 15:28:40 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: CVS stuff References: <199806161141.NAA10275@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"wQdow3.0.iK4.uIdXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2828 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > Of course we can remove everything but the sgml sources. > Just Steffen, Emmanuel and Andy you have to agree on what to do, and do it, > or I'll do it. (But please tell me.) > > But don't complain too loudly if you can't get it to convert properly ... > or if people start asking the same old questions over and over again. > > Just a reminder: sgmltools 1.0 requires perl 5.004. > > Did you ever wonder how the Linux HOWTOs are made? did you ever convert one > yourself? I didn't. And I wouldn't want to require that from GGI > users and/or developers. I do think it is reasonable that a GGI developer has > gcc installed, but i don't think it is reasonable to assume that a ggi developer > has sgml-tools, a new perl and teTeX installed just to get a postscript > version of a document. > > I thought /doc is my playground and that I *had* asked for input often > enough. > > Slightly disappointed, Hartmut. Well, the CVS repository's primary function is development. We don't have binaries for every supported platform in it, so I don't see why we should have the docs in all formats. This will just slow down updating. On the other hand I think you are doing a great job with the docs, so I hate to see you disappointed. I suggest that we keep only SGML docs in the repository, and then you can upload docs in other format's to our FTP site once a week. That way you don't have to update the full docs for every little change in the SGML source. Another option is to move the entire doc tree to a separate toplevel directory in the repository. //Marcus From ggi-develop-request@eskimo.com Tue Jun 16 08:20:08 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA10835; Tue, 16 Jun 1998 08:20:01 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA06919; Tue, 16 Jun 1998 08:05:21 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 08:05:21 -0700 (PDT) Date: Tue, 16 Jun 1998 09:38:15 -0400 (EDT) From: Steve Cheng Sender: steve@maxt4m21.ipoline.com To: ggi-develop@eskimo.com Subject: Re: LibGGI on M$-Win In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mx2.eskimo.com id IAA06854 Resent-Message-ID: <"ejkpO1.0.th1.jceXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2829 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 16 Jun 1998, Rodolphe Ortalo wrote: > Hello, > > I've been contacted by someone who might be interested in (and has > the knowledge to work on) a port of libggi to the M$-Win target. > > If I remember well, someone once told about a port of libggi to > DirectX, etc... Could you indicate me the people I should indicate > to this person (whose name is Robert M. Münch ) ? Arrghh... if you're talking about me (who said I was going to do a DirectX target), sorry, I can't do it any longer. Win32 is just excruciating, and I don't even have access to it anymore since NT died on me. Please let him proceed. -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Tue Jun 16 10:11:49 1998 Return-Path: Received: from mx2.eskimo.com (root@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA11357; Tue, 16 Jun 1998 10:11:36 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA28317; Tue, 16 Jun 1998 09:42:24 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 09:42:24 -0700 (PDT) X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Tue, 16 Jun 1998 18:39:23 +0200 (MET DST) From: Stefan Mars To: ggi-develop@eskimo.com Subject: Re: LibGGI on M$-Win In-Reply-To: <35865671.6F0B084E@e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"l081W1.0.Gw6.h1gXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2830 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 16 Jun 1998, Marcus Sundberg wrote: > becka@rz.uni-duesseldorf.de wrote: > > I think Stefan or Marcus were also involved, plus I think Thomas ... > > Stefan started on a DirectX wrapper for libggi some months ago > but IIRC he hasn't had any more time to work on it. Nope, but during the summer I probably will have time for it. Pray for rainy days (there is this girl...) :) -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From ggi-develop-request@eskimo.com Tue Jun 16 13:00:59 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA11613; Tue, 16 Jun 1998 13:00:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA08542; Tue, 16 Jun 1998 12:57:31 -0700 Resent-Date: Tue, 16 Jun 1998 12:57:31 -0700 Sender: thomas@eskimo.com Message-ID: <3586CCFA.665B9FBD@gmx.de> Date: Tue, 16 Jun 1998 21:52:26 +0200 From: Thomas Tanner X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: LibGGI on M$-Win References: <199806161007.MAA28203@sunserver1.rz.uni-duesseldorf.de> <35865671.6F0B084E@e.kth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"LN0El2.0.L52.guiXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2831 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Marcus Sundberg wrote: > > > I've been contacted by someone who might be interested in (and has > > > the knowledge to work on) a port of libggi to the M$-Win target. > Hmm, wasn't Thomas the one that worked on a DOS port ? Not a DOS port, but I worked on a dynamic library loading scheme that makes the porting of libggi to statically linked systems like DOS possible and simplifies the port to non Unix system (libdl) like Windoze (.dll). The code is in my personal degas snapshot and I'll put on my homepage soon [I'm pretty busy this week ;(] -- Thomas Tanner ----------------------------- email: tanner@gmx.de tanner@ggi-project.org web: http://home.pages.de/~tanner GGI: http://www.ggi-project.org From ggi-develop-request@eskimo.com Tue Jun 16 13:29:20 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA11634; Tue, 16 Jun 1998 13:29:12 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA19024; Tue, 16 Jun 1998 13:30:07 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 13:30:07 -0700 (PDT) X-Authentication-Warning: mir.inazuma.dyn.ml.org: tetron owned process doing -bs Date: Tue, 16 Jun 1998 16:31:00 -0400 (EDT) From: Peter Amstutz X-Sender: amstpi@mir.inazuma.dyn.ml.org Reply-To: amstpi@freenet.tlh.fl.us To: becka@rz.uni-duesseldorf.de cc: ggi-develop@eskimo.com Subject: Re: little bug In-Reply-To: <199806160726.JAA18435@sunserver1.rz.uni-duesseldorf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"h-2TW2.0.1f4.ANjXr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2832 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 16 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Hi ! > > > degas/lib/libggi/extensions/misc/display/svgalib/mode.c > > defines GGIwaitraypos. I don't think it goes here, it's suppose to be in > > another library, right? > > The lib is right ... It should go to LibGGImisc. ok, so libggi/extensions/misc/ is the right place for libggimisc? Actually, GGIgetraypos is defined twice, once where I mention above, and again in libggi/display/svgalib - where I don't think it goes at all. > > Anyway, it's currently tripping up compilation of libggi, and should be > > moved or commented out. > > What happens ? I can't test SVGAlib and thus trusted the one who made the > patch ... I'll check it out anyway ... Actually, the problem is that GGIRP_SYNC and GGIRP_DONTCARE are #ifdef 0'd out of libggi.h. They are in the file "ext" (not "ext.h" or "libggi_ext.h", just "ext" in /usr/local/include/ggi). I'd contribute patches but I'm not quite sure what goes where in the current grand scheme of things. I should probably get access to the devel cvs one of these days, too :) Oh, ggiDrawCircle() is still in libggi. We should bring in libggi2d and get rid of ggiDrawCircle once and for all. Letting it linger is just going to make more programs use it, until it becomes a de factor standard that can't be taken out. Actually, I'd even prefer to see it in there because a basic circledraw is useful, but we really want to get to an API set in stone, and avoid these lingering bits. Oh, on building libggi... I was on IRC and got a couple people interested in it, and one commented that he didn't like a "silent build", that is, all the make messages are redirected to a log file, so one doesn't get to see what's going on. Maybe piping through "tee" (reads stdin, writes to stdout AND a file) would be useful here? I'll take a look at it... Peter Amstutz /* E-mail: amstpi@freenet.tlh.fl.us Home Page: http://www.freenet.tlh.fl.us/~amstpi/ Geek Code: (see http://www.geekcode.com/ for decoding instructions) GCS d- s:+ a--- C++>$ UL++++>$ P+(++) L++>$ E W++ N+ !o K w-- !O M-() !V PS+(++) PE-(--) Y+ PGP t 5++ X+ R tv b+ DI+ D++ G e h */ From ggi-develop-request@eskimo.com Tue Jun 16 15:34:43 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA11771; Tue, 16 Jun 1998 15:34:38 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA08309; Tue, 16 Jun 1998 15:28:53 -0700 Resent-Date: Tue, 16 Jun 1998 15:28:53 -0700 Date: Tue, 16 Jun 1998 18:34:14 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: GGI license - draft #4 In-Reply-To: <199806162223.SAA12760@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"15xU23.0.h12.a6lXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2833 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 16 Jun 1998, Marcus Sundberg wrote: > But I definitely don't want vendor Foo to take code I have > written parts of, add some proprietary stuff, and release > a commercial libggi PLUS, which from there of most applications > will take advantage of (maybe beacause that it contains > som small patented algorithm that makes it faster)! > > For libggi I'd like people to be able to link their code > both static and dynamic to an _unmodifed_ library, and > distribute it under something like the above license. > But as soon as they start modifying the actual libggi code > I see no reason they shouldn't release the source. How do the BSD licenses deal with this situation, just out of curiousity? -=MenTaLguY=- From ggi-develop-request@eskimo.com Tue Jun 16 18:21:24 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA11938; Tue, 16 Jun 1998 18:21:21 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA16069; Tue, 16 Jun 1998 18:09:11 -0700 Resent-Date: Tue, 16 Jun 1998 18:09:11 -0700 Date: Tue, 16 Jun 1998 20:07:42 -0500 (CDT) From: "Edward S. Marshall" To: Steffen Seeger Cc: ggi-develop@eskimo.com Subject: Re: CVS stuff In-Reply-To: <199806161002.MAA14204@shubashi.physik.tu-chemnitz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"j4txo2.0.tw3.sSnXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2834 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 16 Jun 1998, Steffen Seeger wrote: > AFAIR (As far as I remember) we agreed to *only* have sgml sources in > the repository. CVS is for developers, and I expect them to have the > neccessary tools installed. How about in the main degas tree, we keep only sgml sources, and a separate doc tree for the converted forms of the docs, so that people can get those if they need them? That way, Hartmut can still commit generated documentation (since he's probably the only one with the tools to do it right now), and those who don't want to wait on updating the generated docs don't have to; they can just skip updating the toplevel "doc" tree. -- -------------------. emarshal at logic.net .--------------------------------- Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/ Linux labyrinth 2.1.105 #8 SMP Thu Jun 11 23:08:37 CDT 1998 i586 unknown 8:05pm up 1 day, 5:36, 3 users, load average: 0.00, 0.07, 0.09 From ggi-develop-request@eskimo.com Tue Jun 16 19:23:36 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA11957; Tue, 16 Jun 1998 19:23:28 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA05626; Tue, 16 Jun 1998 19:14:26 -0700 (PDT) Resent-Date: Tue, 16 Jun 1998 19:14:26 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: GGI license - draft #4 To: ggi-develop@eskimo.com Date: Tue, 16 Jun 1998 19:34:07 +0200 (MET DST) In-Reply-To: <358657AA.29A4936B@e.kth.se> from "Marcus Sundberg" at Jun 16, 98 01:31:54 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"YHdfL.0.lN1.-PoXr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2836 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I've been quite busy lately and havent really kept up with the > license debate, so what is going to be covered by the GGI license? I would like to have as much as possible covered by it. It seems that there is demand for covering LibGGI and a few basic extensions with LGPL, which is fine with me. > I certainly don't want to release code I have written under > that license. O.K. - what code would be affected ? LibGGI code should be safe, as it looks like it will be LGPL. > I don't having anything aginst commercial apps using libggi, > and binary HW drivers are ok, although not preferable. So you would accept that license for HW drivers - right ? > But I definitely don't want vendor Foo to take code I have > written parts of, add some proprietary stuff, and release > a commercial libggi PLUS, which from there of most applications > will take advantage of (maybe beacause that it contains > som small patented algorithm that makes it faster)! Ugh - software patents ... yeah ... hope they finally tilt that law ... Except for such a case, we should be safe, I think, as explained in some commentary mails: If the "PLUS" is really good, why not letting them make a bit of money from it until we have catched up. They'll at least deliver an idea to us ... If it ain't good, noone will use it. > For libggi I'd like people to be able to link their code > both static and dynamic to an _unmodifed_ library, and > distribute it under something like the above license. > But as soon as they start modifying the actual libggi code > I see no reason they shouldn't release the source. Well - what about adding drivers and such - should they be allowed to make binary-only Libggi-target modules or drivers ? LibGGI as said, will probably be safe ... CU, ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 16 19:37:22 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA11962; Tue, 16 Jun 1998 19:37:21 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA22605; Tue, 16 Jun 1998 19:02:01 -0700 Resent-Date: Tue, 16 Jun 1998 19:02:01 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: CVS stuff To: ggi-develop@eskimo.com Date: Tue, 16 Jun 1998 19:25:35 +0200 (MET DST) In-Reply-To: <199806161141.NAA10275@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at Jun 16, 98 01:40:54 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"gt4T92.0.4X5.OEoXr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2835 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Of course we can remove everything but the sgml sources. > Just Steffen, Emmanuel and Andy you have to agree on what to do, and do it, > or I'll do it. (But please tell me.) I actually do not care. However I think, that at least for the snapshots, a nicely readable and crosslinked version like html would be good as well as a printable one (at least for bigger documents). Maybe we can tweak CVS in a way that you have to explicitly ask for docs or something ... An idea would be a simple script doing cd $(TOPLEVEL)/lib cvs update -PAd cd $(TOPLEVEL)/os cvs update -PAd cd $(TOPLEVEL)/config cvs update -PAd etc., leaving out docs. It could even be placed in the main Makefile ... CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 16 21:32:03 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA12049; Tue, 16 Jun 1998 21:32:00 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id VAA15192; Tue, 16 Jun 1998 21:26:34 -0700 Resent-Date: Tue, 16 Jun 1998 21:26:34 -0700 From: bkosse@iname.com Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 16 Jun 1998 21:25:48 -0700 (PDT) Reply-To: bkosse@iname.com Sender: ben@wyrmslayer.warewolf.com To: ggi-develop@eskimo.com Subject: Re: CVS stuff Resent-Message-ID: <"cgaJR3.0.Gj3.wLqXr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2837 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I actually do not care. However I think, that at least for the snapshots, > a nicely readable and crosslinked version like html would be good as well > as a printable one (at least for bigger documents). To be honest, my preferred format for reading programming docs on the computer is pure text. I'll print out the postscript and such, but on the computer itself (and often, if the doc writer did a good job, I'll just print out the text docs and ignore the postscript). -- Ben Kosse http://www.rit.edu/~bmk7411 The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- Nietzsche From ggi-develop-request@eskimo.com Wed Jun 17 01:06:58 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA12279; Wed, 17 Jun 1998 01:06:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA13870; Wed, 17 Jun 1998 01:09:55 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 01:09:55 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3587795A.D792644A@e.kth.se> Date: Wed, 17 Jun 1998 10:07:54 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: GGI license - draft #4 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"bAjoy.0.ZO3.EdtXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2838 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com becka@rz.uni-duesseldorf.de wrote: > > Hi ! > > > I've been quite busy lately and havent really kept up with the > > license debate, so what is going to be covered by the GGI license? > > I would like to have as much as possible covered by it. > > It seems that there is demand for covering LibGGI and a few basic > extensions with LGPL, which is fine with me. > > > I certainly don't want to release code I have written under > > that license. > > O.K. - what code would be affected ? LibGGI code should be safe, as it > looks like it will be LGPL. Ok, libggi being LGPL is fine. Should you find anything I've written outside the lib/ subtree you can put any licence you want on it, as it will only be minor stuff. > > I don't having anything aginst commercial apps using libggi, > > and binary HW drivers are ok, although not preferable. > > So you would accept that license for HW drivers - right ? Well, I haven't written any HW drivers, but if I had I wouldn't like them to use that licence, simply because I can't think of any case where I would like someone to distribute a modified copy of my code without contributing the changes back to tho OpenSource community. What's the problem with putting HW drivers under LGPL ? > > But I definitely don't want vendor Foo to take code I have > > written parts of, add some proprietary stuff, and release > > a commercial libggi PLUS, which from there of most applications > > will take advantage of (maybe beacause that it contains > > som small patented algorithm that makes it faster)! > > Ugh - software patents ... yeah ... hope they finally tilt that > law ... > > Except for such a case, we should be safe, I think, as explained > in some commentary mails: > > If the "PLUS" is really good, why not letting them make a bit of > money from it until we have catched up. They'll at least deliver > an idea to us ... People making money from applications using GGI is just fine, but I honestly don't see any point in letting people make money from _our_ code. > If it ain't good, noone will use it. Ouch, can't believe you said that. Think VHS, Windows, you name it... ;) > > For libggi I'd like people to be able to link their code > > both static and dynamic to an _unmodifed_ library, and > > distribute it under something like the above license. > > But as soon as they start modifying the actual libggi code > > I see no reason they shouldn't release the source. > > Well - what about adding drivers and such - should they be allowed to make > binary-only Libggi-target modules or drivers ? Yes, I have no problem with that, as long as they don't steal code from existing targets. (To aid people writing new targets we should make a skeleton for a libggi target available under a PD license) //Marcus From ggi-develop-request@eskimo.com Wed Jun 17 01:20:52 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA12288; Wed, 17 Jun 1998 01:20:51 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA06812; Wed, 17 Jun 1998 01:14:47 -0700 Resent-Date: Wed, 17 Jun 1998 01:14:47 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35877B07.6D3700DD@e.kth.se> Date: Wed, 17 Jun 1998 10:15:03 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: little bug References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0pPja.0.Kg1.shtXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2839 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Peter Amstutz wrote: > Oh, on building libggi... I was on IRC and got a couple people > interested in it, and one commented that he didn't like a "silent build", > that is, all the make messages are redirected to a log file, so one > doesn't get to see what's going on. Maybe piping through "tee" (reads > stdin, writes to stdout AND a file) would be useful here? I'll take a > look at it... He's not the only one. Honestly I don't see any reason for a silent bulid, unless you're compiling on a 600 MHz Alpha, logged in with a 300baud Modem. ;) //Marcus From ggi-develop-request@eskimo.com Wed Jun 17 01:40:09 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA12310; Wed, 17 Jun 1998 01:40:02 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA18144; Wed, 17 Jun 1998 01:40:57 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 01:40:57 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806170838.KAA20559@cip8.e-technik.uni-erlangen.de> Subject: Re: GGI license - draft #4 To: ggi-develop@eskimo.com Date: Wed, 17 Jun 1998 10:38:41 +0200 (MESZ) In-Reply-To: <3587795A.D792644A@e.kth.se> from "Marcus Sundberg" at Jun 17, 98 10:07:54 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"11ALL.0.OR4.N4uXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2840 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > What's the problem with putting HW drivers under LGPL ? > Short answer: You can't make LGPL'ed code part of a non-GPLed OS source tree. Long answer: ... see the mailing archive. Angry answer suppressed :-) -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 17 01:58:28 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA12338; Wed, 17 Jun 1998 01:58:25 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA18899; Wed, 17 Jun 1998 01:48:07 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 01:48:07 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806170845.KAA20789@cip8.e-technik.uni-erlangen.de> Subject: Re: CVS stuff To: andreas.beck@ggi-project.org Date: Wed, 17 Jun 1998 10:45:08 +0200 (MESZ) Cc: ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jun 16, 98 07:25:35 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"K0r2k3.0.Bd4.4BuXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2841 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Compromise: we'll put only sgml, txt, html and dvi into the CVS and the snapshots (that makes uncompressed volume go down from 3M to <1M). I have put a copy of the html tree onto my homepage, along with tar.gz's of all types (txt, sgml, html, tex, dvi, ps). You'l find the link from our ggi home page->links->misc links->more links. Now somebody has to tell me how to remove files and directories from a CVS. Hartmut, waiting for orders. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 17 02:19:00 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA12404; Wed, 17 Jun 1998 02:18:58 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id CAA08912; Wed, 17 Jun 1998 02:11:01 -0700 Resent-Date: Wed, 17 Jun 1998 02:11:01 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35878833.FBE7ADE8@e.kth.se> Date: Wed, 17 Jun 1998 11:11:15 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: GGI license - draft #4 References: <199806170838.KAA20559@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ndBis1.0.3B2.aWuXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2842 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > > > > > What's the problem with putting HW drivers under LGPL ? > > > Short answer: You can't make LGPL'ed code part of a non-GPLed > OS source tree. > Long answer: ... see the mailing archive. > Angry answer suppressed :-) Well, I guess I'll just have to read the LGPL properly. However I seriously doubt that it regulates where in a directory structure you may place the code... //Marcus From ggi-develop-request@eskimo.com Wed Jun 17 02:30:32 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA12424; Wed, 17 Jun 1998 02:30:30 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA22723; Wed, 17 Jun 1998 02:22:06 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 02:22:06 -0700 (PDT) Sender: core@orb.suntech.fr Message-ID: <35878920.1DBAA71E@suntech.fr> Date: Wed, 17 Jun 1998 09:15:12 +0000 From: Emmanuel Marty Reply-To: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: CVS stuff References: <199806170845.KAA20789@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"thWmd1.0.xY5.yguXr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2843 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > Compromise: > we'll put only sgml, txt, html and dvi into the CVS and the snapshots > (that makes uncompressed volume go down from 3M to <1M). I personally liked to have all docs formats in the CVS repository, and noonehad objected when Hartmut _did_ ask to the list, but ... > I have put a copy of the html tree onto my homepage, along with > tar.gz's of all types (txt, sgml, html, tex, dvi, ps). > You'l find the link from our ggi home page->links->misc links->more links. I could create a CVS repository for the docs, if you like, but then again thatmight not be a good idea (docs won't be in sync with the version they document ..) > Now somebody has to tell me how to remove files and directories from > a CVS. First rm the file locally, then do cvs remove filename, then cvs commit filename. It won't actually be deleted from the server, it will be put in the attic, and can stillbe retrieved if you update from the repository at a given previous date. > Hartmut, waiting for orders. Hmm, I don't want you to think you're being imposed things - you've always been doing a great job at documenting and you deserve to manage things the way you like :) -- Emmanuel From ggi-develop-request@eskimo.com Wed Jun 17 02:43:05 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA12449; Wed, 17 Jun 1998 02:43:03 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA24810; Wed, 17 Jun 1998 02:40:16 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 02:40:16 -0700 (PDT) Date: Wed, 17 Jun 1998 11:31:50 +0200 (MET DST) From: Rodolphe Ortalo X-Sender: ortalo@verdi To: ggi-develop@eskimo.com Subject: Re: LibGGI on M$-Win In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Resent-Message-ID: <"EbSUu1.0.U36.zxuXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2844 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > On Tue, 16 Jun 1998, Rodolphe Ortalo wrote: > > > Hello, > > > > I've been contacted by someone who might be interested in (and has > > the knowledge to work on) a port of libggi to the M$-Win target. > > > > If I remember well, someone once told about a port of libggi to > > DirectX, etc... Could you indicate me the people I should indicate > > to this person (whose name is Robert M. Münch ) ? Well, so who should I direct him at if he wants to proceed ? (Volunteers should take care of him... ;-) Proposal: Stefan Mars (as he knows the MS issue from the inside) me or Jon Taylor (for inevitable general questions wrt GGI) Andreas "MadArena" Beck (in case the former people are outperformed) Rodolphe From ggi-develop-request@eskimo.com Wed Jun 17 03:53:35 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA12488; Wed, 17 Jun 1998 03:53:24 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA01203; Wed, 17 Jun 1998 03:41:02 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 03:41:02 -0700 (PDT) From: Steffen Seeger Message-Id: <199806171036.MAA02668@legrelle.physik.tu-chemnitz.de> Subject: Re: CVS stuff In-Reply-To: <199806170845.KAA20789@cip8.e-technik.uni-erlangen.de> from Hartmut Niemann at "Jun 17, 98 10:45:08 am" To: ggi-develop@eskimo.com Date: Wed, 17 Jun 1998 12:36:12 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"fbwTS3.0.YI.xqvXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2845 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Compromise: > we'll put only sgml, txt, html and dvi into the CVS and the snapshots > (that makes uncompressed volume go down from 3M to <1M). I would further restrict it to sgml and txt, _possibly_ html. Everything else could be generated once a week and put up a web/ftp site for download. Please remember that some people are using a modem to get the update, and 3MB (even analyzing 3MB) takes some time. Event over ISDN I think twice before downloading 3 MB. > I have put a copy of the html tree onto my homepage, along with > tar.gz's of all types (txt, sgml, html, tex, dvi, ps). > You'l find the link from our ggi home page->links->misc links->more links. > > Now somebody has to tell me how to remove files and directories from > a CVS. first delete them in your checkout, the do a 'cvs delete ' (yes, you have to do it for each file separately, in each subdir separately) and finally commit. This is another reason I suggested only to have the sgml sources in there. If you decide to reorganize things, you don't have to move a dozen of files that all carry the same info. But it's up to you. You have to keep things conistent for the docs. ;-) Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- From ggi-develop-request@eskimo.com Wed Jun 17 05:21:41 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA12530; Wed, 17 Jun 1998 05:21:39 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA20269; Wed, 17 Jun 1998 05:11:47 -0700 Resent-Date: Wed, 17 Jun 1998 05:11:47 -0700 Sender: duff@eskimo.com Message-ID: <3587B270.C9876618@cip.informatik.uni-erlangen.de> Date: Wed, 17 Jun 1998 14:11:28 +0200 From: Andreas Vogler X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.105 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: little bug References: <35877B07.6D3700DD@e.kth.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mx1.eskimo.com id FAA20215 Resent-Message-ID: <"HuZdF3.0.ay4.3AxXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2846 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Marcus Sundberg wrote: > > Peter Amstutz wrote: > > Oh, on building libggi... I was on IRC and got a couple people > > interested in it, and one commented that he didn't like a "silent build", > > that is, all the make messages are redirected to a log file, so one > > doesn't get to see what's going on. Maybe piping through "tee" (reads > > stdin, writes to stdout AND a file) would be useful here? I'll take a > > look at it... > > He's not the only one. > Honestly I don't see any reason for a silent bulid, unless you're > compiling on a 600 MHz Alpha, logged in with a 300baud Modem. ;) Well, the idea was to hide all complicated parts from newbie users, but if a lot of people agree on it, it shouldn´t be a problem to leave make output on the screen and to not hide it. Andreas -- / \ "All that we see or seem \ / / \ is but a dream within a dream" E.A. Poe \ / From ggi-develop-request@eskimo.com Wed Jun 17 06:27:17 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA12570; Wed, 17 Jun 1998 06:27:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA26248; Wed, 17 Jun 1998 06:16:24 -0700 Resent-Date: Wed, 17 Jun 1998 06:16:24 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806171303.PAA05427@sunserver1.rz.uni-duesseldorf.de> Subject: Re: little bug In-Reply-To: <3587B270.C9876618@cip.informatik.uni-erlangen.de> from Andreas Vogler at "Jun 17, 98 02:11:28 pm" To: ggi-develop@eskimo.com Date: Wed, 17 Jun 1998 15:03:22 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hVPmZ1.0.0Q6.d6yXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2847 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > Oh, on building libggi... I was on IRC and got a couple people > > > interested in it, and one commented that he didn't like a "silent build", > > He's not the only one. > Well, the idea was to hide all complicated parts from newbie users, but Well - actually that's how it is. If you build from the toplevel make using the "newbie approach", you'll get a silent build. If you do "make" from the libggi subdirectory (as I thought any hacker would do - I even do make config by "joe .config" ...), you will get a verbose build. So what's the problem ? Maybe adding this info to the FAQ ? CU,ANdy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Wed Jun 17 06:44:15 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA12598; Wed, 17 Jun 1998 06:44:13 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA26884; Wed, 17 Jun 1998 06:19:30 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 06:19:30 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806171309.PAA05789@sunserver1.rz.uni-duesseldorf.de> Subject: Re: GGI license - draft #4 In-Reply-To: <35878833.FBE7ADE8@e.kth.se> from Marcus Sundberg at "Jun 17, 98 11:11:15 am" To: ggi-develop@eskimo.com Date: Wed, 17 Jun 1998 15:09:14 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"oYejh.0.wZ6.W9yXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2848 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > What's the problem with putting HW drivers under LGPL ? > > Short answer: You can't make LGPL'ed code part of a non-GPLed > > OS source tree. > > Long answer: ... see the mailing archive. > > Angry answer suppressed :-) > > Well, I guess I'll just have to read the LGPL properly. The problem is not on the LGPL side. It is the other license. You cannot link *GPL in a kernel with BSD style licensing, and you can't do so with most commercial systems. LGPL requires relinkability, so they would have to give at least object files out, which many vendors won't do. I want KGI drivers to be useable with Linux as well as with SOlaris, BeOS, or whatever ... If some particular driver author really _wants_ to put his work under GPL, he can do so, but this will not allow linkage to some of the potential target OSes. I for myself rather prefer to have put an end to that stupid "you have to write a driver for each OS" than to have held the banner of free software up high ... CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Wed Jun 17 06:56:58 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA12609; Wed, 17 Jun 1998 06:56:56 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA02939; Wed, 17 Jun 1998 06:45:56 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 06:45:56 -0700 (PDT) Date: Wed, 17 Jun 1998 09:43:40 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: little bug In-Reply-To: <199806171303.PAA05427@sunserver1.rz.uni-duesseldorf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"J2WaF1.0.nj.HYyXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2849 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 17 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > So what's the problem ? Maybe adding this info to the FAQ ? I think adding it to the README file veiwable from the toplevel menu would be best. I agree a silent build on the toplevel is OK since the verbose build is available. But if anyone has the energy a checkbox on the toplevel to build with errors shown might save us pointing this out to people that won't read the README. -- Brian S. Julin From ggi-develop-request@eskimo.com Wed Jun 17 07:12:48 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA12626; Wed, 17 Jun 1998 07:12:46 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA07712; Wed, 17 Jun 1998 07:11:01 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 07:11:01 -0700 (PDT) Sender: core@orb.suntech.fr Message-ID: <3587CE00.58DBB721@suntech.fr> Date: Wed, 17 Jun 1998 14:09:04 +0000 From: Emmanuel Marty Reply-To: core@suntech.fr Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: little bug References: <35877B07.6D3700DD@e.kth.se> <3587B270.C9876618@cip.informatik.uni-erlangen.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"7K2yB2.0.Nu1.ovyXr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2850 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andreas Vogler wrote: > Well, the idea was to hide all complicated parts from newbie users, but > if a lot of people agree on it, it shouldn´t be a problem to leave make > output on the screen and to not hide it. It is only silent if you build from toplevel. Please leave it as it is - it isunixish tradition to be silent unless an error occurs anyway :) And if you know what you're doing and just build a subproject, then you'll have the messages. -- Emmanuel From ggi-develop-request@eskimo.com Wed Jun 17 07:53:01 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA12665; Wed, 17 Jun 1998 07:52:56 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA10694; Wed, 17 Jun 1998 07:22:51 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 07:22:51 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3587CA57.58CA0BAF@e.kth.se> Date: Wed, 17 Jun 1998 15:53:27 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: little bug References: <35877B07.6D3700DD@e.kth.se> <3587B270.C9876618@cip.informatik.uni-erlangen.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"3aaVO1.0.fc2.q4zXr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2851 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andreas Vogler wrote: > > Marcus Sundberg wrote: > > > > Peter Amstutz wrote: > > > Oh, on building libggi... I was on IRC and got a couple people > > > interested in it, and one commented that he didn't like a "silent build", > > > that is, all the make messages are redirected to a log file, so one > > > doesn't get to see what's going on. Maybe piping through "tee" (reads > > > stdin, writes to stdout AND a file) would be useful here? I'll take a > > > look at it... > > > > He's not the only one. > > Honestly I don't see any reason for a silent bulid, unless you're > > compiling on a 600 MHz Alpha, logged in with a 300baud Modem. ;) > > Well, the idea was to hide all complicated parts from newbie users, but > if a lot of people agree on it, it shouldn´t be a problem to leave make > output on the screen and to not hide it. I've already removed the "silent" option from the Makefile, so currently stdout goes to the screen, and stderr goes to the logfile. For myself I'd like everything to go to the screen. //Marcus From ggi-develop-request@eskimo.com Wed Jun 17 08:03:16 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA12676; Wed, 17 Jun 1998 08:03:10 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA11323; Wed, 17 Jun 1998 07:54:16 -0700 Resent-Date: Wed, 17 Jun 1998 07:54:16 -0700 Date: Wed, 17 Jun 1998 10:48:37 -0400 (EDT) From: Steve Cheng Sender: steve@maxt2m30.ipoline.com To: ggi-develop@eskimo.com Subject: Re: little bug In-Reply-To: <199806171303.PAA05427@sunserver1.rz.uni-duesseldorf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"9IVCo2.0.jm2.NYzXr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2852 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 17 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Well - actually that's how it is. If you build from the toplevel make using > the "newbie approach", you'll get a silent build. > > If you do "make" from the libggi subdirectory (as I thought any hacker would > do - I even do make config by "joe .config" ...), you will get a verbose build. Heh... I didn't even know there was a "newbie build" until you mentioned it. I tried to use the toplevel configure but it was broken last time because of degas changed. -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Wed Jun 17 08:56:42 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA12735; Wed, 17 Jun 1998 08:56:38 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA26505; Wed, 17 Jun 1998 08:48:06 -0700 Resent-Date: Wed, 17 Jun 1998 08:48:06 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3587E546.D5DCA9D0@e.kth.se> Date: Wed, 17 Jun 1998 17:48:22 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: GGI license - draft #4 References: <199806171309.PAA05789@sunserver1.rz.uni-duesseldorf.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hipfK1.0.1U6.rK-Xr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2853 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com becka@rz.uni-duesseldorf.de wrote: > > > > > What's the problem with putting HW drivers under LGPL ? > > > Short answer: You can't make LGPL'ed code part of a non-GPLed > > > OS source tree. > > > Long answer: ... see the mailing archive. > > > Angry answer suppressed :-) > > > > Well, I guess I'll just have to read the LGPL properly. > > The problem is not on the LGPL side. It is the other license. > > You cannot link *GPL in a kernel with BSD style licensing, and you > can't do so with most commercial systems. LGPL requires relinkability, > so they would have to give at least object files out, which many > vendors won't do. > > I want KGI drivers to be useable with Linux as well as with SOlaris, > BeOS, or whatever ... Yes, so do I. I have now read the LGPL from top to bottom, and here are my conclusions (End of paragraph 2) In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. Thus distributing LGPL code together with any other software is no problem as long as the LGPL code is kept separate. (Paragraph 7) 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. This will allow distribution of GGI HW drivers as a binary module/vxd/dll/whatever which will be dynamicaly linked to binaries/kernels. Now there's only one potential issue left - distributing non-librarytype binary-only code linked staticly against GGI code (ie. kernels and statically linked executables). As such a binary would be both hardware AND OS-specific I don't see much need for such to exist. And should someone want to create such binaries I suggest they do what the LGPL says: write to the author to ask for permission Of course I'm not a lawyer, so I might have gotten something wrong, but if anyone have any objections to what I have said, please tell me exactly what part of the LGPL makes you think I'm wrong. //Marcus From ggi-develop-request@eskimo.com Wed Jun 17 10:12:06 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA12813; Wed, 17 Jun 1998 10:12:00 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA18451; Wed, 17 Jun 1998 10:14:42 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 10:14:42 -0700 (PDT) Message-ID: <524299DFAB41D11193EF00805F8598024F669C@brekka.ch2m.com> From: "Fulgham, Brent/SCO" To: "'ggi-develop@eskimo.com'" Subject: Little bugs when doing kernel make Date: Wed, 17 Jun 1998 10:51:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2120.0) Content-Type: text/plain Resent-Message-ID: <"MpbFf2.0.yV4.rb_Xr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2854 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Could someone with cvs access please address the following issues: 1. The current CVS repo (as of last night) makes use of something called "uchar" in a number of files needed when you build a new kernel image. Could someone please add: typedef unsigned char uchar; To ggi/types.h? This resolves the problem (it probably needs to be added under the uint8 definition for alpha, i386, etc. 2. The configure script for doing a "complete" install is still looking for a "patches" directory. This needs to be changed to use the new "os/Linux" directory. Thanks, -Brent From ggi-develop-request@eskimo.com Wed Jun 17 10:29:36 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA12818; Wed, 17 Jun 1998 10:29:34 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA22067; Wed, 17 Jun 1998 10:32:21 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 10:32:21 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: little bug To: ggi-develop@eskimo.com (mailing list GGI) Date: Wed, 17 Jun 1998 19:24:16 +0200 (MET DST) In-Reply-To: from "Peter Amstutz" at Jun 16, 98 04:31:00 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"2hUBA.0.gO5.Ys_Xr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2855 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > ok, so libggi/extensions/misc/ is the right place for libggimisc? Yes. > Actually, GGIgetraypos is defined twice, once where I mention above, and > again in libggi/display/svgalib - where I don't think it goes at all. Yes. This will be removed ASAP. > Actually, the problem is that GGIRP_SYNC and GGIRP_DONTCARE are #ifdef 0'd > out of libggi.h. They are in the file "ext" (not "ext.h" or > "libggi_ext.h", just "ext" in /usr/local/include/ggi). Yes. This is a bug in the install routine that does not create the /ext subdirectory. > I'd contribute patches but I'm not quite sure what goes where in the > current grand scheme of things. I should probably get access to the > devel cvs one of these days, too :) Thank. Have fixed it. Will commit ASAP. > Oh, ggiDrawCircle() is still in libggi. We should bring in libggi2d and > get rid of ggiDrawCircle once and for all. I've just killed it. Do it once, do it right. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 17 11:01:17 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA12844; Wed, 17 Jun 1998 11:01:13 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA29953; Wed, 17 Jun 1998 10:57:40 -0700 Resent-Date: Wed, 17 Jun 1998 10:57:40 -0700 Date: Thu, 18 Jun 1998 10:56:29 -0700 (MST) From: teunis To: ggi-develop@eskimo.com Subject: Re: Where Are The Drivers?! In-Reply-To: <357F921A.1F72E406@e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"_OpCz2.0.vJ7.JE0Yr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2856 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 11 Jun 1998, Marcus Sundberg wrote: > giles francis hall wrote: > > > > wtf? the drivers are missing: > > [snip] > > > i remember when there used to be an s3 directory and a matrox directory and > > some other drivers --> what up? where did they run off to? > > They haven't been ported to the GGI Console (former EvStack) yet. What? Is source for the new system ready? *goodie*! Expect the S3 ViRGE driver within the next few days *giggle* - I've been waiting for this a -LOOOOONGGG- time now!!!!!!! (last August) G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Wed Jun 17 11:10:19 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA12855; Wed, 17 Jun 1998 11:10:17 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA01172; Wed, 17 Jun 1998 11:08:32 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 11:08:32 -0700 (PDT) Date: Thu, 18 Jun 1998 11:05:02 -0700 (MST) From: teunis To: ggi-develop@eskimo.com Subject: Re: IRC summary (final) and libggi3d In-Reply-To: <357FE769.36009D02@ensimag.imag.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"AJQRQ2.0.AI.QO0Yr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2857 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 11 Jun 1998, Xavier Bouchoux wrote: [clip] > 2) What is the status of libggi3d & friends? > the email in the homepage don't seem to be correct... > Is there some design done? even coding? Due to HD loss + a whole mess of code problems this one's taken longer than I expected.... (but since GGIMesa existed I wasn't too concerned) (also a whole list of RL problems) Now that EvStacks (now GGI Console) and libGGI are largely stablized I'll get cracking *giggle* Though I was never the only person working on such - I wonder how the others are doing? Incidentally, my teunis@mauve.computersupportcentre.com address is now invalid (lost ISP, new DNS doesn't have this address) could someone fix my teunis@ggi-project.org entry? :) G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Wed Jun 17 12:57:28 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA12979; Wed, 17 Jun 1998 12:57:27 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA25919; Wed, 17 Jun 1998 12:49:16 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 12:49:16 -0700 (PDT) Message-Id: <199806171936.VAA29034@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: Little bugs when doing kernel make In-reply-to: Your message of "Wed, 17 Jun 1998 10:51:42 MDT." <524299DFAB41D11193EF00805F8598024F669C@brekka.ch2m.com> Date: Wed, 17 Jun 1998 21:36:27 +0200 From: Marcus Sundberg Resent-Message-ID: <"kbK1H2.0.nK6.ts1Yr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2858 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > 1. The current CVS repo (as of last night) makes use of something > called "uchar" in a number of files needed when you build a new kernel > image. Could someone please add: > > typedef unsigned char uchar; > > To ggi/types.h? This resolves the problem (it probably needs to be > added under the uint8 definition for alpha, i386, etc. Oops. I think I removed that typedef. But it was for a good reason: uchar should not be used. I'll change the affected files to use unsigned char instead. (Or rather uint8 in most of the cases). //Marcus From ggi-develop-request@eskimo.com Wed Jun 17 13:37:09 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA13058; Wed, 17 Jun 1998 13:37:05 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA05486; Wed, 17 Jun 1998 13:33:52 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 13:33:52 -0700 (PDT) Date: Wed, 17 Jun 1998 22:24:30 +0200 (MEST) From: Matthias Grimrath Reply-To: Matthias Grimrath To: ggi-develop@eskimo.com Subject: KGI driver makefile system Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"3tXfN.0.cL1.lW2Yr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2859 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi driver developers! Now that the move to degas has been completed, I recognized that my new makefile system I introduced in the old repository has been removed. Let me repeat the advantadges: - true linking of object files in subsystems. For example the Matrox chipset drivers: mga1024.c mga_common.c ... to one chipdrv.o. No need to mess with .inc files. Less worries about namespace pollution, no abuse of the preprocessor as a linker and the Matrox drivers NEED this feature back! The driver kernel module itself will carry more symbols in 2.0.X, whereas in recent 2.1.X the kernel can remove specified symbols on module insertion time. (Implying that ggi prime time will be on 2.3.X kernels) - on a 'make depend' only those dependencies between files are built that are part of the selected driver/subsystem. Less time for dep building and no annoying messages if there happen to be broken sources in the repository. The only objection was from Steffen who claimed to have a possibility to build all drivers/subsystem with one big make. So my offering is: I'll bring this Makefile system back before everyone starts to commit his driver(s), taking care of Steffen objection. Your comment? Matthias Grimrath From ggi-develop-request@eskimo.com Wed Jun 17 14:54:47 1998 Return-Path: Received: from mx1.eskimo.com ([204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA13332; Wed, 17 Jun 1998 14:53:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA24150; Wed, 17 Jun 1998 14:42:04 -0700 Resent-Date: Wed, 17 Jun 1998 14:42:04 -0700 Message-Id: <199806172124.XAA26464@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: KGI driver makefile system In-reply-to: Your message of "Wed, 17 Jun 1998 22:24:30 +0200." Date: Wed, 17 Jun 1998 23:24:55 +0200 From: Marcus Sundberg Resent-Message-ID: <"mkOVR2.0.vu5.gW3Yr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2860 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This sounds very fine with me! Also, the makefile system could use some cleanup - it contains tons of old junk. If you could do that while you're at it it would be great. //Marcus From ggi-develop-request@eskimo.com Wed Jun 17 15:48:11 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA13373; Wed, 17 Jun 1998 15:48:08 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA10030; Wed, 17 Jun 1998 15:43:07 -0700 Resent-Date: Wed, 17 Jun 1998 15:43:07 -0700 Date: Wed, 17 Jun 1998 18:49:02 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: GGI license - draft #4 In-Reply-To: <199806172230.SAA16827@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"eywAI.0.aS2.wP4Yr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2861 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > What's the problem with putting HW drivers under LGPL ? Same problem as for LGPLing LibGGI: *BSD. We simply can't use any form of GPL (even LGPL) if we want to be accepted by the *BSD folks. -=MenTaLguY=- From ggi-develop-request@eskimo.com Wed Jun 17 17:30:38 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA13475; Wed, 17 Jun 1998 17:30:32 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA27822; Wed, 17 Jun 1998 17:30:39 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 17:30:39 -0700 (PDT) Date: Wed, 17 Jun 1998 15:23:49 +0200 (DFT) From: Massimiliano Ghilardi To: ggi-develop@eskimo.com Subject: Re: little bug In-Reply-To: <35877B07.6D3700DD@e.kth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"gj3g11.0.Yo6.i-5Yr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2862 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 17 Jun 1998, Marcus Sundberg wrote: > Peter Amstutz wrote: > > Oh, on building libggi... I was on IRC and got a couple people > > interested in it, and one commented that he didn't like a "silent build", > > that is, all the make messages are redirected to a log file, so one > > doesn't get to see what's going on. Maybe piping through "tee" (reads > > stdin, writes to stdout AND a file) would be useful here? I'll take a > > look at it... > > He's not the only one. Agreed. I'd like to see what commands are executed too. Actually, I even patched an old pre-Dali GGI to do that. Massimiliano Ghilardi From ggi-develop-request@eskimo.com Wed Jun 17 17:55:30 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA13492; Wed, 17 Jun 1998 17:55:27 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA03839; Wed, 17 Jun 1998 17:59:15 -0700 (PDT) Resent-Date: Wed, 17 Jun 1998 17:59:15 -0700 (PDT) Date: Thu, 18 Jun 1998 17:54:23 -0700 (MST) From: teunis To: ggi-develop@eskimo.com Subject: Re: S3/Virge Question In-Reply-To: <199806120800.KAA00770@mclane.physik.tu-chemnitz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"FCoo41.0.mx.RP6Yr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2863 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 12 Jun 1998, Steffen Seeger wrote: > > > This message is aimed at Jan or Teunis, but input from anyone would be > > appreciated: > > > > Can anyone suggest why my S3/Virge driver works when compiled using the > > SVGA monosync monitor data from the distribution, but when I use my own > > monitor values from the mfr. literature my system locks up when I insmod > > the driver? I think I've ruled out a typo in the kgi_monitor structure > > I created, but you never know... > > > > If anyone has experience resolving this kind of problem, please respond. > > > > Thanks, > > > > -Brent > > Try to enable kernel logging and check the logfiles. Make sure you log > debug messages also. Turning on debugging in the kernel driver gives > some more output on what's going on. I had that happen with some drivers as well - it looked like a problem with the monitor drivers. (though more soon - am just getting ready to rebuild S3 driver for new kernel/KGI layout). There -WAS- a serious bug in the S3 driver that was in EvStack involving not initializing data correctly but hopefully that'll be an issue in the past :) G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Thu Jun 18 00:21:17 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA13748; Thu, 18 Jun 1998 00:21:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id AAA11142; Thu, 18 Jun 1998 00:17:44 -0700 Resent-Date: Thu, 18 Jun 1998 00:17:44 -0700 Date: Fri, 19 Jun 1998 00:16:15 -0700 (MST) From: teunis To: ggi-develop@eskimo.com Subject: Re: Open Source Certification (yet more licensing comments) In-Reply-To: <35830E3B.4BB61741@cistron.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"t15qj2.0.uj2.NyBYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2864 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 14 Jun 1998, W. Scholten wrote: > Kendall Bennett wrote: > > > > > You might also be interested that at SciTech we have used a modified > > > > version of the Mozilla Public License for our SciTech MGL Public > > > > License. The only modification we made was an ammendment at the end that > > > > states that SciTech has the extra right to reuse any of the 'original' > > > > contributed code for internal projects without that code falling under > > > > the public license. ie: we can reuse all our own code for other > > > > projects, but any contributed code must remain free. Of > > > > > > Hmm. This seems competely unnecessary from the info you give. YOU made the > > > code, you can put it under NPL, but also use it anywhere else for whatever > > > purpose under whatever license (i.e. the original code (and derivativions > > > by you), not the altered version when others hack it). > > > > Well that is how I saw it also, but the lawyers did not see it that > > way. They said that once we released the code to the public, all that > > code would be bound by the MGL Public License, and hence if we re- > > used any of the original code we would have to re-distribute > > modifications also. The reason for this clause is that it is not > > explicity stated in the license that we may do so; hence we > > explicitly stated this to keep the lawyers happy. Also I doubt anyone > > would complain about this particular clause, since we don't plan to > > re-use modifications without returning changes back to the developer > > community. > > Well, this is simply NOT correct. This would mean for example that I can > never change the license for software, that I cannot reuse my own code > that I give away. That's silly and not what copyright law is about. > Copyright conditions are for those who receive things, not for those who > create things. If this were true, then I cannot make a commercial > derivative of a program I put under GPL for example (which I know I > can). Sorry - copyright protects the owner of the copywrite, not the author. This licence modification protects the -AUTHOR- as well! (I worked for a company where all work I did was copyright them. This is a perfectly normal situation but it's very irritating if you want to use any of your work anywhere else.....) Incidentally - this situation has less to do with copyright protection than with intellectual secret protection..... (perhaps?) (or perhaps with acceptance of liability on the part of the authors...... not sure here) There - does that help? (or am I off on a tangent :) Incidentally the company agreed that should I use code under another copyright they wouldn't fight the terms of that copyright... (this allowed me to feel a little safer bringing GPL code from home :) [paranoid thinking] -- yes they DID allow me to have my own copyrights on code written outside of the office... the contract I was working under was pretty nasty and required I get this kind of protection. G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Thu Jun 18 00:39:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA13826; Thu, 18 Jun 1998 00:39:48 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA04453; Thu, 18 Jun 1998 00:40:48 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 00:40:48 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3588C40B.DED2C2BF@e.kth.se> Date: Thu, 18 Jun 1998 09:38:51 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: GGI license - draft #4 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"u2JoQ1.0.T51.-HCYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2865 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com MenTaLguY wrote: > > > What's the problem with putting HW drivers under LGPL ? > > Same problem as for LGPLing LibGGI: > > *BSD. > > We simply can't use any form of GPL (even LGPL) if we want to be accepted by > the *BSD folks. LGPL will allow the BSD people to both distribute and/or use the code, just like everybody is allowed to do by the LGPL. If they don't like the license - well that's their problem. We can't please everybody. On the other hand LGPL is not an ideal license. LGPL without having to distribute objectcode for code that's just linked to the library is what I'd prefer. //Marcus From ggi-develop-request@eskimo.com Thu Jun 18 01:04:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA13882; Thu, 18 Jun 1998 01:04:40 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA07252; Thu, 18 Jun 1998 00:55:38 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 00:55:38 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806180748.JAA26700@cip8.e-technik.uni-erlangen.de> Subject: Re: KGI driver makefile system To: m.grimrath@tu-bs.de Date: Thu, 18 Jun 1998 09:48:21 +0200 (MESZ) Cc: ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: from "Matthias Grimrath" at Jun 17, 98 10:24:30 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KTKSt1.0.Cn1.uVCYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2866 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Hi driver developers! > > Now that the move to degas has been completed, I recognized that my new > makefile system I introduced in the old repository has been removed. Let me > repeat the advantadges: > > - true linking of object files in subsystems. For example the Matrox > chipset drivers: mga1024.c mga_common.c ... to one chipdrv.o. No need to > mess with .inc files. Less worries about namespace pollution, no abuse of > the preprocessor as a linker and the Matrox drivers NEED this feature > back! The driver kernel module itself will carry more symbols in 2.0.X, > whereas in recent 2.1.X the kernel can remove specified symbols on module > insertion time. (Implying that ggi prime time will be on 2.3.X kernels) > > - on a 'make depend' only those dependencies between files are built that > are part of the selected driver/subsystem. Less time for dep building and > no annoying messages if there happen to be broken sources in the repository. > > The only objection was from Steffen who claimed to have a possibility to > build all drivers/subsystem with one big make. > > So my offering is: I'll bring this Makefile system back before everyone > starts to commit his driver(s), taking care of Steffen objection. > > Your comment? > > Matthias Grimrath > > Sounds good. While you're at it, could you write the necessary documentation about how to use this system when writing my own driver? It would be good if not everybody had to figure out how the configuration/make process works from the make files. Plain ASCII is perfect, I'll sgml-ize it gladly for you. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Thu Jun 18 01:46:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA13917; Thu, 18 Jun 1998 01:46:35 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA15769; Thu, 18 Jun 1998 01:42:41 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 01:42:41 -0700 (PDT) X-Sender: ortalo@poptsf.laas.fr Message-Id: In-Reply-To: References: from "Peter Amstutz" at Jun 16, 98 04:31:00 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro F3.1.3 Date: Thu, 18 Jun 1998 10:37:49 +0200 To: ggi-develop@eskimo.com From: Rodolphe Ortalo Subject: libg* placement Resent-Message-ID: <"Maf-k1.0.Gs3._BDYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2867 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >> ok, so libggi/extensions/misc/ is the right place for libggimisc? > >Yes. Hey. Andreas : do you mean that libggi/extensions/libggi2d/ is the right place for libggi2d, and, more specifically for me, that libggi/extensions/libgwt/ is the right place for libgwt ? (There will be no problems with lib{ggi2d,gwt} sublibs inclusion or conf files ?) At first, I had put my files in degas/lib/libgwt/ ... (on my hard disk only). Rodolphe From ggi-develop-request@eskimo.com Thu Jun 18 04:10:04 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA14051; Thu, 18 Jun 1998 04:10:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA28733; Thu, 18 Jun 1998 04:03:34 -0700 Resent-Date: Thu, 18 Jun 1998 04:03:34 -0700 Sender: mee@daimi.aau.dk Message-ID: <3588F401.3EF0B6DD@daimi.aau.dk> Date: Thu, 18 Jun 1998 13:03:29 +0200 From: Martin Eli Erhardsen X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: VGA issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0J-K02.0.n07.5GFYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2868 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I have been reading the the VGA docs, while waiting for a working degas VGA driver, and I have come with some VGA proposals. Should we support width 9 fonts in textmode? By dropping support for them we could simplicy the the code, because then the character width is always 8, and we can use shifts instead of divisions. Do you think that a chained 16-color mode is useful? It would enable us to use 640x400x4 on the vga without any pagefaults, if we use 128k for the memory window. It would also be very useful on SVGA cards with linear frame buffers. What about linear-2? The VGA supports a packed 2-bit mode for CGA-emulation, so why doesn't the kgi driver support it too? Why doesn't the kgi drivers use DirectBuffer to tell libggi about the mode, instead of suggesting libraries. It cumbersome to detect if the memory is 8, 16, 32 or 64 in all the libggi libraries, when the kgi driver should know this. The mode negotiation in the vga driver isn't done according to the specification in the libggi docs, and this needs to be fixed. text_16 has 16 colors, which can be used as foreground and background colors. Putc and puts should use both the foreground and background colors, to write a char. Drawpixel should just fill a pixel with the current foreground color by setting the foreground and background colors of that pixel to the desired color, so that the font doesn't have any influence on the result. Putpixel and getpixel should work just like linear-16. The big problem with text_16 is how to represent the colors. If we use 16 bits to represent the color, then libggi/default/ramdac doesn't work, while if we use only 4 bits, then we can't use the color in a putpixel. From ggi-develop-request@eskimo.com Thu Jun 18 04:20:51 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA14063; Thu, 18 Jun 1998 04:20:42 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA02768; Thu, 18 Jun 1998 04:13:24 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 04:13:24 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806181106.NAA01223@sunserver1.rz.uni-duesseldorf.de> Subject: Re: libg* placement In-Reply-To: from Rodolphe Ortalo at "Jun 18, 98 10:37:49 am" To: ggi-develop@eskimo.com Date: Thu, 18 Jun 1998 13:06:33 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"2tT9F3.0.8h.IPFYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2869 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > >> ok, so libggi/extensions/misc/ is the right place for libggimisc? > Hey. Andreas : do you mean that libggi/extensions/libggi2d/ is the > right place for libggi2d, and, more specifically for me, that > libggi/extensions/libgwt/ is the right place for libgwt ? Yes. If it is an extension, put it under 4he lib/libggi/extensions tree. This is done, because you might want to access LibGGI internal state, which is only possible, if you have access to its private headers. Anything else like wrappers, helper libs (that are not extensions) and such goes directly to /lib. CU,ANdy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Thu Jun 18 05:20:49 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA14092; Thu, 18 Jun 1998 05:20:47 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA13367; Thu, 18 Jun 1998 05:19:04 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 05:19:04 -0700 (PDT) Date: Thu, 18 Jun 1998 08:16:45 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: KGI driver makefile system In-Reply-To: <199806180748.JAA26700@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"iGH-o2.0.fG3.oMGYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2871 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 18 Jun 1998, Hartmut Niemann wrote: > Sounds good. > While you're at it, could you write the necessary documentation about how to > use this system when writing my own driver? Please -- and provide a .stubs directory like there is now. -- Brian S. Julin From ggi-develop-request@eskimo.com Thu Jun 18 05:24:05 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA14097; Thu, 18 Jun 1998 05:23:48 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA13075; Thu, 18 Jun 1998 05:16:49 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 05:16:49 -0700 (PDT) Date: Thu, 18 Jun 1998 08:14:33 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: VGA issues In-Reply-To: <3588F401.3EF0B6DD@daimi.aau.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"DR7Ij1.0.AC3.kKGYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2870 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 18 Jun 1998, Martin Eli Erhardsen wrote: > Should we support width 9 fonts in textmode? The MDA driver and base kernel i386 will have to -- MDA monitors can only do 9-dot fonts. Personally my drivers/driver-libs will eventually support any font width with emulation. My chipsets can do 6, 7, 8, 9, and 10-dot fonts. Some can do just about any width. > By dropping support for them we could simplicy the the code, > because then the character width is always 8, and we can use > shifts instead of divisions. Mode setup is not performance critical. > Do you think that a chained 16-color mode is useful? > It would enable us to use 640x400x4 on the vga without any pagefaults, > if we use 128k for the memory window. > It would also be very useful on SVGA cards with linear frame buffers. If you chain you waste half the linear framebuffer on unused bits. We should use the 128K buffer when we can, and we don't, granted. I'd like to see ModeY, and use of 0x3c2 bit 5, investigated/implemented. Odds are a lot of controllers will map all 256K when using a 128K window and 0x3c2 bit 5 to select pages. > What about linear-2? The VGA supports a packed 2-bit mode > for CGA-emulation, so why doesn't the kgi driver support it too? Noone's asked for it/wanted it enough to emulate it yet. The pallette is funny to work with. > Why doesn't the kgi drivers use DirectBuffer to tell libggi > about the mode, instead of suggesting libraries. Because libGGI needs to load hw acceleration libraries which really have not much to do with directbuffer. > The mode negotiation in the vga driver isn't done according > to the specification in the libggi docs, and this needs to be fixed. The system needs a bit of rework, yes. > text_16 has 16 colors, which can be used as foreground and background > colors. The 16 refers to 16 bits per pixel (character cell) which is 8 (or 9) bits representing 256 (or 512) font entries and 8 (or 7) color (or attribute), for VGA. > Putc and puts should use both the foreground and background colors, > to write a char. Yes -- it doesn't? > Drawpixel should just fill a pixel with the current foreground color > by setting the foreground and background colors of that pixel to the > desired color, so that the font doesn't have any influence on the > result. Drawpixel in text modes is supposed to put characters/attributes. If you want a block, draw a space. > The big problem with text_16 is how to represent the colors. > If we use 16 bits to represent the color, then libggi/default/ramdac > doesn't > work, while if we use only 4 bits, then we can't use the color in a > putpixel. Well, the API certainly doesn't make it clear that you have 4 bits of background and 4 bits of foreground color. MenTaLGuY should add that to his open API issues on emulated text modes. Hope that answers your questions/suggestions? -- Brian S. Julin From ggi-develop-request@eskimo.com Thu Jun 18 05:39:34 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA14155; Thu, 18 Jun 1998 05:39:32 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA01504; Thu, 18 Jun 1998 05:33:13 -0700 Resent-Date: Thu, 18 Jun 1998 05:33:13 -0700 Message-ID: <19980617195257.A1103@bengburken.dyn.ml.org> Date: Wed, 17 Jun 1998 19:52:57 +0200 From: =?iso-8859-1?Q?Jonas_Borgstr=F6m?= To: ggi-develop@eskimo.com Subject: VT-Problem. Reply-To: jonas_b@bitsmart.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.91.1i Resent-Message-ID: <"2X_zn1.0.ON.8aGYr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2873 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I don't know if this is a known bug but... If I use the evstack kernel and load the conlinux module I can start X-Windows and use CTRL+ALT+F1 to switch back to text-mode and ALT+F7 to return. But if I exit from X-Windows and start it again CTRL+ALT+F1 works as before but then I have to use ALT+F8 to return. And if I restart it again I have to to use ALT+F9 and so on, it's not supposed to be so is it? -- -------------------------------------- Jonas Borgström From ggi-develop-request@eskimo.com Thu Jun 18 05:47:08 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA14168; Thu, 18 Jun 1998 05:47:07 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA14852; Thu, 18 Jun 1998 05:28:34 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 05:28:34 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806181225.OAA05570@sunserver1.rz.uni-duesseldorf.de> Subject: Re: KGI driver makefile system In-Reply-To: from Brian Julin at "Jun 18, 98 08:16:45 am" To: ggi-develop@eskimo.com Date: Thu, 18 Jun 1998 14:25:22 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"1qNDq2.0.ud3.lVGYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2872 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > While you're at it, could you write the necessary documentation about how to > > use this system when writing my own driver? > > Please -- and provide a .stubs directory like there is now. Ahem - could we agree to move to "stubs" instead of ".stubs" ? I think the .stubs might be a bit difficult to locate - won't it ? Or should we rule out the "I never read documentation" type programmers ? CU, Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Thu Jun 18 06:38:11 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA14251; Thu, 18 Jun 1998 06:38:09 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA07756; Thu, 18 Jun 1998 06:22:06 -0700 Resent-Date: Thu, 18 Jun 1998 06:22:06 -0700 Sender: mee@daimi.aau.dk Message-ID: <3589147B.100438EF@daimi.aau.dk> Date: Thu, 18 Jun 1998 15:22:03 +0200 From: Martin Eli Erhardsen X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: VGA issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"aoXx1.0.zu1.-HHYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2874 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Brian Julin wrote: > > On Thu, 18 Jun 1998, Martin Eli Erhardsen wrote: > > > Should we support width 9 fonts in textmode? > > The MDA driver and base kernel i386 will have to -- MDA monitors > can only do 9-dot fonts. Personally my drivers/driver-libs will eventually > support any font width with emulation. My chipsets can do 6, 7, 8, 9, > and 10-dot fonts. Some can do just about any width. > MDA-monitors shouldn't care about font width, they use only horisontal and vertical refresh rates. The chipset is another matter entirely. I don't like the width 9 VGA fonts, bacuse they are a hack. The VGA is really using width 8 fonts for a width of 9, and this is done with a special cheat where characters above a certain value get their last pixel duplicated. > > What about linear-2? The VGA supports a packed 2-bit mode > > for CGA-emulation, so why doesn't the kgi driver support it too? > > Noone's asked for it/wanted it enough to emulate it yet. The pallette > is funny to work with. > Isn't it possible to use the VGA palette registers? > > Why doesn't the kgi drivers use DirectBuffer to tell libggi > > about the mode, instead of suggesting libraries. > > Because libGGI needs to load hw acceleration libraries which really have > not much to do with directbuffer. > Wouldn't it be really irritating to have 2 linear-8 libraries, one for a 16 bit interface and one for a 32 bit interface. If the driver told libggi about the how many bits the card had, the library could tell the user, and select approiate drawing functions. From ggi-develop-request@eskimo.com Thu Jun 18 08:00:32 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA14318; Thu, 18 Jun 1998 08:00:30 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA23997; Thu, 18 Jun 1998 07:54:47 -0700 Resent-Date: Thu, 18 Jun 1998 07:54:47 -0700 X-Sender: ortalo@poptsf.laas.fr Message-Id: In-Reply-To: <199806181106.NAA01223@sunserver1.rz.uni-duesseldorf.de> References: from Rodolphe Ortalo at "Jun 18, 98 10:37:49 am" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro F3.1.3 Date: Thu, 18 Jun 1998 16:56:55 +0200 To: ggi-develop@eskimo.com From: Rodolphe Ortalo Subject: Re: libg* placement Resent-Message-ID: <"ObWf83.0.ps5.seIYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2875 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >> >> ok, so libggi/extensions/misc/ is the right place for libggimisc? > >> Hey. Andreas : do you mean that libggi/extensions/libggi2d/ is the >> right place for libggi2d, and, more specifically for me, that >> libggi/extensions/libgwt/ is the right place for libgwt ? > >Yes. If it is an extension, put it under 4he lib/libggi/extensions >tree. This is done, because you might want to access LibGGI internal >state, which is only possible, if you have access to its private >headers. Ahhhhh. Okay. Then I understand why I found the Makefile & Makerules config rather cumbersome to set up, and why I wanted to mail to the list that "-I../libggi/include/internal.h" was really bad. (A "-I../../include/internal.h" is better...) Well, now, I need to change my code instead. ;-) I will also need to load dynamic libraries, such as: libggi/extensions/libgwt/default/display-stubs-gwt-blitting.so libggi/extensions/libgwt/default/display-stubs-gwt-exposeevent.so libggi/extensions/libgwt/default/display-stubs-gwt-X.so with a conf in libggi/extensions/libgwt/libgwt.conf (in dist.) No problem with this ? >Anything else like wrappers, helper libs (that are not extensions) and >such goes directly to /lib. Hmmm. That's the problem with libgwt, all the functions dealing directly and _only_ with the windows hierarchy may be viewed as helper libs. Similarly, a "libggiregion" may be useful alone. But well, we'll see when something work (:-). Yet I have to change my current code to put it in the right place. :-) Thanks for the info. Rodolphe From ggi-develop-request@eskimo.com Thu Jun 18 10:34:59 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA14447; Thu, 18 Jun 1998 10:34:56 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA10834; Thu, 18 Jun 1998 08:54:25 -0700 Resent-Date: Thu, 18 Jun 1998 08:54:25 -0700 Message-ID: <524299DFAB41D11193EF00805F8598024F669F@brekka.ch2m.com> From: "Fulgham, Brent/SCO" To: "'ggi-develop@eskimo.com'" Subject: LibGGI 1.4 Question Date: Thu, 18 Jun 1998 09:54:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2120.0) Content-Type: text/plain Resent-Message-ID: <"OU3TU.0.8f2.mWJYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2876 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I'm segfaulting when I try to run any of the demo programs after compiling LibGGI 1.4. Is this typical of everyone else's experiences, or have I got something misconfigured? Segfault occurs (according to output with LIBGGI_DEBUG=255) immediately after setting the mode (mode sets successfully, a "ggi on X" window opens and stays open after segfault. This is under the X target using 800x640 16bpp settings that worked fine under LibGGI 1.3 -- I am using an updated CVS tree from about 10 hours ago. Compiled using egcs 1.0.3. -Brent From ggi-develop-request@eskimo.com Thu Jun 18 15:33:44 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA14677; Thu, 18 Jun 1998 15:33:42 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA31624; Thu, 18 Jun 1998 15:27:04 -0700 Resent-Date: Thu, 18 Jun 1998 15:27:04 -0700 Message-Id: <199806182219.AAA14887@paris.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: ggi-develop@eskimo.com Subject: I have seen the stars... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jun 1998 00:19:58 +0200 From: Marcus Sundberg Resent-Message-ID: <"LBPWL.0.zj7.sGPYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2877 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com ...demo of libggi running on my NT box! I've finally got libggi to run with the CYGWIN32 environment. This was basicly done by replacing dlopen/dlsym/dlclose with LoadLibrary/GetProcAddress/FreeLibrary. The stars demo was run on the xlib-target, displaying on the free (but not very good...) win32 Xserver MiX. But this is however not the right way to do our win32 port, because CYGWIN32 links everything to the cygwin DLL, which has two major drawbacks: - It's under the GPL (not LGPL), which only allows GPLed code to be linked with it. - It's not threadsafe. So now I have put my efforts into the mingw32 compiler, which uses gcc to generate 100% native win32-binaries with no licence restrictions. And it also has the nice feature of being simple to compile as a crosscompiler (which means I don't have to expose myself for the trauma of using NT... ;) As for the guy who wanted to do a win-port I suggest he starts writing a directX/GDI port, while I attack the core libggi. I should also be able to answer most questions about libggi. //Marcus PS. If anyone would like to have a binary/buildinstructions for pgcc-1.0.3 compiled as a linux -> win32 crosscompiler I'll make them available from my GGI page. DS. -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Thu Jun 18 15:53:59 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA14699; Thu, 18 Jun 1998 15:53:50 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA29347; Thu, 18 Jun 1998 15:51:17 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 15:51:17 -0700 (PDT) Message-Id: <199806182242.AAA14956@paris.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: andreas.beck@ggi-project.org cc: ggi-develop@eskimo.com Subject: Misc libggi stuff Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 19 Jun 1998 00:42:52 +0200 From: Marcus Sundberg Resent-Message-ID: <"tVsaK3.0.QA7.ZdPYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2878 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Before the CVS closedown there where a lot of changes which to me seemed pretty decided on for libggi. What happend to that? Among other things libggi.h and libggi_db.h was going to be merged, but now we instead have one more includefile. Hmm... [digging in the list-archive] Andy, please have a loook at http://www.ggi-project.org/mailinglist/mar98/603.html and tell me which of the listed things should be done and which are scrapped. I have some other questions regarding libggi as well: 1. Threads in libggi; is libggi supposed to simply be threadsafe, or should it actually use threading internally? 2. Currently the driver-libs are dlopen()ed for every visual of the same type. Shouldn't this be handled like the extensions: open once - use for many visuals. 3. I'd like to move GGIdlcleanup into the ggi_visual_opdisplay struct, so we only have one single entry-point into the driver-libs. Any objections? //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Thu Jun 18 15:54:02 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA14703; Thu, 18 Jun 1998 15:53:58 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA00946; Thu, 18 Jun 1998 15:59:14 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 15:59:14 -0700 (PDT) Message-ID: <001001bd9b14$006c7140$0c0a0a0a@MASSACRE> From: "David Waite" To: Subject: Re: I have seen the stars... Date: Thu, 18 Jun 1998 18:51:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0518.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.0 Resent-Message-ID: <"3Ztrj.0.bE.zkPYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2879 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com -----Original Message----- From: Marcus Sundberg To: Date: Thursday, June 18, 1998 5:36 PM Subject: I have seen the stars... >So now I have put my efforts into the mingw32 compiler, >which uses gcc to generate 100% native win32-binaries with >no licence restrictions. And it also has the nice feature >of being simple to compile as a crosscompiler (which >means I don't have to expose myself for the trauma of >using NT... ;) tre cool! Are you going to work on an X target with mingw32, or a DirectX one? >//Marcus > >PS. If anyone would like to have a binary/buildinstructions >for pgcc-1.0.3 compiled as a linux -> win32 crosscompiler >I'll make them available from my GGI page. DS. Sounds interesting, I'll take a looksee. From ggi-develop-request@eskimo.com Thu Jun 18 16:57:38 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA14757; Thu, 18 Jun 1998 16:57:36 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA26413; Thu, 18 Jun 1998 16:58:23 -0700 Resent-Date: Thu, 18 Jun 1998 16:58:23 -0700 Date: Thu, 18 Jun 1998 20:02:57 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: VGA issues In-Reply-To: <199806182330.TAA08525@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"63d-52.0.ZS6.UcQYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2880 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Drawpixel in text modes is supposed to put characters/attributes. If > you want a block, draw a space. Of course, that'd use the background, and not the foreground. And in addition, it'd get funky if the hi bit of the background meant blink, as it does by default... > > The big problem with text_16 is how to represent the colors. > > If we use 16 bits to represent the color, then libggi/default/ramdac > > doesn't > > work, while if we use only 4 bits, then we can't use the color in a > > putpixel. > > Well, the API certainly doesn't make it clear that you have 4 bits of > background and 4 bits of foreground color. MenTaLGuY should add that > to his open API issues on emulated text modes. Yes... I'll try to address that. As far as setting the GC background properly, text mode drivers should override (chain, really) the ggi[GS]etGCBackground() implementation -- I think that's possible from stubs now for some time. -=MenTaLguY=- From ggi-develop-request@eskimo.com Thu Jun 18 17:03:00 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA14799; Thu, 18 Jun 1998 17:02:58 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA14192; Thu, 18 Jun 1998 17:01:41 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 17:01:41 -0700 (PDT) Date: Thu, 18 Jun 1998 19:59:07 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: VGA issues In-Reply-To: <199806182330.TAA08510@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cKtLS3.0.dT3.XfQYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2881 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 18 Jun 1998, Martin Eli Erhardsen wrote: > I have been reading the the VGA docs, while waiting for a working > degas VGA driver, and I have come with some VGA proposals. > > Should we support width 9 fonts in textmode? > By dropping support for them we could simplicy the the code, > because then the character width is always 8, and we can use > shifts instead of divisions. Yes, we need to keep width 9 support in, or some people will shoot us. :) However, we could always do something creative like sticking a function pointer somewhere relevent and changing it to an optimized-for-8 or general-case thing. Or use a trampoline for a similar effect. -=MenTaLguY=- From ggi-develop-request@eskimo.com Thu Jun 18 17:26:21 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA14805; Thu, 18 Jun 1998 17:26:04 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id RAA00391; Thu, 18 Jun 1998 17:27:03 -0700 Resent-Date: Thu, 18 Jun 1998 17:27:03 -0700 Message-Id: <199806190010.CAA15438@paris.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: ggi-develop@eskimo.com Subject: Re: I have seen the stars... In-reply-to: Your message of "Thu, 18 Jun 1998 18:51:22 CDT." <001001bd9b14$006c7140$0c0a0a0a@MASSACRE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jun 1998 02:10:12 +0200 From: Marcus Sundberg Resent-Message-ID: <"pC0qT2.0.t5.M1RYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2882 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > -----Original Message----- > From: Marcus Sundberg > To: > Date: Thursday, June 18, 1998 5:36 PM > Subject: I have seen the stars... > > >So now I have put my efforts into the mingw32 compiler, > >which uses gcc to generate 100% native win32-binaries with > >no licence restrictions. And it also has the nice feature > >of being simple to compile as a crosscompiler (which > >means I don't have to expose myself for the trauma of > >using NT... ;) > > tre cool! Are you going to work on an X target with mingw32, or a DirectX > one? I'll probably try the Xlib target first, and after that I'll have a look att DirectX. > >PS. If anyone would like to have a binary/buildinstructions > >for pgcc-1.0.3 compiled as a linux -> win32 crosscompiler > >I'll make them available from my GGI page. DS. > > Sounds interesting, I'll take a looksee. It might take a day or two before I get them up. Oh, and btw, the URLs on the main GGI pages are wrong. My www pages are att http://www.stacken.kth.se/~mackan/ and http://www.stacken.kth.se/~mackan/ggi/ //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Thu Jun 18 17:47:05 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA14813; Thu, 18 Jun 1998 17:47:03 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA24217; Thu, 18 Jun 1998 17:51:15 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 17:51:15 -0700 (PDT) Date: Thu, 18 Jun 1998 20:46:40 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: I have seen the stars... In-Reply-To: <199806182331.TAA08592@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"CT9x9.0.Aw5.0ORYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2883 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > - It's under the GPL (not LGPL), which only allows GPLed > code to be linked with it. They said they were going to fix that a while back -- it should be fixed by now. You have the most recent version, right? -=MenTaLguY=- From ggi-develop-request@eskimo.com Thu Jun 18 18:49:05 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA14895; Thu, 18 Jun 1998 18:49:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA20386; Thu, 18 Jun 1998 18:47:12 -0700 Resent-Date: Thu, 18 Jun 1998 18:47:12 -0700 Date: Fri, 19 Jun 1998 18:44:45 -0700 (PDT) From: Nathan X-Sender: gblues@gblues To: ggi-develop@eskimo.com Subject: Re: I have seen the stars... In-Reply-To: <199806182219.AAA14887@paris.e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"P5s6u3.0.L-4.VCSYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2884 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 19 Jun 1998, Marcus Sundberg wrote: > ...demo of libggi running on my NT box! *sniff* I'm so proud.. my little demo being the first to successfully run on the win32 platform.. That is very cool. How does it perform btw? Nathan (author of stars demo) gblues@jps.net From ggi-develop-request@eskimo.com Thu Jun 18 20:27:51 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA14925; Thu, 18 Jun 1998 20:27:49 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id UAA28923; Thu, 18 Jun 1998 20:32:18 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 20:32:18 -0700 (PDT) From: Andrew Apted Message-ID: <19980619131802.31982@ajax.netspace.net.au> Date: Fri, 19 Jun 1998 13:18:02 +1000 To: ggi-develop@eskimo.com Subject: Re: Misc libggi stuff Reply-To: ggi-develop@eskimo.com References: <199806182242.AAA14956@paris.e.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806182242.AAA14956@paris.e.kth.se>; from Marcus Sundberg on Fri, Jun 19, 1998 at 12:42:52AM +0200 Resent-Message-ID: <"wXVTq1.0.l37.-kTYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2885 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Marcus writes: > Andy, please have a loook at > http://www.ggi-project.org/mailinglist/mar98/603.html > and tell me which of the listed things should be > done and which are scrapped. One thing I'd like to see scrapped is the ggiGetGammaMap() and ggiSetGammaMap() functions. Few (if any) targets will support it, and few (if any) programs will ever use it. > I have some other questions regarding libggi as well: > > 1. Threads in libggi; is libggi supposed to simply be threadsafe, > or should it actually use threading internally? We can't rely on threads (one example: libpthreads uses SIGUSR1 and SIGUSR2 signals which the svgalib, fbdev and suidkgi targets also need). So IMHO, LibGGI shouldn't use threads at all. > 3. I'd like to move GGIdlcleanup into the ggi_visual_opdisplay > struct, so we only have one single entry-point into the > driver-libs. Any objections? Good idea. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Thu Jun 18 22:14:17 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA15065; Thu, 18 Jun 1998 22:14:14 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA00255; Thu, 18 Jun 1998 22:17:34 -0700 Resent-Date: Thu, 18 Jun 1998 22:17:34 -0700 Message-ID: <19980619001420.10058@fries.net> Date: Fri, 19 Jun 1998 00:14:20 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: CVS stuff References: <199806170845.KAA20789@cip8.e-technik.uni-erlangen.de> <35878920.1DBAA71E@suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <35878920.1DBAA71E@suntech.fr>; from Emmanuel Marty on Wed, Jun 17, 1998 at 09:15:12AM +0000 Resent-Message-ID: <"yNCuc.0.r3.jHVYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2887 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, Jun 17, 1998 at 09:15:12AM +0000, Emmanuel Marty wrote: > > Hartmut, waiting for orders. > > Hmm, I don't want you to think you're being imposed things - you've always > been doing a great job at documenting and you deserve to manage things the > way you like :) I too was under the impression that only sgml would be in the repository. Anything else adds bandwidth to mirroring and size to the cvs repository in the size of a dvi file everytime a single byte changes. I doubt this is what we want. I'm suggesting we not have anything but the sgml version of docs in the repository. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Thu Jun 18 22:14:52 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA15070; Thu, 18 Jun 1998 22:14:50 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA32691; Thu, 18 Jun 1998 22:15:27 -0700 Resent-Date: Thu, 18 Jun 1998 22:15:27 -0700 Message-ID: <19980619001215.04626@fries.net> Date: Fri, 19 Jun 1998 00:12:15 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: CVS stuff References: <199806161141.NAA10275@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from becka@rz.uni-duesseldorf.de on Tue, Jun 16, 1998 at 07:25:35PM +0200 Resent-Message-ID: <"7vxgY1.0.f-7.kFVYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2886 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, Jun 16, 1998 at 07:25:35PM +0200, becka@rz.uni-duesseldorf.de wrote: > An idea would be a simple script doing > > cd $(TOPLEVEL)/lib > cvs update -PAd > cd $(TOPLEVEL)/os > cvs update -PAd > cd $(TOPLEVEL)/config > cvs update -PAd > > etc., leaving out docs. > try: cvs update -PAd lib os config > It could even be placed in the main Makefile ... However, it would be simpler to simply have the snapshot builder build the docs so the tarballs people download have them. LessTif and I'm sure other gnu autoconf based packages, if you use 'cvs get lesstif' end up with no configure and require automake, autoconf, and other things just to run configure, before docs are even an issue. I do not see how requiring utilities for developers can be that hard. I know of no one who is using an os that doesn't have the necessary packages for building documentation. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Thu Jun 18 22:15:45 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA15075; Thu, 18 Jun 1998 22:15:43 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id WAA11360; Thu, 18 Jun 1998 22:21:12 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 22:21:12 -0700 (PDT) Message-ID: <19980619001548.37112@fries.net> Date: Fri, 19 Jun 1998 00:15:48 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: CVS stuff References: <199806170845.KAA20789@cip8.e-technik.uni-erlangen.de> <199806171036.MAA02668@legrelle.physik.tu-chemnitz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199806171036.MAA02668@legrelle.physik.tu-chemnitz.de>; from Steffen Seeger on Wed, Jun 17, 1998 at 12:36:12PM +0200 Resent-Message-ID: <"jak3U.0.In2.5LVYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2888 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, Jun 17, 1998 at 12:36:12PM +0200, Steffen Seeger wrote: > first delete them in your checkout, the > do a > > 'cvs delete ' You can actually get away with: cvs rm -f / .. etc.. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Thu Jun 18 23:06:04 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA15113; Thu, 18 Jun 1998 23:06:02 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id XAA24808; Thu, 18 Jun 1998 23:11:42 -0700 (PDT) Resent-Date: Thu, 18 Jun 1998 23:11:42 -0700 (PDT) Date: Thu, 18 Jun 1998 22:21:11 -0700 (PDT) From: Jesse Barnes To: ggi-develop@eskimo.com Subject: Dali segfault In-Reply-To: <19980619001215.04626@fries.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"z6jj2.0.S36.K4WYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2889 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I recently downloaded ggi-dali-final.tar.gz and all compiled correctly. However, when I try to run any of the demos, they segfault when they try to set the mode. I debugged the stars demo and the segfault happened during the call to ggiSetGraphMode(vis, GGI_AUTO, GGI_AUTO...). gdb reported the following: Program received signal SIGSEGV, Segmentation fault. 0x40783a82 in GGIdlinit (visual=0x6e696c64, version=0x47007469
) at visual.c:43 43 visual->opcolor->mapcolor=GGImapcolor; Any ideas why this could be happening? I linked libggi and the demos to both libdl.so.1 and libdl.so-2.0.7 to no avail (although the former caused the demos to segfault immediately, rather than flashing an X window on my display and then segfaulting). Thanks, Jesse Barnes "To err is human -- to blame it on the computer is even more so." - Anonymous From ggi-develop-request@eskimo.com Fri Jun 19 01:09:29 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA15280; Fri, 19 Jun 1998 01:09:26 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA00788; Fri, 19 Jun 1998 01:05:45 -0700 Resent-Date: Fri, 19 Jun 1998 01:05:45 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806190804.KAA21528@sunserver1.rz.uni-duesseldorf.de> Subject: Re: Misc libggi stuff In-Reply-To: <19980619131802.31982@ajax.netspace.net.au> from Andrew Apted at "Jun 19, 98 01:18:02 pm" To: ggi-develop@eskimo.com Date: Fri, 19 Jun 1998 10:04:24 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"IWngA1.0.CC.OlXYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2890 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > Andy, please have a loook at > > http://www.ggi-project.org/mailinglist/mar98/603.html > > and tell me which of the listed things should be > > done and which are scrapped. : - debug-output: : the new macros NOTICE, WARNING, ERROR, FATAL : will be introduced to graduate the debugging-information : which can be suppressed by ggiDebugLevel (LIBGGI_DEBUG). This should be done. As simple as in kernel by just using "<#>" as a prefix. Unprefixed prints should be treated as the highest possible level for smooth transition. One quick question back: Should we treat LIBGGI_DEBUG as a bitfield or as a "minimum error level" ? : - removing of unused includes in the files Yes - whoever finds such an occurence, please report, so we can fix this. It's only minor, I know, but ... : - standardized file format (especially the header) Yes. The coding standards are pretty well specified, but we need to standardize the header as well. However for this to happen, we will need to resolve the licensing debate. : - new (loadable) library managment: If the scheme mentioned here is available in code, we should mend it in to allow for static library builds. Thomas, Uwe ? : - new extension scheme: Done. Or has someone located a major flaw in the new scheme ? : macros like VIS_GC, VIS_MODE.. are renamed to : GGI_GC, GGI_MODE (according to the GGI namespace rules) This might be a good idea. Someone here to go over the sources and do it ? : - display drivers must provide the new function : int ggiGetSuggestStrings(ggi_visual_t vis, char ***suggestStrings, int *count); This is basically the ggiGetAPI call. : - the code is mostly rather unreadable ! : Coders, please remember, GGI is a GPL-project. : Other people might want to read, understand and improve the code. : We don't have to save disk space by using one-character variables : and an extra-tight coding style! : [Shouldn't this be added to the coding style rules?] Hmm - we should remove such places. Though I do not feel there are too many of them, but I simply might be too familiar with the code ... : - renaming/moving of include files: : : ggi/ggi.h -> ggi/types.h : libggi.h + libggi_db.h -> ggi.h : libggi2d.h -> ggi2d.h : threads.h -> ggi/threads.h Yes - this should be done ... patches please ... : - old stuff that will be deleted: : ggi_focus, ggiGetFB(vis), ggiGetBPP(vis), ggiGetColorsPerPixel(vis) Yep. > > 3. I'd like to move GGIdlcleanup into the ggi_visual_opdisplay > > struct, so we only have one single entry-point into the > > driver-libs. Any objections? > Good idea. Hmm - not sure about that. For aesthetic reasons, the current behaviour is nicer. However I see the advantage for targets where we will have to build the libdl functionality ourselves ... CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Fri Jun 19 05:00:36 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA15495; Fri, 19 Jun 1998 05:00:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA14436; Fri, 19 Jun 1998 04:55:39 -0700 Resent-Date: Fri, 19 Jun 1998 04:55:39 -0700 From: Andrew Apted Message-ID: <19980619174436.54944@ajax.netspace.net.au> Date: Fri, 19 Jun 1998 17:44:36 +1000 To: ggi-develop@eskimo.com Subject: Re: VGA issues Reply-To: ggi-develop@eskimo.com References: <199806182330.TAA08525@mentalnet.dyn.ml.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from MenTaLguY on Thu, Jun 18, 1998 at 08:02:57PM -0400 Resent-Message-ID: <"houR_3.0.QX3.v6bYr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2891 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com MenTaLguY writes: > > Well, the API certainly doesn't make it clear that you have 4 bits of > > background and 4 bits of foreground color. MenTaLGuY should add that > > to his open API issues on emulated text modes. > > Yes... I'll try to address that. As far as setting the GC background > properly, text mode drivers should override (chain, really) the > ggi[GS]etGCBackground() implementation -- I think that's possible from stubs > now for some time. I've also been pondering the best way of handling VGA text mode (GT_TEXT16) WRT the libggi drawing primitives. Here is my conclusions : 1) ggiGetPixel() gets the 16 bit values, and ggiPutPixel() puts the 16 bit values, *without* any conversion. Thus doing putpixel(0x1e42) would place a bright yellow 'C' on a blue background (assuming the normal palette). 2) ggiMapColor() finds the closest (4 bit) color in the palette, and returns it *shifted* left 12 times. Thus doing mapcolor(white) would return 0xf000. In this way we get behaviour like a graphics mode, where doing ggiPutPixel(ggiMapColor) will do the expected thing (like it was a 16 color 80x25 mode). [This assumes 4 bits of background i.e. no blinking]. 3) ggiSetGC{Fore,Back}ground() and ggiDrawXXX() don't need to do anything special. e.g. ggiSetGCForeground(vis, ggiMapColor(vis, {0xffff,0,0})); ggiDrawBox(vis, 0, 0, 40, 10); would draw a red box (as you'd expect). 4) ggiPutc(c) is equivalent to calling ggiPutPixel() with pixel = (VIS_GC.bgcol & 0xf000) | ((GC.fgcol & 0xf000) >> 4) | (c & 0xff). e.g. ggiSetGCBackground(vis, ggiMapColor(vis, {0,0,0xffff})); ggiSetGCForeground(vis, ggiMapColor(vis, {0,0xffff,0})); ggiPuts(vis, 0, 0, "hello"); would draw a green "hello" on a blue background (as you'd expect). OK, does that sound reasonable to everyone ? Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 19 10:01:12 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA15783; Fri, 19 Jun 1998 10:01:06 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA19815; Fri, 19 Jun 1998 09:58:19 -0700 Resent-Date: Fri, 19 Jun 1998 09:58:19 -0700 From: wolfwings@lightspeed.net Sender: wolfwings@lightspeed.net Reply-to: wolfwings@lightspeed.net To: ggi-develop@eskimo.com Date: Fri, 19 Jun 98 09:45:42 pst Subject: Re: VGA issues Message-id: <358a95b6.3da6.0@lightspeed.net> X-User-Info: 209.27.222.54 Resent-Message-ID: <"VR0hf3.0.Qr4.gYfYr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2892 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >2) ggiMapColor() finds the closest (4 bit) color in the palette, and > returns it *shifted* left 12 times. Thus doing mapcolor(white) would > return 0xf000. In this way we get behaviour like a graphics mode, Minor thought, but perhaps shift-added so the highest nibble is copies to all lower nibbles? So you get 0xFFFF instead of 0xF000, which avoids problems with the palette getting darker after repeated conversions and modifications. WolfWings ShadowFlight wolfwings@lightspeed.net From ggi-develop-request@eskimo.com Fri Jun 19 10:38:37 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA15835; Fri, 19 Jun 1998 10:38:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA32192; Fri, 19 Jun 1998 10:36:39 -0700 Resent-Date: Fri, 19 Jun 1998 10:36:39 -0700 Date: Sat, 20 Jun 1998 10:32:16 -0700 (MST) From: teunis To: ggi-develop@eskimo.com Subject: Re: Misc libggi stuff In-Reply-To: <19980619131802.31982@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"nNNCO1.0.ts7.b6gYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2893 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 19 Jun 1998, Andrew Apted wrote: > Marcus writes: > > > Andy, please have a loook at > > http://www.ggi-project.org/mailinglist/mar98/603.html > > and tell me which of the listed things should be > > done and which are scrapped. > > One thing I'd like to see scrapped is the ggiGetGammaMap() and > ggiSetGammaMap() functions. Few (if any) targets will support it, and > few (if any) programs will ever use it. Disagree. If even one device supports it, it should be present (somewhere). But in this case an extension should do... (libgamma?) > > I have some other questions regarding libggi as well: > > > > 1. Threads in libggi; is libggi supposed to simply be threadsafe, > > or should it actually use threading internally? > > We can't rely on threads (one example: libpthreads uses SIGUSR1 and > SIGUSR2 signals which the svgalib, fbdev and suidkgi targets also need). > So IMHO, LibGGI shouldn't use threads at all. 100% disagree. All -libraries- should be thread-safe. If libGGI is not threadsafe I won't use it. and LinuxThreads (afaik) doesn't use SIGUSR[1/2]. But then the big problem with those signals isn't threading: it's that Linux 2.0/glibc 2.0 and before only support 32 signals and more are needed. Hopefully this will be fixed for 2.2! (afaik it already is) But the simplest statement is: no threads and I won't use it :) (but who cares) > > 3. I'd like to move GGIdlcleanup into the ggi_visual_opdisplay > > struct, so we only have one single entry-point into the > > driver-libs. Any objections? > > Good idea. Agrees :) G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Fri Jun 19 10:52:21 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA15849; Fri, 19 Jun 1998 10:52:16 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA02077; Fri, 19 Jun 1998 10:49:11 -0700 Resent-Date: Fri, 19 Jun 1998 10:49:11 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: I have seen the stars... To: ggi-develop@eskimo.com Date: Fri, 19 Jun 1998 19:46:24 +0200 (MET DST) In-Reply-To: <199806182219.AAA14887@paris.e.kth.se> from "Marcus Sundberg" at Jun 19, 98 00:19:58 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"RgefP.0.JW.MIgYr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2896 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > ...demo of libggi running on my NT box! Somebody living near him - buy this guy a beer ! > I've finally got libggi to run with the CYGWIN32 environment. > This was basicly done by replacing dlopen/dlsym/dlclose > with LoadLibrary/GetProcAddress/FreeLibrary. Hmm - so the CYGWIN dl-things are broken - right ? > The stars demo was run on the xlib-target, displaying > on the free (but not very good...) win32 Xserver MiX. Nice ... > But this is however not the right way to do our win32 > port, because CYGWIN32 links everything to the cygwin DLL, > which has two major drawbacks: > - It's under the GPL (not LGPL), which only allows GPLed > code to be linked with it. Ouch - who chose that license ? Argh ! > - It's not threadsafe. Minor point ... few systems are :-/. > So now I have put my efforts into the mingw32 compiler, > which uses gcc to generate 100% native win32-binaries with > no licence restrictions. And it also has the nice feature > of being simple to compile as a crosscompiler (which > means I don't have to expose myself for the trauma of > using NT... ;) Great ! > PS. If anyone would like to have a binary/buildinstructions > for pgcc-1.0.3 compiled as a linux -> win32 crosscompiler > I'll make them available from my GGI page. DS. Yes - yes - yes ! CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 19 10:57:19 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA15861; Fri, 19 Jun 1998 10:57:17 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA02052; Fri, 19 Jun 1998 10:49:06 -0700 Resent-Date: Fri, 19 Jun 1998 10:49:06 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: libg* placement To: ggi-develop@eskimo.com Date: Fri, 19 Jun 1998 19:40:03 +0200 (MET DST) In-Reply-To: from "Rodolphe Ortalo" at Jun 18, 98 04:56:55 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"AfOZV1.0.xV.HIgYr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2895 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I will also need to load dynamic libraries, such as: > libggi/extensions/libgwt/default/display-stubs-gwt-blitting.so > libggi/extensions/libgwt/default/display-stubs-gwt-exposeevent.so > libggi/extensions/libgwt/default/display-stubs-gwt-X.so > with a conf in libggi/extensions/libgwt/libgwt.conf (in dist.) > > No problem with this ? Shouldn't be a problem ... you just add a .include to the libggi.conf and a libgwt.cont and all is well ... > >Anything else like wrappers, helper libs (that are not extensions) and > >such goes directly to /lib. > Hmmm. That's the problem with libgwt, all the functions dealing directly > and _only_ with the windows hierarchy may be viewed as helper libs. > Similarly, a "libggiregion" may be useful alone. But well, we'll see > when something work (:-). Yeah - well ... if parts need to be an extension, then I'd call the whole thing an extension ... CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 19 10:57:46 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA15867; Fri, 19 Jun 1998 10:57:43 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA02138; Fri, 19 Jun 1998 10:49:26 -0700 Resent-Date: Fri, 19 Jun 1998 10:49:26 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: LibGGI 1.4 Question To: ggi-develop@eskimo.com Date: Fri, 19 Jun 1998 19:43:01 +0200 (MET DST) In-Reply-To: <524299DFAB41D11193EF00805F8598024F669F@brekka.ch2m.com> from "Fulgham, Brent/SCO" at Jun 18, 98 09:54:16 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"1aAVx.0.IX.bIgYr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2897 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I'm segfaulting when I try to run any of the demo programs after > compiling LibGGI 1.4. Is this typical of everyone else's experiences, > or have I got something misconfigured? > > Segfault occurs (according to output with LIBGGI_DEBUG=255) immediately > after setting the mode (mode sets successfully, a "ggi on X" window > opens and stays open after segfault. Hmm - I know this behaviour from compiling LIBGGI with threads enabled. Unfortunately the X libs are not threadsafe, and though we do not use threads internally, the presence of the thread flags seems to annoy X. Could you check that ? If this isn't the case, could you try to track down the bug a bit further by using strace or gdb as well as LIBGGI_DEBUG=255 and posting the appropriate output ? CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 19 11:18:16 1998 Return-Path: Received: from mx2.eskimo.com (root@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA15880; Fri, 19 Jun 1998 11:18:14 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA02580; Fri, 19 Jun 1998 10:50:59 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 10:50:59 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Misc libggi stuff To: ggi-develop@eskimo.com Date: Fri, 19 Jun 1998 19:32:54 +0200 (MET DST) In-Reply-To: <199806182242.AAA14956@paris.e.kth.se> from "Marcus Sundberg" at Jun 19, 98 00:42:52 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"FQwjf3.0.5e.wJgYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2894 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > 1. Threads in libggi; is libggi supposed to simply be threadsafe, > or should it actually use threading internally? Threadsafe. We should avoid using threads except for targets where we are pretty sure that threads ability is always present. There are no such targets yet. BeOS might be a possible candidate. > 2. Currently the driver-libs are dlopen()ed for every visual of > the same type. Shouldn't this be handled like the extensions: > open once - use for many visuals. Hmm - some driver libs keep static internal state ... I am not sure, if this would work in that case. Actually on any sane implementation of dlopen, code-pages should be shared anyway, so I see little gain ... CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 19 12:47:52 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA15963; Fri, 19 Jun 1998 12:47:48 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA28339; Fri, 19 Jun 1998 12:50:50 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 12:50:50 -0700 (PDT) Date: Sat, 20 Jun 1998 12:46:12 -0700 (PDT) From: Nathan X-Sender: gblues@gblues To: ggi-develop@eskimo.com Subject: Re: LibGGI 1.4 Question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"8dj6-.0.ew6.O4iYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2898 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 19 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Hmm - I know this behaviour from compiling LIBGGI with threads enabled. > Unfortunately the X libs are not threadsafe, and though we do not use > threads internally, the presence of the thread flags seems to annoy X. Also after upgrading to libGGI 1.4.0 you have to recompile the demos because the upgrade breaks binary compatibility, due to functions requiring a pointer rather than the whole variable. Nathan gblues@jps.net From ggi-develop-request@eskimo.com Fri Jun 19 15:32:04 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA16095; Fri, 19 Jun 1998 15:31:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA28359; Fri, 19 Jun 1998 15:25:54 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 15:25:54 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: little bug To: ntucker@vax.area.com (Neal Tucker) Date: Fri, 19 Jun 1998 20:01:07 +0200 (MET DST) Cc: ggi-develop@eskimo.com (mailing list GGI) In-Reply-To: <19980619045848.A4667@vax.area.com> from "Neal Tucker" at Jun 19, 98 04:58:48 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"VT3Pp2.0.rw6.kLkYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2901 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi Neal ! > > > > > Oh, on building libggi... I was on IRC and got a couple people > > > > > interested in it, and one commented that he didn't like a "silent build", > > > > He's not the only one. > > > Well, the idea was to hide all complicated parts from newbie users, but > > Well - actually that's how it is. If you build from the toplevel make using > > the "newbie approach", you'll get a silent build. > > If you do "make" from the libggi subdirectory (as I thought any hacker would > > do - I even do make config by "joe .config" ...), you will get a verbose build. > [Andreas: I'm responding to you directly because the list claims I'm > not subscribed... O.K. - have forwarded this answer ... > Even as a hacker, I have been trained to expect certain things from a > "./configure", and have learned that that's what you do first (especially > when the readme encourages you to do so). I think the goal of automated- > for-newbies installs is a good one, but it seems that it's better suited > for a "release" (as opposed to devel/stable) distribution. Well - at least for the stable distribution, we should treat it just as a release. > As it is, the docs indicated that "configure" is the way you're *supposed* > to do things, and I would expect that even most hardcore hackers would just > go along with that, because they've generally got better things to do than > figure out what configure does and do it by hand. Well yes ... we should maybe warn them a little in the README and direct them to the right commands, if they want to see what is going on ... The point is, that the newbiew doesn't want to know, and many newbies are a bit afraid of big screenfuls of compiler output ... So I see you point, and I think we should resolve it in documentation by pointing "real hackers" to a section describing how to do things by hand and what configure actually does. > Also, a suggestion for the configure script, if you plan to leave it the > way it is: more info on what it's going to do... I was VERY startled to > have it suddenly patching my kernel source, and startled again to see that > I was dropped into a "make menuconfig". Actually that is, what I think should happen to a newbie, as he will probably not want to enter "make patch-kernel;cd /usr/src/linux;make menuconfig ..." But you are right, we should be a bit more verbose on what we are going to do and give a chance to say "NO !!!!!" ... > At that point, I wanted to bail, because I wasn't even sure what kernel > /usr/src/linux pointed to, and when I exited that, I was shocked and > horrified to see it do a "make clean" and start building the kernel > again. Now I'm scared to death of that configure script. *grin* ... Can't say much ... didn't use it often - developer you know ... Knows the Makefile and just makes what is needed ... > I wouldn't be completely surprised if it ran fdisk next time.. :-) *grin* It does, if it spots a Windows partition to make for some extra swap space ;-))). > Where I come from, "configure" is supposed to do just that: configure. O.K. - point taken ... would someone like to enhance the configure script to ask for confirmation every now and then, stating what it is going to do next ? Thanks, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 19 15:34:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA16101; Fri, 19 Jun 1998 15:34:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA27940; Fri, 19 Jun 1998 15:24:13 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 15:24:13 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Move gamma functions to misc ? To: ggi-develop@eskimo.com (mailing list GGI) Date: Fri, 19 Jun 1998 20:33:37 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"2fnMK1.0.Lq6.4KkYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2900 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! Should we move int ggiGetGamma(ggi_visual_t vis,ggi_float *r,ggi_float *g,ggi_float *b); int ggiSetGamma(ggi_visual_t vis,ggi_float r,ggi_float g,ggi_float b); int ggiGetGammaMap(ggi_visual_t vis,int s,int len,ggi_color *gammamap); int ggiSetGammaMap(ggi_visual_t vis,int s,int len,ggi_color *gammamap); to the "misc" extension ? It can be done generically there (i.e. every target would support it then, as soon as it is linked to libggimisc), by just having the default behaviour override (un)MapColor and friends. On targets that support gamma mapping in HW (like some KGI drivers), this could still be used ... So should we move it over or keep it in LibGGI ? No demo seems to use it, so we could just move it over - right ? CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 19 15:35:57 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA16106; Fri, 19 Jun 1998 15:35:56 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA27901; Fri, 19 Jun 1998 15:23:58 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 15:23:58 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: VGA issues To: ggi-develop@eskimo.com Date: Fri, 19 Jun 1998 20:03:27 +0200 (MET DST) In-Reply-To: <19980619174436.54944@ajax.netspace.net.au> from "Andrew Apted" at Jun 19, 98 05:44:36 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"tSPD7.0.rp6.yJkYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2899 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I've also been pondering the best way of handling VGA text mode > (GT_TEXT16) WRT the libggi drawing primitives. Here is my conclusions : > > 1) ggiGetPixel() gets the 16 bit values, and ggiPutPixel() puts the 16 > bit values, *without* any conversion. Thus doing putpixel(0x1e42) > would place a bright yellow 'C' on a blue background (assuming the > normal palette). > > 2) ggiMapColor() finds the closest (4 bit) color in the palette, and > returns it *shifted* left 12 times. Thus doing mapcolor(white) would > return 0xf000. In this way we get behaviour like a graphics mode, > where doing ggiPutPixel(ggiMapColor) will do the expected thing (like > it was a 16 color 80x25 mode). [This assumes 4 bits of background > i.e. no blinking]. > > 3) ggiSetGC{Fore,Back}ground() and ggiDrawXXX() don't need to do > anything special. > > e.g. ggiSetGCForeground(vis, ggiMapColor(vis, {0xffff,0,0})); > ggiDrawBox(vis, 0, 0, 40, 10); > > would draw a red box (as you'd expect). > > 4) ggiPutc(c) is equivalent to calling ggiPutPixel() with pixel = > (VIS_GC.bgcol & 0xf000) | ((GC.fgcol & 0xf000) >> 4) | (c & 0xff). > > e.g. ggiSetGCBackground(vis, ggiMapColor(vis, {0,0,0xffff})); > ggiSetGCForeground(vis, ggiMapColor(vis, {0,0xffff,0})); > ggiPuts(vis, 0, 0, "hello"); > > would draw a green "hello" on a blue background (as you'd expect). > > OK, does that sound reasonable to everyone ? It does to me. Implement and send patches, please. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 19 16:06:03 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA16122; Fri, 19 Jun 1998 16:06:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA10763; Fri, 19 Jun 1998 16:06:17 -0700 Resent-Date: Fri, 19 Jun 1998 16:06:17 -0700 Date: Sat, 20 Jun 1998 16:04:49 -0700 (MST) From: teunis To: ggi-develop@eskimo.com Subject: Re: CVS stuff In-Reply-To: <19980619001215.04626@fries.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"GPdyE1.0.-d2.exkYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2902 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 19 Jun 1998, Todd T. Fries wrote: > On Tue, Jun 16, 1998 at 07:25:35PM +0200, becka@rz.uni-duesseldorf.de wrote: > > An idea would be a simple script doing > > > > cd $(TOPLEVEL)/lib > > cvs update -PAd > > cd $(TOPLEVEL)/os > > cvs update -PAd > > cd $(TOPLEVEL)/config > > cvs update -PAd > > > > etc., leaving out docs. > > > > try: > cvs update -PAd lib os config > > > It could even be placed in the main Makefile ... > > However, it would be simpler to simply have the snapshot builder build the > docs so the tarballs people download have them. > > LessTif and I'm sure other gnu autoconf based packages, if you use > 'cvs get lesstif' end up with no configure and require automake, autoconf, > and other things just to run configure, before docs are even an issue. > I do not see how requiring utilities for developers can be that hard. > I know of no one who is using an os that doesn't have the necessary > packages for building documentation. I for one -HATE- LaTeX being required because I've never had the space... but if that's what it takes, I'll grumble, complain, produce text output and erase the docs afterwards. Either that or vgrep it. So does this require TeX? G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Fri Jun 19 17:15:03 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA16255; Fri, 19 Jun 1998 17:15:01 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA20381; Fri, 19 Jun 1998 17:21:04 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 17:21:04 -0700 (PDT) Date: Sat, 20 Jun 1998 17:17:10 -0700 (MST) From: teunis To: andreas.beck@ggi-project.org cc: ggi-develop@eskimo.com Subject: Re: Misc libggi stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Fduxw.0.H-4.h1mYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2903 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 19 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Hi ! > > > 1. Threads in libggi; is libggi supposed to simply be threadsafe, > > or should it actually use threading internally? > > Threadsafe. We should avoid using threads except for targets where we > are pretty sure that threads ability is always present. There are no > such targets yet. BeOS might be a possible candidate. linux using clone() - but linux has -lousy- thread-management code for that stuff.... *grin* (that's what I did until I started programming in Objective C/threaded which requires pthreads...) > > 2. Currently the driver-libs are dlopen()ed for every visual of > > the same type. Shouldn't this be handled like the extensions: > > open once - use for many visuals. > > Hmm - some driver libs keep static internal state ... I am not sure, if > this would work in that case. Actually on any sane implementation of > dlopen, code-pages should be shared anyway, so I see little gain ... static internal state not supported under Windows DLL's last time I looked (which I'll admit was back in the dark ages of win 3.1) Irregardless you're better initializing state with a function than depending on the OS to do it.... G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Fri Jun 19 17:28:19 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA16261; Fri, 19 Jun 1998 17:28:17 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA22343; Fri, 19 Jun 1998 17:32:42 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 17:32:42 -0700 (PDT) Message-Id: <199806200030.CAA07701@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: Misc libggi stuff In-reply-to: Your message of "Fri, 19 Jun 1998 10:04:24 +0200." <199806190804.KAA21528@sunserver1.rz.uni-duesseldorf.de> Date: Sat, 20 Jun 1998 02:30:23 +0200 From: Marcus Sundberg Resent-Message-ID: <"NE_KV3.0.wS5.cCmYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2904 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > : - debug-output: > : the new macros NOTICE, WARNING, ERROR, FATAL > : will be introduced to graduate the debugging-information > : which can be suppressed by ggiDebugLevel (LIBGGI_DEBUG). > > This should be done. As simple as in kernel by just using "<#>" as a prefix. > Unprefixed prints should be treated as the highest possible level for smooth > transition. "ERROR" clashes with win32 headers. I suggest we prefix all those with GGI to be on the safe side. > One quick question back: Should we treat LIBGGI_DEBUG as a bitfield or as > a "minimum error level" ? > : - removing of unused includes in the files > > Yes - whoever finds such an occurence, please report, so we can fix this. > It's only minor, I know, but ... I've removed a lot of those recently, but I know there're more lying around. It's a damn boring thing to do btw... ;) > : macros like VIS_GC, VIS_MODE.. are renamed to > : GGI_GC, GGI_MODE (according to the GGI namespace rules) > > This might be a good idea. Someone here to go over the sources and do it ? Done. I changed them to LIBGGI_* which I find more apropriate, but if you prefer GGI_* I'll change it again (takes just a single command to do it). > : - renaming/moving of include files: > : > : ggi/ggi.h -> ggi/types.h > : libggi.h + libggi_db.h -> ggi.h ggi/ggi.h currently only does: #include #include #include Should I replace all occurences of #include to the three #include lines above, or should ggi.h be renamed to something else? (IMO the former) > : libggi2d.h -> ggi2d.h I suppose this will be fixed when libggi2d is moved back into CVS... > : threads.h -> ggi/threads.h Hmmm? I'd rather say move the contents of threads.h into internal.h. > : - old stuff that will be deleted: > : ggi_focus, ggiGetFB(vis), ggiGetBPP(vis), ggiGetColorsPerPixel(vis) > > Yep. Done. But what are these lines? ./display/glide/events.c: ggievent.any.focus = 0; ./display/suidkgi/kbd.c: kbd_event.key.focus = 0; ./display/suidkgi/mouse.c: mouse_event.pmove.focus = 0; ./display/suidkgi/mouse.c: mouse_event.pbutton.focus = 0; > > > 3. I'd like to move GGIdlcleanup into the ggi_visual_opdisplay > > > struct, so we only have one single entry-point into the > > > driver-libs. Any objections? > > Good idea. > > Hmm - not sure about that. For aesthetic reasons, the current behaviour > is nicer. However I see the advantage for targets where we will have to > build the libdl functionality ourselves ... Huh? ;) I completely fail to see any aesthetic reason in either way of doing it. I just know it's plain unneccesary to get the cleanup function with dlsym(), and as you say it may also cause trouble on some targets. > > 2. Currently the driver-libs are dlopen()ed for every visual of > > the same type. Shouldn't this be handled like the extensions: > > open once - use for many visuals. > > Hmm - some driver libs keep static internal state ... I am not sure, if > this would work in that case. Then they are broken and should be fixed. Keeping internal state is what the private entry in the visual struct is for. (The ones that can't be fixed are the ones that uses signals in sync mode, and they'll break horribly if you try to have multiple visuals open anyway...) //Marcus From ggi-develop-request@eskimo.com Fri Jun 19 19:03:59 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA16321; Fri, 19 Jun 1998 19:03:56 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA08317; Fri, 19 Jun 1998 19:02:56 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 19:02:56 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Misc libggi stuff To: ggi-develop@eskimo.com Date: Sat, 20 Jun 1998 00:24:43 +0200 (MET DST) In-Reply-To: from "teunis" at Jun 20, 98 10:32:16 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"9cuJV3.0.p12.BXnYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2905 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com HI ! > > One thing I'd like to see scrapped is the ggiGetGammaMap() and > > ggiSetGammaMap() functions. Few (if any) targets will support it, and > > few (if any) programs will ever use it. > > Disagree. If even one device supports it, it should be present > (somewhere). But in this case an extension should do... (libgamma?) This is how he meant it. See my proposal for moving Gamma things to the misc extension. > > > 1. Threads in libggi; is libggi supposed to simply be threadsafe, > > > or should it actually use threading internally? > > We can't rely on threads (one example: libpthreads uses SIGUSR1 and > > SIGUSR2 signals which the svgalib, fbdev and suidkgi targets also need). > > So IMHO, LibGGI shouldn't use threads at all. > > 100% disagree. All -libraries- should be thread-safe. Read question and answer carefully. He says we shouldn't _use_ threads _in_ LibGGI and I agree with that. Making it thread_safe_ is another issue. We should try to do that whereever possible. CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 19 19:06:47 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA16330; Fri, 19 Jun 1998 19:06:45 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA10591; Fri, 19 Jun 1998 19:12:45 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 19:12:45 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: LibGGI 1.4 Question To: BFulgham@CH2M.com (Fulgham Brent/SCO) Date: Sat, 20 Jun 1998 00:32:22 +0200 (MET DST) Cc: ggi-develop@eskimo.com (mailing list GGI) In-Reply-To: <524299DFAB41D11193EF00805F8598026AA068@brekka.ch2m.com> from "Fulgham, Brent/SCO" at Jun 19, 98 03:09:42 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"XtEcF2.0.Nb2.RgnYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2906 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > Yes. I deactivated threads and now the demo programs work. However, > when running the ggiMesa port (under Mesa3.0beta5) I get segfaults when > trying to run the gears demo. LibGGI 1.4 breaks ggiMesa, but Graydon > Hoare generated a fix and has gotten gears running on his system. > > Jordan Mendellson and I have both experienced the same thing when using > LibGGI 1.4 under mesa. Behavior is that a blank window opens with black > background titled "GGI on X". Then the program segfaults and the window > closes. I get: > > ggimesa: GGIMesaCreateContext: > ggimesa: GGIMesaCreateContext: done. > ggimesa: GGIMesaSetVisual: > ggimesa: setup_driver=NULL ! > ggimesa: Please check your config files! > Segmentation fault > > Based on this output I reviewed my libggi.conf, ggimesa.conf, and the > location of the extension libraries created by ggi. All seem to be in > order. I am using a 16bpp X-display, and setting my gears demo for > 16bpp. Hmm - check that ggimesa.conf is actually ".include"d in libggi.conf. This is the common reason for this error. > I'm attaching an strace because none of us (on the Berlin Project) can > figure out why it's working for Graydon, and not the rest of us... > open("/etc/ggi/libggi.conf", O_RDONLY) = 3 > fstat(3, {st_mode=0, st_size=0, ...}) = 0 > mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x4015e000 > read(3, "# Mapping file for suggest-strin"..., 4096) = 3371 > brk(0x804d000) = 0x804d000 > open("/etc/ggi/libggi2d.conf", O_RDONLY) = -1 ENOENT (No such file or > directory) > read(3, "", 4096) = 0 > close(3) = 0 Gotcha. That should be it. While /etc/ggi/libggi2d.conf is tried to be ".included" (but fails, as the file isn't there), noone tries to include /etc/ggi/ggimesa.conf ... Thus the mesa extension cannot resolve the locations of the libraries. Putting the right .include in should solve it ... CU, ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 19 19:21:38 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA16337; Fri, 19 Jun 1998 19:21:37 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA06860; Fri, 19 Jun 1998 19:24:01 -0700 Resent-Date: Fri, 19 Jun 1998 19:24:01 -0700 Date: Sat, 20 Jun 1998 19:22:31 -0700 (MST) From: teunis To: andreas.beck@ggi-project.org cc: ggi-develop@eskimo.com Subject: Re: Misc libggi stuff (threading) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"9JBBJ.0.tg1.0rnYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2907 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 20 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > HI ! > > [on gamma] > This is how he meant it. See my proposal for moving Gamma things to > the misc extension. Got it - (that message just arrived) > > > > 1. Threads in libggi; is libggi supposed to simply be threadsafe, > > > > or should it actually use threading internally? > > > We can't rely on threads (one example: libpthreads uses SIGUSR1 and > > > SIGUSR2 signals which the svgalib, fbdev and suidkgi targets also need). > > > So IMHO, LibGGI shouldn't use threads at all. > > > > 100% disagree. All -libraries- should be thread-safe. > > Read question and answer carefully. He says we shouldn't _use_ threads _in_ > LibGGI and I agree with that. Making it thread_safe_ is another issue. > We should try to do that whereever possible. Gleah. Well IMHO threads should exist on all platforms *le really deep sigh*..... Sorry 'bout that. (boku wa baku desu...) Hmmm - now how to -test- thread-compliance? Gonna have to think of something.... BTW - anyone running GGI under an SMP (or equiv) architecture? G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Fri Jun 19 19:26:24 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA16342; Fri, 19 Jun 1998 19:26:21 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA13937; Fri, 19 Jun 1998 19:30:52 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 19:30:52 -0700 (PDT) From: Andrew Apted Message-ID: <19980620122425.45096@ajax.netspace.net.au> Date: Sat, 20 Jun 1998 12:24:25 +1000 To: ggi-develop@eskimo.com Subject: Re: Misc libggi stuff Reply-To: ggi-develop@eskimo.com References: <199806190804.KAA21528@sunserver1.rz.uni-duesseldorf.de> <199806200030.CAA07701@zafir.e.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806200030.CAA07701@zafir.e.kth.se>; from Marcus Sundberg on Sat, Jun 20, 1998 at 02:30:23AM +0200 Resent-Message-ID: <"7x_UW1.0.YP3.OxnYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2908 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Marcus writes: > But what are these lines? > > .../display/suidkgi/kbd.c: kbd_event.key.focus = 0; > .../display/suidkgi/mouse.c: mouse_event.pmove.focus = 0; > .../display/suidkgi/mouse.c: mouse_event.pbutton.focus = 0; I'll fix those ASAP. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 19 19:39:30 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA16347; Fri, 19 Jun 1998 19:39:29 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA11021; Fri, 19 Jun 1998 19:40:33 -0700 Resent-Date: Fri, 19 Jun 1998 19:40:33 -0700 From: Andrew Apted Message-ID: <19980620123614.13004@ajax.netspace.net.au> Date: Sat, 20 Jun 1998 12:36:14 +1000 To: ggi-develop@eskimo.com Subject: Re: Move gamma functions to misc ? Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from becka@rz.uni-duesseldorf.de on Fri, Jun 19, 1998 at 08:33:37PM +0200 Resent-Message-ID: <"cGKbV1.0.4i2.V4oYr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2909 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andy writes : > Should we move > > int ggiGetGamma(ggi_visual_t vis,ggi_float *r,ggi_float *g,ggi_float *b); > int ggiSetGamma(ggi_visual_t vis,ggi_float r,ggi_float g,ggi_float b); > > int ggiGetGammaMap(ggi_visual_t vis,int s,int len,ggi_color *gammamap); > int ggiSetGammaMap(ggi_visual_t vis,int s,int len,ggi_color *gammamap); > > to the "misc" extension ? > It can be done generically there (i.e. every target would support it then, > as soon as it is linked to libggimisc), by just having the default behaviour > override (un)MapColor and friends. What is ggiSetGammaMap() supposed to do anyway ? Also, I don't understand how you intend to do this "generically" -- I guess you're talking just palettized modes, yeah ? [otherwise you need to redraw the whole screen when the gamma changes] [or give the app an Redraw-Screen event :-))]. > On targets that support gamma mapping in HW (like some KGI drivers), this > could still be used ... > > So should we move it over or keep it in LibGGI ? I'm going to be adding support for ggiSetGamma() in the emulation targets (trueemu, palemu and monotext), so I'd say keep this one in LibGGI, and put ggiSetGammaMap() into misc. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 19 20:34:25 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA16359; Fri, 19 Jun 1998 20:34:24 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id UAA20103; Fri, 19 Jun 1998 20:32:05 -0700 Resent-Date: Fri, 19 Jun 1998 20:32:05 -0700 Message-ID: <19980619222848.03054@fries.net> Date: Fri, 19 Jun 1998 22:28:48 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: CVS stuff References: <19980619001215.04626@fries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from teunis on Sat, Jun 20, 1998 at 04:04:49PM -0700 Resent-Message-ID: <"Brj7.0.-v4.rqoYr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2910 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, Jun 20, 1998 at 04:04:49PM -0700, teunis wrote: > I for one -HATE- LaTeX being required because I've never had the space... > but if that's what it takes, I'll grumble, complain, produce text output > and erase the docs afterwards. Either that or vgrep it. > > So does this require TeX? Do you honestly say you need to generate the dvi/postscript files? I believe they only require tex. If you need to compile documentation to work on drivers .. hrm, I think it is available online in html form anyway. Basically, anyone who produces snapshot tar files would need the required utilities. I volunteer as I have ample space for any utilities that might be needed (if I don't already have them installed..). -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Fri Jun 19 22:00:04 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA16414; Fri, 19 Jun 1998 21:59:57 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA09217; Fri, 19 Jun 1998 21:59:22 -0700 (PDT) Resent-Date: Fri, 19 Jun 1998 21:59:22 -0700 (PDT) Date: Sat, 20 Jun 1998 00:56:43 -0400 (EDT) From: Steve Cheng Sender: steve@maxt7m16.ipoline.com To: Justin Hahn cc: GGI Mailing List Subject: Re: Suggestion on licensing for you... In-Reply-To: <199806192254.SAA25409@raven.bu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"-m2we2.0.uF2.e6qYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2911 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 19 Jun 1998, Justin Hahn wrote: > Was skimming your IRC logs, here's something that might work for ya: > Ah, I'm just summarizing the logs, I'm really not that interested in licensing. I'll forward this to the GGI mailing list. > Require that all code be the property, copyright, etc. of the GGI > project, Unfortunately, the GGI Project is not a legal entity, and cannot own copyrights. > or whoever the accepted maintainer is (this requires > appointing someone whose role is equivalent to Linus in Linux kernel > devel.) I think this is too much of a hassle, and some might want "control" over their code. > Then they have the right to issue code under any and all > licenses they wish, including multiple licenses (the GPL doesn't say > you can't issue your source code under several licenses, or even sell > it under a commercial license AND GPL it. It'd be illegal for it to do so.) > > That way people under BSD license can accept BSD. People under GPL can > accept GPL. Etc. Actually, this IS the problem. Some GGI contributors do not accept the BSD license (vendors could close the source); others do not like the (L)GPL. > > Hope that helps you some. It makes the most legal sense. Moreover, > anything that goes into a kernel may need to be considered property of > the kernel developer, and hence you'd lose the copyright on it anyhow... > > > I'll stop here since I haven't caught up with the latest licensing wars on the mailing list :-) Thanks anyway for the comments. -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Fri Jun 19 22:01:39 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA16421; Fri, 19 Jun 1998 22:01:38 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA28808; Fri, 19 Jun 1998 22:00:29 -0700 Resent-Date: Fri, 19 Jun 1998 22:00:29 -0700 X-Authentication-Warning: mir.inazuma.dyn.ml.org: tetron owned process doing -bs Date: Sat, 20 Jun 1998 01:08:28 -0400 (EDT) From: Peter Amstutz X-Sender: amstpi@mir.inazuma.dyn.ml.org Reply-To: amstpi@freenet.tlh.fl.us To: ggi-develop@eskimo.com Subject: Re: Misc libggi stuff (threading) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Un_8b3.0.x17.j7qYr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2912 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 20 Jun 1998, teunis wrote: > Hmmm - now how to -test- thread-compliance? Gonna have to think of How about a mandelbrot using some n^2 threads, where each thread renders its square and try to draw simultaniously via (hopefully threadsafe) libggi? > something.... BTW - anyone running GGI under an SMP (or equiv) > architecture? 2.1.103-SMP /w dual p200 right here. Not using a ggi kernel at the moment though *sigh* What do you want to know? Peter Amstutz /* E-mail: amstpi@freenet.tlh.fl.us Home Page: http://www.freenet.tlh.fl.us/~amstpi/ Geek Code: (see http://www.geekcode.com/ for decoding instructions) GCS d- s:+ a--- C++>$ UL++++>$ P+(++) L++>$ E W++ N+ !o K w-- !O M-() !V PS+(++) PE-(--) Y+ PGP t 5++ X+ R tv b+ DI+ D++ G e h */ From ggi-develop-request@eskimo.com Sat Jun 20 00:34:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA16495; Sat, 20 Jun 1998 00:34:08 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA02878; Sat, 20 Jun 1998 00:33:46 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 00:33:46 -0700 (PDT) From: Andrew Apted Message-ID: <19980620125956.55617@ajax.netspace.net.au> Date: Sat, 20 Jun 1998 12:59:56 +1000 To: ggi-develop@eskimo.com Subject: Re: Misc libggi stuff Reply-To: ggi-develop@eskimo.com References: <19980619131802.31982@ajax.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from teunis on Sat, Jun 20, 1998 at 10:32:16AM -0700 Resent-Message-ID: <"nwtIP3.0.ri.ONsYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2913 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com teunis writes: > > We can't rely on threads (one example: libpthreads uses SIGUSR1 and > > SIGUSR2 signals which the svgalib, fbdev and suidkgi targets also need). > > So IMHO, LibGGI shouldn't use threads at all. > > 100% disagree. All -libraries- should be thread-safe. If libGGI is not > threadsafe I won't use it. Thread safe: definitely ! Threads required: no. > and LinuxThreads (afaik) doesn't use SIGUSR[1/2]. Pthreads was using SIGUSR[1/2] at least 9 months ago when I was writing a threaded SVGAlib app. Since SVGAlib also uses them, I ended up having to recompiling pthreads to use two other signals (SIGUNUSED and SIGSTKFLT IIRC). [This combo highly unrecommended BTW, a mega PITA]. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Sat Jun 20 00:46:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA16533; Sat, 20 Jun 1998 00:46:51 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA04313; Sat, 20 Jun 1998 00:52:36 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 00:52:36 -0700 (PDT) Date: Sat, 20 Jun 1998 00:49:12 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: Degas stuff Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"C4eW-2.0.F31.1fsYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2914 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I finally got a chance to download the latest Degas devel snapshot (I can't get CVS access at the moment) and play with it a bit. Overall, it looks very nice but there are a few bumps (2.1.106, EGCS). Here are some issues I ran into, apologies if any of these have already been brought up: ========== - The 2.1.105 patch patched 2.1.106 cleanly - README.INSTALL still refers to 0.0.9 (should be 0.1.0?) and libggi-dynamic (should be just plain libggi). - When I tried to run through the top-level make (the one that uses dialog), every sub-make (kernel patch, libggi, etc) failed due to a missing "gmake". What is gmake? I change the makefile to use "make" instead of "gmake" and it seemed to work fine.... - There are a couple of places in the makefile system where the makefiles don't seem to know where certain subdirectories are. I ended up going back to the older "make patch_kernel" system, which seemed to work OK. - Old one: the KGI "insert" script assumes the presence of a compiled serial mouse driver. - Old one #2: The "graphic" KGI driver sub-module handles acceleration and would make more sense if called "accel" or something similar. - The KGI config system refers to a "Herculus" clock driver |->. - Pedantry: The KGI driver module is currently called "ggidrv.o", which is somewhat misleading. Maybe "kgidrv.o" would make more sense.... - The VGA driver compiles, but upon module insertion I get an oops (divide error) which leaves the module inserted but /dev/graphic not working (probably dies partway through initialization). - The VGA driver seems to always set the compiled-in clut.inc (lovely pastel textmode colors) on module insertion, which renders my jed color syntax highlighting unusable. Any way we could make that an #ifdef and off by default? - No scrollback |-<. Anything I can easily tweak to turn this back on? - The KGI/util directory still lacks a proper makefile and is not integrated with the rest of the Degas makefile system. - The biggie: I can't get LibGGI to work with any targets. It always dies complaining about not being able to open a default visual, and it dies the same way with the same errors no matter which target is selected for use. ========== I am working on updating the Glide target and adding it back into the makefile system. I have it compiling without errors, but I can't test it until I get past that LibGGI showstopper problem. Also, I am planning on porting the Trio64V+ driver over to the new system, hopefully this weekend. Overall, though, I have to say that Degas looks really nice so far. The new directory structure is MUCH better and easier to navigate! The addition of EvStack and the kernel "make config" options are also cool. Kudos to everyone involved! Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 20 03:09:01 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA16686; Sat, 20 Jun 1998 03:09:00 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA19306; Sat, 20 Jun 1998 03:07:46 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 03:07:46 -0700 (PDT) Message-Id: <199806201005.MAA10917@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: Degas stuff In-reply-to: Your message of "Sat, 20 Jun 1998 00:49:12 PDT." Date: Sat, 20 Jun 1998 12:05:29 +0200 From: Marcus Sundberg Resent-Message-ID: <"M5nsL2.0.Yj4.mduYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2915 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > - When I tried to run through the top-level make (the one that uses > dialog), every sub-make (kernel patch, libggi, etc) failed due to a > missing "gmake". What is gmake? I change the makefile to use "make" > instead of "gmake" and it seemed to work fine.... gmake is GNU make ofcourse. ;) Most non-Linux systems has another make than GNU's, and most of them has GNU make installed as gmake. Problem was I made a typo in the configure script, preventing correct detection of gmake abcense. This diff (allready commited) will fix the problem: diff -r1.2 configure 49c49 < if [ "$?" = "0" ]; then --- > if [ "$?" = "1" ]; then > - The biggie: I can't get LibGGI to work with any targets. It always dies > complaining about not being able to open a default visual, and it dies the > same way with the same errors no matter which target is selected for use. I don't know about the stable repository, but the devel repository works for me on Linux glibc2, HP-UX, Digital Unix and Windows NT... Thus I find it particularly weird that several people reports that it completely fails to run. I can see four reasons for that: 1. You compiled libggi with threads enabled. This does not work yet, and I'll disable it in the configure script until it works to avoid confusing bugreports. 2. You did something wrong, which is unlikely if you used the present Makefile/configure system. 3. Your system is broken. 4. You have some old libggi stuff hanging around in the wrong place. //Marcus From ggi-develop-request@eskimo.com Sat Jun 20 03:15:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA16693; Sat, 20 Jun 1998 03:15:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA21051; Sat, 20 Jun 1998 03:20:30 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 03:20:30 -0700 (PDT) Message-Id: X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: GGI mailing list Subject: New LIBGGI demo, iXalance Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Jun 1998 13:13:09 +0300 From: Jarno Paananen Resent-Message-ID: <"FfOhW1.0.p85.hpuYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2916 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi, I've just completed porting the pretty well-known demo loader system iXalance (see http://www.tbl.org/win32.htm) to Linux with LIBGGI. It is used to run former DOS demos accessing the hw with a certain interface that has been now available for Win32 in the form of iXalance. The demos are The Black Lotus' marvelous 64k-intros Stash and Jizz and demo Astral Blur. Now you can watch these demos also under Linux, in X-window beside your Netscape if you want ;-) It draws directly to a memory display and uses ggiCrossBlit to draw it on the screen so it doesn't use that much of the LIBGGI's potential. The package can be downloaded from http://www.s2.org/~jpaana/iXalance- 0.1.tar.gz Comments welcome to my own address so I'll notice them :-) Regards, Jarno -- Jarno Mikael Paananen - Panama, kelionnen raja - jpaana@iki.fi From ggi-develop-request@eskimo.com Sat Jun 20 03:43:16 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA16722; Sat, 20 Jun 1998 03:43:14 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA22541; Sat, 20 Jun 1998 03:46:13 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 03:46:13 -0700 (PDT) Date: Sat, 20 Jun 1998 12:41:08 +0200 (CEST) From: Emmanuel Marty X-Sender: core@core To: ggi-develop@eskimo.com cc: jpaana@s2.org Subject: Re: New LIBGGI demo, iXalance Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"JkvsW.0.5W5.pBvYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2917 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi :) Jarno Paananen as in, the person who wrote ThePlayer (wow, that sends me back to the Amiga times.. what was your group.. *thinks* Sahara Surfers, right? Hmm, s2.org, I guess I am :) and MIDAS ? Welcome aboard ! > I've just completed porting the pretty well-known demo loader system > iXalance (see http://www.tbl.org/win32.htm) to Linux with LIBGGI. GREAT! We owe you a beer (or two..). I haven't followed the PC scene much ever, so that'll probably be stupid questions : 1) how many iXalance-compliant demos are there at the moment, and is that becoming a sort of standard? Getting them ALL to run under libggi sounds sweet.. :) 2) your loader will read, fixup and run iXalance-compliant demos assembled for win32 just fine, or do they have to be reassembled for linux/ELF first? (or rather, did you use your own executable format :) GGI, besides allowing non-setuid graphics, really aims at games and demos. Right now we miss a couple of things that aren't present in win32 either but that we'd like to have, such as proper vsync.. Linux is a PITA with that, if you want to help Brian S. Julin (who's working on that at the moment), that'd be great.. And all tricks that were possible under DOS, aren't under windoze anymore, and speed non-hw-accelerated systems by a large factor when programmed properly .. Btw the URL above didn't work, but I could find it easily at : http://www.tbl.org/tbl32.htm (saying that for other people that want to download your demos) Ok, I'm going to kill my poor home ISDN line downloading all TBL demos and trying iXalance under GGI.. :) -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 20 04:07:43 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA16745; Sat, 20 Jun 1998 04:07:41 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA23611; Sat, 20 Jun 1998 04:07:25 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 04:07:25 -0700 (PDT) Date: Sat, 20 Jun 1998 13:02:21 +0200 (CEST) From: Emmanuel Marty X-Sender: core@core To: ggi-develop@eskimo.com cc: jpaana@s2.org Subject: Re: New LIBGGI demo, iXalance Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"BKbF2.0.lm5.hVvYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2918 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I just tested it (see previous message :), it works for me. I guess the question about 'own executable format' is answered :) *gawps at Astral Blur* You should add an option in iXelata/libggi for it to use DirectBuffer instead of a memory visual and crossblit - half of the KGI drivers don't implement blit acceleration, so when ones displays through the KGI target it might be a good idea (just do it as an option to the end-user).. What do you think? Thanks a million times for your work.. You have no idea how happy I am to finally run demos under GGI. -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 20 04:26:20 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA16777; Sat, 20 Jun 1998 04:26:03 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA24802; Sat, 20 Jun 1998 04:26:26 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 04:26:26 -0700 (PDT) Sender: duff@eskimo.com Message-ID: <358B9BDD.9298D06E@cip.informatik.uni-erlangen.de> Date: Sat, 20 Jun 1998 13:24:13 +0200 From: Andreas Vogler X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.105 i586) MIME-Version: 1.0 To: GGI-develop@eskimo.com Subject: Kernel patching Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"vGn8u3.0.P36.WnvYr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2919 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi it seems to me that a lot of things (especially kernel patching) have been broken by the dali->degas move. Where have the missing parts gone (e.g. the autodetection of kernel source version) and will they reappear or do we have to do it all again? Andreas -- / \ "All that we see or seem \ / / \ is but a dream within a dream" E.A. Poe \ / From ggi-develop-request@eskimo.com Sat Jun 20 05:19:33 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA16862; Sat, 20 Jun 1998 05:19:32 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA00634; Sat, 20 Jun 1998 05:23:41 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 05:23:41 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Misc libggi stuff To: ggi-develop@eskimo.com Date: Sat, 20 Jun 1998 14:14:31 +0200 (MET DST) In-Reply-To: <199806200030.CAA07701@zafir.e.kth.se> from "Marcus Sundberg" at Jun 20, 98 02:30:23 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"O6sIN3.0.m9.BdwYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2920 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > : the new macros NOTICE, WARNING, ERROR, FATAL > > This should be done. As simple as in kernel by just using "<#>" as a prefix. > > Unprefixed prints should be treated as the highest possible level for smooth > > transition. > "ERROR" clashes with win32 headers. I suggest we prefix all those with > GGI to be on the safe side. YES. > > : - removing of unused includes in the files > I've removed a lot of those recently, but I know there're more lying around. > It's a damn boring thing to do btw... ;) Maybe someone to write a script the does something like going through a list of "#include" lines and then doing something like cat $file | grep -v "$currtestinclude" >bla.c ; gcc -o bla bla.c 2>&1 | grep prototype ? Might be a challenge for a script programmer - right ? > > : macros like VIS_GC, VIS_MODE.. are renamed to > > : GGI_GC, GGI_MODE (according to the GGI namespace rules) > Done. I changed them to LIBGGI_* which I find more apropriate, but if you > prefer GGI_* I'll change it again (takes just a single command to do it). LIBGGI is fine with me. > ggi/ggi.h currently only does: > #include > #include > #include > > Should I replace all occurences of #include to the three > #include lines above, or should ggi.h be renamed to something else? > (IMO the former) I agree with you. > > : threads.h -> ggi/threads.h > Hmmm? I'd rather say move the contents of threads.h into internal.h. Yep. > But what are these lines? > > ./display/glide/events.c: ggievent.any.focus = 0; > ./display/suidkgi/kbd.c: kbd_event.key.focus = 0; > ./display/suidkgi/mouse.c: mouse_event.pmove.focus = 0; > ./display/suidkgi/mouse.c: mouse_event.pbutton.focus = 0; Leave them alone. They are just setting a dummy entry which makes no sense under these targets. It has nothing to do with the old "SetFocus" thingy. > > Hmm - not sure about that. For aesthetic reasons, the current behaviour > > is nicer. However I see the advantage for targets where we will have to > > build the libdl functionality ourselves ... > > Huh? ;) I completely fail to see any aesthetic reason in either way > of doing it. *grin* Symmetry. > I just know it's plain unneccesary to get the cleanup function with > dlsym(), and as you say it may also cause trouble on some targets. I just found a reason ... loader code is to be generic to handle normal libs as well as extension libs ... This forbids storing the exit info in something like the visual-ops. The only way would be to get it from the init function at startup time. I'd say leave that for now. Even if we have to hack a dlopen for some broken targets, it is no big deal to have 2 two fixed entry points instead of only one. > > Hmm - some driver libs keep static internal state ... I am not sure, if > > this would work in that case. > Then they are broken and should be fixed. Keeping internal state is > what the private entry in the visual struct is for. Yes. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 20 05:35:27 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA16877; Sat, 20 Jun 1998 05:35:26 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA03384; Sat, 20 Jun 1998 05:41:17 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 05:41:17 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Degas stuff To: ggi-develop@eskimo.com Date: Sat, 20 Jun 1998 14:33:26 +0200 (MET DST) In-Reply-To: from "Jon M. Taylor" at Jun 20, 98 00:49:12 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"sNorW3.0.lq.htwYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2921 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > - README.INSTALL still refers to 0.0.9 (should be 0.1.0?) and > libggi-dynamic (should be just plain libggi). Should be fixed. > - When I tried to run through the top-level make (the one that uses > dialog), every sub-make (kernel patch, libggi, etc) failed due to a > missing "gmake". What is gmake? I change the makefile to use "make" > instead of "gmake" and it seemed to work fine.... We should never directly refer to such things. $(MAKE) is here for that. > - There are a couple of places in the makefile system where the makefiles > don't seem to know where certain subdirectories are. I ended up going > back to the older "make patch_kernel" system, which seemed to work OK. Can you track and fix these ? > - Old one: the KGI "insert" script assumes the presence of a compiled > serial mouse driver. I assume it does not harm, if it isn't there, except for the error message - right ? > - Old one #2: The "graphic" KGI driver sub-module handles acceleration > and would make more sense if called "accel" or something similar. Yeah. Shall I move that in the repository or shall we do the "clean" way of cvs remove / cvs add ? > - The KGI config system refers to a "Herculus" clock driver |->. Fix that typo, please. > - Pedantry: The KGI driver module is currently called "ggidrv.o", which > is somewhat misleading. Maybe "kgidrv.o" would make more sense.... Yes. Fixes welcome. > - The biggie: I can't get LibGGI to work with any targets. It always dies > complaining about not being able to open a default visual, and it dies the > same way with the same errors no matter which target is selected for use. Could you strace it and send LIBGGI_DEBUG output ? CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 20 05:37:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA16884; Sat, 20 Jun 1998 05:37:52 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA03782; Sat, 20 Jun 1998 05:43:19 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 05:43:19 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Move gamma functions to misc ? To: ggi-develop@eskimo.com Date: Sat, 20 Jun 1998 14:35:30 +0200 (MET DST) In-Reply-To: <19980620123614.13004@ajax.netspace.net.au> from "Andrew Apted" at Jun 20, 98 12:36:14 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"GNrCc.0.uw.XvwYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2922 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Andy writes : > > > Should we move > > > > int ggiGetGamma(ggi_visual_t vis,ggi_float *r,ggi_float *g,ggi_float *b); > > int ggiSetGamma(ggi_visual_t vis,ggi_float r,ggi_float g,ggi_float b); > > > > int ggiGetGammaMap(ggi_visual_t vis,int s,int len,ggi_color *gammamap); > > int ggiSetGammaMap(ggi_visual_t vis,int s,int len,ggi_color *gammamap); > > > > to the "misc" extension ? > > It can be done generically there (i.e. every target would support it then, > > as soon as it is linked to libggimisc), by just having the default behaviour > > override (un)MapColor and friends. > > What is ggiSetGammaMap() supposed to do anyway ? > > Also, I don't understand how you intend to do this "generically" -- I > guess you're talking just palettized modes, yeah ? [otherwise you need > to redraw the whole screen when the gamma changes] Yes - this is how I meant it. If you set gamma at the very start, all is well. Otherwise tough luck. > I'm going to be adding support for ggiSetGamma() in the emulation > targets (trueemu, palemu and monotext), How do you use it there ? CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 20 07:52:12 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA16974; Sat, 20 Jun 1998 07:52:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA20679; Sat, 20 Jun 1998 07:56:08 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 07:56:08 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: New LIBGGI demo, iXalance To: ggi-develop@eskimo.com Date: Sat, 20 Jun 1998 16:51:28 +0200 (MET DST) Cc: jpaana@iki.fi In-Reply-To: from "Jarno Paananen" at Jun 20, 98 01:13:09 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"abYiY1.0.w25.3syYr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2923 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I've just completed porting the pretty well-known demo loader system > iXalance (see http://www.tbl.org/win32.htm) to Linux with LIBGGI. GREAT ! Thanks a lot for this contribution ... Pity I don't have glibc2 ... > It draws directly to a memory display and uses ggiCrossBlit to draw > it on the screen so it doesn't use that much of the LIBGGI's > potential. Yeah. I'll gladly give advice, if you are planning to port it to using DirectBuffer or something. You might want to tell the people at tbl.org, that you can now run iXalance demos on Linux, so they can update that "Win sucks, Linux rules" section. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 20 08:41:31 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA17018; Sat, 20 Jun 1998 08:41:30 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA09292; Sat, 20 Jun 1998 08:41:31 -0700 Resent-Date: Sat, 20 Jun 1998 08:41:31 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Where are the diffs ? To: ggi-develop@eskimo.com (mailing list GGI) Date: Sat, 20 Jun 1998 17:40:01 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"KrWka3.0.dG2.gWzYr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2924 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hey folks ! I thought I had made clear what those two trees are for. One for playing around and one for a stable checkout. As of now the stable tree is useless ... Are all your changes that instable ? If all go back to "yeah - we'll hack around, leave that users that want something to work with alone", I'll either : - take down the devel repository, so you _have_ to work by sending patches - or mirror the stable repository to the devel one every sunday to incite some will to get your changes in the stable tree. I will _NOT_ wander around myselves and try to snatch the pieces from the devel repository. This isn't doable for someone who has not actually written the code. So some on - diff your changes against the stable repository and send me commented patches to incorporate them. BTW: I have re-imported the svgalib wrapper, checked it and moved it into the stable tree. CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 20 14:57:45 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA17376; Sat, 20 Jun 1998 14:57:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA25816; Sat, 20 Jun 1998 14:54:15 -0700 Resent-Date: Sat, 20 Jun 1998 14:54:15 -0700 Date: Sat, 20 Jun 1998 14:54:08 -0400 (EDT) From: Steve Cheng Sender: steve@maxt1m33.ipoline.com To: andreas.beck@ggi-project.org cc: GGI Mailing List Subject: Re: Where are the diffs ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"4xCCB3.0.CJ6.6-2Zr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2926 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 20 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Hey folks ! > > I thought I had made clear what those two trees are for. One for playing > around and one for a stable checkout. As of now the stable tree is useless ... Yes. > Are all your changes that instable ? Probably the only software that has no bugs is TeX. We have broken compiles in the past by things that we thought wouldn't change anything. It is not easy to test whether changes are stable or not without more people trying it, and be SURE of that. Therefore no one diffs changes into stable. Plus, doing diffs by hand rather than CVS is not pleasant. That is the whole point of CVS -- make it easier to commit changes. No one wants to do double work -- at least for me (e.g. the patches I sent you, I don't actually do them in stable because it's cumbersome). I don't know if that is true for others, or may be I don't know of a better way to do patches. Then there are patches that depend on other changes added to devel only, by other people. > If all go back to "yeah - we'll hack around, leave that users that want > something to work with alone", I'll either : > > - take down the devel repository, so you _have_ to work by sending patches > - or mirror the stable repository to the devel one every sunday > > to incite some will to get your changes in the stable tree. Maybe you should simply "age" devel into stable, but closing down devel is unacceptable. I'm beginning to question whether the benefits of a stable tree to "our customers" is worth the extra work. > I will _NOT_ wander around myselves and try to snatch the pieces from the > devel repository. This isn't doable for someone who has not actually written > the code. Sorry, but I never knew that we must do this. But alright, I'll do that now... -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Sat Jun 20 15:03:19 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA17387; Sat, 20 Jun 1998 15:03:17 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA31442; Sat, 20 Jun 1998 15:05:30 -0700 Resent-Date: Sat, 20 Jun 1998 15:05:30 -0700 Message-Id: X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: ggi-develop@eskimo.com Subject: Re: New LIBGGI demo, iXalance In-Reply-To: Your message of "Sat, 20 Jun 1998 12:41:08 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Jun 1998 22:19:16 +0300 From: Jarno Paananen Resent-Message-ID: <"Bpnhp1.0.0h7.e83Zr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2928 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Hi :) Hi! > Jarno Paananen as in, the person who wrote ThePlayer (wow, that sends me > back to the Amiga times.. what was your group.. *thinks* Sahara Surfers, > right? Hmm, s2.org, I guess I am :) and MIDAS ? Welcome aboard ! Nice that someone still remembers me :-) I'll add PS3M to the list and it's quite complete. I've lurked here for a while, but haven't had too much free time to do anything... > > I've just completed porting the pretty well-known demo loader system > > iXalance (see http://www.tbl.org/win32.htm) to Linux with LIBGGI. > > GREAT! We owe you a beer (or two..). I haven't followed the PC scene > much ever, so that'll probably be stupid questions : Heh, thanks :) > 1) how many iXalance-compliant demos are there at the moment, and is that > becoming a sort of standard? Getting them ALL to run under libggi sounds > sweet.. :) At the moment there are only those 3 from TBL. They are pretty hard to do without knowledge of the iXalance loader and I kind of hope they won't become a standard because it's so much of a rude hack :-) As a proof of concept it's great as these demos were first purely for dos (understandable for Stash for example, phew how much stuff in 64k...) then converted for Win32 and now runnable in the exactly same form on Linux. > 2) your loader will read, fixup and run iXalance-compliant demos assembled > for win32 just fine, or do they have to be reassembled for linux/ELF > first? (or rather, did you use your own executable format :) They are actually a custom package of compressed DOS32-images, pictures and modules. DOS32 is a dos-extender whose object format is pretty simple and straight-forward to relocate and stuff. > GGI, besides allowing non-setuid graphics, really aims at games and > demos. Right now we miss a couple of things that aren't present > in win32 either but that we'd like to have, such as proper vsync.. > Linux is a PITA with that, if you want to help Brian S. Julin (who's > working on that at the moment), that'd be great.. And all tricks > that were possible under DOS, aren't under windoze anymore, and > speed non-hw-accelerated systems by a large factor when programmed > properly .. I'll see what I can do, but for constant use I'd need a KGI that allows me still to use XFree and SVGAlib (not so necessary though...) I think this is the case for some other developers too. Developing KGI shouldn't make it too complicated to use the normal software you use evedy day. Just my 0.2 cents... > Btw the URL above didn't work, but I could find it easily at : > http://www.tbl.org/tbl32.htm > > (saying that for other people that want to download your demos) Oops, fortunately the README had the correct one. > Ok, I'm going to kill my poor home ISDN line downloading all TBL demos and > trying iXalance under GGI.. :) And the second one: > I just tested it (see previous message :), it works for me. I > guess the question about 'own executable format' is answered :) Yes, it's a custom format which is exactly the same under Win32 and Linux. > *gawps at Astral Blur* Heh, it's pretty amazing, especially for the first time. > You should add an option in iXelata/libggi for it to use DirectBuffer > instead of a memory visual and crossblit - half of the KGI drivers > don't implement blit acceleration, so when ones displays through > the KGI target it might be a good idea (just do it as an option > to the end-user).. What do you think? I could do this. The only problems I see are that the demo code which wants a linear 16-bit color buffer can't be altered anymore. And it wants exactly the resolutions it requests. The other one is that the demos do pretty much reading from the buffer too (alpha blending and such) and it's really slow from the actual video memory. Btw. where does the X-target keep it's DirectBuffer? If that could be for example the MITSHM-memory, at least one copy could be avoided I think. > Thanks a million times for your work.. You have no idea how > happy I am to finally run demos under GGI. You're welcome :-) It took me almost one night to get it finally to work, but you know these nightless nights here in Finland at this time of the year ;) Regards, Jarno -- Jarno Mikael Paananen - Panama, kelionnen raja - jpaana@iki.fi From ggi-develop-request@eskimo.com Sat Jun 20 15:05:12 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA17393; Sat, 20 Jun 1998 15:05:11 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA31417; Sat, 20 Jun 1998 15:05:28 -0700 Resent-Date: Sat, 20 Jun 1998 15:05:28 -0700 Message-Id: X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: ggi-develop@eskimo.com Subject: Re: New LIBGGI demo, iXalance In-Reply-To: Your message of "Sat, 20 Jun 1998 16:51:28 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Jun 1998 22:24:36 +0300 From: Jarno Paananen Resent-Message-ID: <"UF-j73.0.eg7.c83Zr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2927 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Hi ! Hi there too, > > I've just completed porting the pretty well-known demo loader system > > iXalance (see http://www.tbl.org/win32.htm) to Linux with LIBGGI. > > GREAT ! Thanks a lot for this contribution ... > Pity I don't have glibc2 ... And I can't compile libc5-binaries that easily :( > > It draws directly to a memory display and uses ggiCrossBlit to draw > > it on the screen so it doesn't use that much of the LIBGGI's > > potential. > > Yeah. I'll gladly give advice, if you are planning to port it to using > DirectBuffer or something. As I said in the previous post, the main problem is that the actual demo code can't be changed anymore, so the resolutions it wants have to be available and that it makes lots of reads from the frame buffer. As you know this is really slow from the actual video memory compared to a main memory buffer. > You might want to tell the people at tbl.org, that you can now run iXalance > demos on Linux, so they can update that "Win sucks, Linux rules" section. I've been in close contact with Jurjen Katsman / Nix/TBL who created iXalance in the first place (got the sources and stuff), but as it's Midsummer, he hasn't had the time to update those yet ;-) Regards, Jarno -- Jarno Mikael Paananen - Panama, kelionnen raja - jpaana@iki.fi From ggi-develop-request@eskimo.com Sat Jun 20 15:11:01 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA17404; Sat, 20 Jun 1998 15:11:00 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA00575; Sat, 20 Jun 1998 14:13:34 -0700 Resent-Date: Sat, 20 Jun 1998 14:13:34 -0700 Message-ID: <19980620160833.63177@3e8.com> Date: Sat, 20 Jun 1998 16:08:33 -0500 From: Jim Ursetto To: ggi-develop@eskimo.com Subject: Degas, 1st try Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i X-System: Linux alice 2.1.105 X-Deities: e38 Resent-Message-ID: <"afMbi1.0.s8.zN2Zr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2925 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com It's good to be back :) Here are some results from my first try at running an EvStack (yes, yes, GGI Console)-enabled kernel with Degas, from CVS devel as of this morning. 1. As many have pointed out, the toplevel makefile is fragged. Even after changing patches/Linux to os/Linux, 'make patch_kernel' doesn't work because the makefile doesn't have a 'patch' rule. I wound up patching by hand using dopatch. By the way, unpatch hasn't been updated for Degas. 2. On to compiling the kernel. Under vanilla 2.1.105, make menuconfig causes gawk to segfault, so I used make xconfig instead. But there were errors using this after patching: drivers/console/Config.in: CONFIG_GGI_XTERM="m" needs to be changed to define_bool CONFIG_GGI_XTERM m (line 26) drivers/console/Config.in: ARCH is undeclared (line 60). This prevents from being able to select some critical options in the GGI Config menu. I commented out the condition so I could compile. linux/arch/i386/config.in: Around line 146, a condition was added to make sure GGI is not enabled before enabling MAGIC_SYSRQ. For some reason (I think a bug) the kernel tkparse script generates faulty code for this. That is, in kconfig.tk, update_mainmenu does not declare CONFIG_GGI as global, and the make crashes. Removing the condition "fixes" this, as does taking out the body of the condition. (??!) I couldn't figure out a good solution for the last two beyond an ugly hack. 3. OK, it compiled! And booted. And didn't crash! But, even though I compiled conlinux support into the kernel, - stm fails to set the video mode once every two times; - stm always fails to resize the console (it says VT_RESIZEX: success, but then ERROR: VT_RESIZE returned 0) - setfont always fails with "PIO_FONT ioctl error: Invalid argument" - loadkeys spews out hundreds of "KDSKBENT: Invalid argument" errors - X comes up fine, but the keyboard doesn't work I was under the impression that conlinux support worked for other people. Of course, something could have been misconfigured. Any ideas? Meanwhile, I'm going to play with the broken VGA driver. Jim -- 333 88 By thy purple gently glowing, e38, e38. eee 3 8 8 Time itself seems to be slowing (e38, e38) e e 3 8 8 Heal the wounds of time and space eeeeee 33 88 Multiverse a better place e 3 8 8 Thou omnipotent, all-knowing e38, e38... e 3 8 8 But I see you must be going, e38. eee 333 88 Society of e friends-of-e@xorinia.dim.gov From ggi-develop-request@eskimo.com Sat Jun 20 16:09:26 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA17459; Sat, 20 Jun 1998 16:09:24 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA00899; Sat, 20 Jun 1998 16:07:26 -0700 Resent-Date: Sat, 20 Jun 1998 16:07:26 -0700 Sender: raka@student.uq.edu.au Message-ID: <358BADEE.D06E4CDA@student.uq.edu.au> Date: Sat, 20 Jun 1998 12:41:18 +0000 From: Adrian Ratnapala X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Dali segfault References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ATryC3.0.wD.j24Zr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2929 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jesse Barnes wrote: > I recently downloaded ggi-dali-final.tar.gz and all compiled correctly. > However, when I try to run any of the demos, they segfault when they try > to set the mode. I debugged the stars demo and the segfault happened > during the call to ggiSetGraphMode(vis, GGI_AUTO, GGI_AUTO...). gdb > reported the following: > Program received signal SIGSEGV, Segmentation fault. > 0x40783a82 in GGIdlinit (visual=0x6e696c64, > version=0x47007469
) at visual.c:43 > 43 visual->opcolor->mapcolor=GGImapcolor; I think I got this problem too. I didn't look at it too deeply, but putting LIBGGI_DEBUG=255,gave me the distinct impression that something was trying to use values of -1 instead of thinking "-1 == GGI_AUTO therefore I must figure out a value for myself". I am not sure this is right though, since I didn't look into it. Everything works if you explicitly give it values, instead of useing GGI_AUTO. From ggi-develop-request@eskimo.com Sat Jun 20 17:56:40 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA17630; Sat, 20 Jun 1998 17:56:37 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id RAA18687; Sat, 20 Jun 1998 17:56:10 -0700 Resent-Date: Sat, 20 Jun 1998 17:56:10 -0700 Message-ID: <19980620195249.35415@3e8.com> Date: Sat, 20 Jun 1998 19:52:49 -0500 From: Jim Ursetto To: ggi-develop@eskimo.com Subject: vga driver divide bug fixed Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i X-System: Linux alice 2.1.105 X-Deities: e38 Resent-Message-ID: <"CMTo03.0.tZ4.fe5Zr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2930 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com It's the little things that take hours to debug. Now that this is fixed, I'm getting a "kgi_scroll_setmode: No default mode for display 0" error, at which time the display freezes and I have to reboot with C-A-D. Gotta go eat. I'm gonna get this damn thing running sooner or later... --- driver/clock/fixed/fixed.inc.orig Sat Jun 20 19:45:31 1998 +++ driver/clock/fixed/fixed.inc Sat Jun 20 19:45:52 1998 @@ -89,7 +89,7 @@ enum kgi_tm_cmd *cmd) { ggi_sint i; - ggi_sint newfreq = (cmd == CMD_PROPOSE) + ggi_sint newfreq = (*cmd == CMD_PROPOSE) ? 0x7FFFFFFF : mode->tm.dclk * mode->tm.clk.mul / mode->tm.clk.div; ggi_sint best = 0; -- Jim Ursetto | Though dreams can be deceiving/Like faces are to hearts ursetto@uiuc.edu | They serve for sweet relieving/When fantasy and reality e38 | Lie too far -------------------> apart From ggi-develop-request@eskimo.com Sat Jun 20 18:19:18 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA17662; Sat, 20 Jun 1998 18:19:16 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA13499; Sat, 20 Jun 1998 18:22:08 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 18:22:08 -0700 (PDT) Date: Sat, 20 Jun 1998 18:18:36 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: VGA driver maintainer Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"0gTlA3.0.pI3.z06Zr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2931 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I just noticed that I am still listed as the VGA driver maintainer. As I have not worked on the VGA driver in quite some time and do not plan to do so in the future, I would like to take the long-overdue step of formally stepping down. Who wants to take my place? Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 20 23:19:09 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA17943; Sat, 20 Jun 1998 23:19:08 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id XAA06397; Sat, 20 Jun 1998 23:24:14 -0700 (PDT) Resent-Date: Sat, 20 Jun 1998 23:24:14 -0700 (PDT) Message-ID: <19980621011839.10828@3e8.com> Date: Sun, 21 Jun 1998 01:18:39 -0500 From: Jim Ursetto To: ggi-develop@eskimo.com Subject: degas vga driver now working! Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Qxx1br4bt0+wmkIi X-Mailer: Mutt 0.89i X-System: Linux alice 2.1.105 X-Deities: e38 Resent-Message-ID: <"-C4-a2.0.jZ1.BSAZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2932 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii After making the previous cmd -> *cmd change, the VGA driver still crashed upon insertion. It seems that the dpp change was incomplete (so painfully obvious now), so I finished it. The VGA driver now inserts and has working textmode. Verify and commit if you feel like it, otherwise wait until I get CVS access again. I'll be testing graphics as soon as I get up the nerve. I found a weirdness while tracing through the mode negotiation code, though. The driver starts out by asking for 720x400 (9-pixel wide) text mode; after about 8,000 check_modes it has changed this to 640x350 (EGA) text mode. Very strange. Oh well, it's not my fault ;) The only VT affected is the one on which you type insmod ggidrv.o. A side effect of this (?) is that 9x16 text mode is restored upon driver removal, but the font stays 8x14. I can live with that... rebooting is much more annoying. -- Jim Ursetto | "My goal in life is to become yogurt." ursetto@uiuc.edu | -- a cat-tree human from mars --------------------------------------------------------------> --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vga.uue" begin 644 vga.patch M+2TM('9G82YC+F]R:6<)4W5N($IU;B`R,2`P,#HU-CHP.2`Q.3DX"BLK*R!V M9V$N8PE3=6X@2G5N(#(Q(#`P.C4X.C`V(#$Y.3@*0$`@+30W-BPX("LT-S8L M."!`0`H@"B`)+RH@4V5T(&%L;"!T:&4@;6]D92!I;F9O('1H870@=V4G=F4@ M:G5S="!G871H97)E9"`J+PH@"61E9F%U;'1?9V=I7VUO9&4N9G)A;65S"0D] M(#$["BT)9&5F875L=%]G9VE?;6]D92YV:7-I8FQE+G@)/2!T>"YW:61T:#L* M+0ED969A=6QT7V=G:5]M;V1E+G9I0D]('1Y+G=I9'1H.PHK"61E M9F%U;'1?9V=I7VUO9&4N=FES:6)L92YX"3T@='@N=VED=&@O9'!P>#L**PED M969A=6QT7V=G:5]M;V1E+G9I0D]('1Y+G=I9'1H+V1P<'D["B`) M9&5F875L=%]G9VE?;6]D92YV:7)T+G@)"3T@='@N=VED=&@O9'!P>#L*(`ED M969A=6QT7V=G:5]M;V1E+G9I0D)/2!T>2YW:61T:"]D<'!Y.PH@"61E M9F%U;'1?9V=I7VUO9&4N2D@*B`R M*2`J(&1P<'@["BL)"0D)6%9)4E1504P@/2!F8E]T97AT7VQE;B`O("A95DE2 M5%5!3"`J(#(I.PH@"0D)"B`)"0EI9B`H659)4E1504P@/3T@,"D*+0D)"0E9 M5DE25%5!3"`](&9B7W1E>'1?;&5N("\@*"A85DE25%5!3"`O(&1P<'@I("H@ M,BD@*B!D<'!Y.PHK"0D)"5E625)454%,(#T@9F)?=&5X=%]L96X@+R`H6%9) M4E1504P@*B`R*3L*(`HM"0D):68@*"@R("H@*%A625)454%,("\@9'!P>"D* M+0D)"2`@("`@*B`H659)4E1504P@+R!D<'!Y*2D@/B!F8E]T97AT7VQE;BD@ M>PHK"0D):68@*"@R("H@6%9)4E1504P**PD)"2`@("`@*B!95DE25%5!3"D@ M/B!F8E]T97AT7VQE;BD@>PH@"0D)"4Y/5$E#12@B3F]T(&5N;W5G:"!T97AT M(&UE;6]R>2(I.PH@"0D)"7)E='5R;B`M14Y/345-.PH@"0D)?0I`0"`M-S,V M+#@@*S"`A/2`Q M*2!\?"`H;6]D92T^=&TN;6%G;FEF>2YY("$](#$I"B`)"0D@("`@?'P@*&1P M<'@@/"`X*2!\?"`H.2`\(&1P<'@I('Q\("AD<'!Y(#P@,2D*(`D)"2`@("!\ M?"`H9'!P>2`^(#,R*2!\?"`*+0D)"2`@("`H*#(@*B`H6%9)4E1504P@+R!D M<'!X*2`J(`HM"0D)("`@("`@*%E625)454%,("\@9'!P>2DI(#X@9F)?=&5X M=%]L96XI"BL)"0D@("`@*"@R("H@6%9)4E1504P@*B`**PD)"2`@("`@(%E6 M25)454%,*2`^(&9B7W1E>'1?;&5N*0H@"0D)("`@('Q\("AM;V1E+3YT;2YD M8VQK(#X@8VAI<&EN9F\N9&-L:RYM87@I"B`)"0D@("`@?'P@*&UO9&4M/G1M B+F1C;&L@/"!C:&EP:6YF;RYD8VQK+FUI;BDI"B`)"0E["GP@ ` end --Qxx1br4bt0+wmkIi-- From ggi-develop-request@eskimo.com Sun Jun 21 00:32:31 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA18057; Sun, 21 Jun 1998 00:32:27 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA14335; Sun, 21 Jun 1998 00:36:36 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 00:36:36 -0700 (PDT) From: Andrew Apted Message-ID: <19980621141940.57336@ajax.netspace.net.au> Date: Sun, 21 Jun 1998 14:19:40 +1000 To: ggi-develop@eskimo.com Subject: Re: Move gamma functions to misc ? Reply-To: ggi-develop@eskimo.com References: <19980620123614.13004@ajax.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from becka@rz.uni-duesseldorf.de on Sat, Jun 20, 1998 at 02:35:30PM +0200 Resent-Message-ID: <"7cvqM3.0.qV3.2WBZr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2933 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andy writes: > Yes - this is how I meant it. If you set gamma at the very start, all > is well. Otherwise tough luck. For hicolor/truecolor modes, I think it should fail rather than just change the ggiMapColor() & ggiUnmapPixel() results. EG. games might want to use it for a special effect (flash the whole screen). > > I'm going to be adding support for ggiSetGamma() in the emulation > > targets (trueemu, palemu and monotext), > > How do you use it there ? The emulation targets have a framebuffer in memory, so when the gamma changes they can update the lookup tables, mark the whole screen as being modified, and on the next ggiFlush() the screen gets updated. It won't work when those targets are in "straight-through" mode though (something else I'm planning to add...). Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Sun Jun 21 00:33:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA18062; Sun, 21 Jun 1998 00:33:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA14391; Sun, 21 Jun 1998 00:36:49 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 00:36:49 -0700 (PDT) From: Andrew Apted Message-ID: <19980621155949.32460@ajax.netspace.net.au> Date: Sun, 21 Jun 1998 15:59:49 +1000 To: ggi-develop@eskimo.com Subject: Re: Move gamma functions to misc ? Reply-To: ggi-develop@eskimo.com References: <19980620123614.13004@ajax.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <19980620123614.13004@ajax.netspace.net.au>; from Andrew Apted on Sat, Jun 20, 1998 at 12:36:14PM +1000 Resent-Message-ID: <"_BRqj.0.fW3.FWBZr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2934 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Yours truly writes: > What is ggiSetGammaMap() supposed to do anyway ? I used the source, Luke, and took a peek at libggi/default/gamma/gamma.c. It seems ggiSetGammaMap() is for those hicolor/truecolor modes where R, G, and B get passed through a lookup table. [Thus 'gamma' is a bit misleading]. I'd like to propose that we use ggiSetPaletteVec() for this feature, and simply drop ggiSetGammaMap(). Agreed ? Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Sun Jun 21 00:37:49 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA18085; Sun, 21 Jun 1998 00:37:43 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA15231; Sun, 21 Jun 1998 00:41:44 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 00:41:44 -0700 (PDT) From: Andrew Apted Message-ID: <19980621152853.30596@ajax.netspace.net.au> Date: Sun, 21 Jun 1998 15:28:53 +1000 To: ggi-develop@eskimo.com Subject: Re: Where are the diffs ? Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from becka@rz.uni-duesseldorf.de on Sat, Jun 20, 1998 at 05:40:01PM +0200 Resent-Message-ID: <"X8MXM.0.rj3.raBZr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2935 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andy writes: > Hey folks ! > > I thought I had made clear what those two trees are for. One for > playing around and one for a stable checkout. As of now the stable > tree is useless ... No, it hasn't been clear how this arrangement is supposed to work. If everytime we commit something to ggidevel we're supposed to make a patch and post it, then IMO there's not much point in having the devel repository. Right now I think that having just one repository (the stable one) would be best. We mere mortals can make changes locally, use 'cvs diff', and then post off the results for inclusion by the "Gods of Stability" :-). Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Sun Jun 21 01:43:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA18291; Sun, 21 Jun 1998 01:43:50 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA22151; Sun, 21 Jun 1998 01:47:46 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 01:47:46 -0700 (PDT) Message-Id: <199806210845.KAA16857@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: Where are the diffs ? In-reply-to: Your message of "Sun, 21 Jun 1998 15:28:53 +1000." <19980621152853.30596@ajax.netspace.net.au> Date: Sun, 21 Jun 1998 10:45:29 +0200 From: Marcus Sundberg Resent-Message-ID: <"4l0nD2.0._P5.mYCZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2936 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > If everytime we commit something to ggidevel we're supposed to make a > patch and post it, then IMO there's not much point in having the devel > repository. > > Right now I think that having just one repository (the stable one) would > be best. We mere mortals can make changes locally, use 'cvs diff', and > then post off the results for inclusion by the "Gods of Stability" :-) I suggest that we keep the devel repostitory, but only use it for large changes that more than one person works on, simply as a means of easily sharing code among developers. //Marcus From ggi-develop-request@eskimo.com Sun Jun 21 02:49:00 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA18462; Sun, 21 Jun 1998 02:48:57 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA27497; Sun, 21 Jun 1998 02:51:21 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 02:51:21 -0700 (PDT) Date: Sun, 21 Jun 1998 11:48:59 +0200 (MET DST) From: Rodolphe Ortalo X-Sender: ortalo@schubert To: ggi-develop@eskimo.com Subject: Re: Where are the diffs ? In-Reply-To: <199806210845.KAA16857@zafir.e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Z9JVJ1.0.Wj6.LUDZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2937 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > If everytime we commit something to ggidevel we're supposed to make a > > patch and post it, then IMO there's not much point in having the devel > > repository. Personnally, I don't see any problem with the two repositories. The devel plays the role of the previous dali repository, i.e.: we put our personal work into it when we have made some advances, or when we have to share something with another developer, or when we just want to save the current state. That means we are relatively free to use the repository without worrying too much about long-term stability and "perfect" code. Hence we can propose things, and share experimental things. The stable is here to contain the things that we see complete and relatively well tested. In order to protect this repository, there is some kind of formal submission/control procedure to commit to it (ie: we submit a patch to the main developpers who are the most competent to review it.) So, why do you see something annoying with this organization ? Personnally, I'm very happy to have the devel rep. which is very convenient for development; and very happy to have the stable repository that is reviewed before anything I submit to it is actually commited (but, I'm of the very-careful kind :-). Rodolphe From ggi-develop-request@eskimo.com Sun Jun 21 04:40:05 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA18540; Sun, 21 Jun 1998 04:40:01 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA07084; Sun, 21 Jun 1998 04:44:38 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 04:44:38 -0700 (PDT) Sender: mee@daimi.aau.dk Message-ID: <358CF19D.38D7B1B9@daimi.aau.dk> Date: Sun, 21 Jun 1998 13:42:21 +0200 From: Martin Eli Erhardsen X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX64 6.4 IP30) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: degas vga driver now working! References: <19980621011839.10828@3e8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7LydI1.0.Zk1.a8FZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2938 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jim Ursetto wrote: > > After making the previous cmd -> *cmd change, the VGA driver still crashed > upon insertion. It seems that the dpp change was incomplete (so painfully > obvious now), so I finished it. The VGA driver now inserts and has working > textmode. Verify and commit if you feel like it, otherwise wait until I get > CVS access again. I'll be testing graphics as soon as I get up the nerve. > It looks okay, so I have commited it I'll have a look at the graphics mode negotiation code, if the driver works. It shouldn't be too difficult to implement full specification. From ggi-develop-request@eskimo.com Sun Jun 21 05:08:28 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA18574; Sun, 21 Jun 1998 05:08:26 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA25078; Sun, 21 Jun 1998 05:04:39 -0700 Resent-Date: Sun, 21 Jun 1998 05:04:39 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Dali segfault To: ggi-develop@eskimo.com Date: Sun, 21 Jun 1998 14:02:54 +0200 (MET DST) In-Reply-To: <358BADEE.D06E4CDA@student.uq.edu.au> from "Adrian Ratnapala" at Jun 20, 98 12:41:18 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"3RzgL3.0.S76.ERFZr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2940 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > I recently downloaded ggi-dali-final.tar.gz and all compiled correctly. > > However, when I try to run any of the demos, they segfault when they try > > to set the mode. I debugged the stars demo and the segfault happened > > during the call to ggiSetGraphMode(vis, GGI_AUTO, GGI_AUTO...). gdb > > reported the following: > > Program received signal SIGSEGV, Segmentation fault. > > 0x40783a82 in GGIdlinit (visual=0x6e696c64, > > version=0x47007469
) at visual.c:43 > > 43 visual->opcolor->mapcolor=GGImapcolor; > > I think I got this problem too. I didn't look at it too deeply, but putting > LIBGGI_DEBUG=255,gave me the distinct impression that something was trying to > use values of -1 instead > of thinking "-1 == GGI_AUTO therefore I must figure out a value for myself". > I am not sure this is right though, since I didn't look into it. > > Everything works if you explicitly give it values, instead of useing > GGI_AUTO. This happens only on the KGI target - right ? It hasn't been updated to recognize GGI_AUTO. Someone should finally do that ... C'mon it's easy ... CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 21 05:08:53 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA18578; Sun, 21 Jun 1998 05:08:51 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA25059; Sun, 21 Jun 1998 05:04:30 -0700 Resent-Date: Sun, 21 Jun 1998 05:04:30 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Where are the diffs ? To: ggi-develop@eskimo.com Date: Sun, 21 Jun 1998 14:00:47 +0200 (MET DST) In-Reply-To: from "Steve Cheng" at Jun 20, 98 02:54:08 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"xiFYz2.0.O76.ERFZr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2939 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > I thought I had made clear what those two trees are for. One for playing > > around and one for a stable checkout. As of now the stable tree is useless ... > > Maybe you should simply "age" devel into stable, but closing down devel is > unacceptable. I'm beginning to question whether the benefits of a stable > tree to "our customers" is worth the extra work. It is crucial. We will be swept off the market within the next year, if we fail to provide stable, supported snapshots. Have a look at what mozilla folks are doing: They freeze the repository, if a build on one supported platform fails. O.K. - it seems the idea of having those two repositories and diffing in the stable things faces quite some opposition. O.K. However we desperately need a stable and a devel release. So I'd suggest we do the following: We go as Linux kernel does, developing on a devel-tree, introducing a feature freeze from time to time, calling the result a stable tree and then starting over. However we need to have a much more rapid development cycle at this stage, so what I propose is: 1. We set a release-cycle of 1 month. 2. Development goes normally from the 1st to the 24th each month. 3. Feature freeze sets in at the 25th each month. That should leave about a week to set things straight until the devel tree is moved to the stable tree at the first of each month. 4. If bugs are reported from the stable tree, _everyone_ that know what is going on should try to fix those ASAP in _both_ trees (sort of how we came to Linux 2.0.34). Would that be acceptable ? Remember: If we just "hack away" as we like to do (as we are programmers), we won't be used and thus the project will die some day. CU, ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 21 07:58:10 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA18713; Sun, 21 Jun 1998 07:58:07 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA00501; Sun, 21 Jun 1998 08:02:12 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 08:02:12 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: O.K. - backported LibGGImisc to devel rep ... ARGH ! To: ggi-develop@eskimo.com (mailing list GGI) Date: Sun, 21 Jun 1998 16:58:18 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Qpgyb1.0.i7.o1IZr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2941 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi folks ! I have backported the more important libggimisc things to the devel repository. And this was no fun. We will change back to the single-repository approach ASAP. If the repositories aren't kept in some reasonable sync. patching is impossible. The diff was 0.5MB ... Steve: You sent me patches for the non-X targets for getAPI. could you re-send or commit them to devel ? Thanks. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 21 09:07:44 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA18756; Sun, 21 Jun 1998 09:07:42 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA05836; Sun, 21 Jun 1998 09:01:39 -0700 Resent-Date: Sun, 21 Jun 1998 09:01:39 -0700 Message-Id: <199806211601.SAA15905@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: O.K. - backported LibGGImisc to devel rep ... ARGH ! In-reply-to: Your message of "Sun, 21 Jun 1998 16:58:18 +0200." Date: Sun, 21 Jun 1998 18:01:35 +0200 From: Marcus Sundberg Resent-Message-ID: <"gZxPs.0.-Q1.ZvIZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2942 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > This happens only on the KGI target - right ? It hasn't been updated to > recognize GGI_AUTO. Someone should finally do that ... C'mon it's easy ... That will require the KGI drivers to export information about what modes it can handle. Do we currently have an interface for this? //Marcus From ggi-develop-request@eskimo.com Sun Jun 21 10:30:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA18781; Sun, 21 Jun 1998 10:30:12 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA25553; Sun, 21 Jun 1998 10:33:14 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 10:33:14 -0700 (PDT) Date: Sun, 21 Jun 1998 13:30:15 -0400 (EDT) From: Steve Cheng Sender: steve@maxt2m26.ipoline.com To: GGI Mailing List Subject: Re: O.K. - backported LibGGImisc to devel rep ... ARGH ! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ZXL372.0.5F6.JFKZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2943 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 21 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Steve: You sent me patches for the non-X targets for getAPI. could you re-send > or commit them to devel ? Thanks. Committed them to devel. [and fixed conflicts with LIBGGI_*] However the current devel tree did not compile out-of-the-box. Mostly errors with extensions/misc/display/svgalib/, which appears to be copied out verbatim from an earlier version of the actual target. I hacked it so it will compile, but I'm not sure if I did it correctly, so I'll just outline the problems for someone more qualified to fix: * Makefile: $TOPLEVEL -> $LIBGGI_TOPLEVEL * Makefile: cut out "color.c events.c" ,etc. from compilation since they don't exist * VIS_MODE,etc. -> LIBGGI_MODE everywhere * GGIRP_DONTCARE and GGIRP_SYNC not defined! * ggi_event_buffer -> EvQueue which has been fixed in display/svgalib since Degas was out If this has been already been fixed than please ignore. Thanks. -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Sun Jun 21 11:31:17 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA18812; Sun, 21 Jun 1998 11:31:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA18112; Sun, 21 Jun 1998 11:29:34 -0700 Resent-Date: Sun, 21 Jun 1998 11:29:34 -0700 Sender: mee@daimi.aau.dk Message-ID: <358D510C.332EEDF5@daimi.aau.dk> Date: Sun, 21 Jun 1998 20:29:32 +0200 From: Martin Eli Erhardsen X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: How to set graphics modes in degas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"whGCS1.0.pQ4.D4LZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2944 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Now that the degas VGA driver can be inserted, I have tried to set the graphics modes, but I can't open /dev/graphic or /dev/display/node0/graph I have tried opening /dev/display/node0/vty2, and writing some text to it, so I know that it works. Does anyone know what the problem is ? From ggi-develop-request@eskimo.com Sun Jun 21 12:11:59 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA18840; Sun, 21 Jun 1998 12:11:57 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA14402; Sun, 21 Jun 1998 12:14:32 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 12:14:32 -0700 (PDT) Message-ID: <19980621140845.52838@fries.net> Date: Sun, 21 Jun 1998 14:08:45 -0500 From: "Todd T. Fries" To: andreas.beck@ggi-project.org Cc: ggi-develop@eskimo.com Subject: Re: Degas stuff References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from becka@rz.uni-duesseldorf.de on Sat, Jun 20, 1998 at 02:33:26PM +0200 Resent-Message-ID: <"pt-0Y3.0.tW3.JkLZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2945 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, Jun 20, 1998 at 02:33:26PM +0200, becka@rz.uni-duesseldorf.de wrote: > We should never directly refer to such things. $(MAKE) is here for that. Absolutely! > > - Old one #2: The "graphic" KGI driver sub-module handles acceleration > > and would make more sense if called "accel" or something similar. > > Yeah. Shall I move that in the repository or shall we do the "clean" > way of cvs remove / cvs add ? Unless you have an extremely strong reason to not do so, the "clean" method is highly recommended. Modifying the repository manually only makes it so you cannot revert to an older source revision accurately at a future date. Thus it is best to just never plan on modifying the repository directly, to avoid such problems. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Sun Jun 21 12:21:06 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA18845; Sun, 21 Jun 1998 12:21:05 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA16594; Sun, 21 Jun 1998 12:25:21 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 12:25:21 -0700 (PDT) Message-ID: <19980621141943.13133@fries.net> Date: Sun, 21 Jun 1998 14:19:43 -0500 From: "Todd T. Fries" To: andreas.beck@ggi-project.org Cc: mailing list GGI Subject: Re: Where are the diffs ? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from becka@rz.uni-duesseldorf.de on Sat, Jun 20, 1998 at 05:40:01PM +0200 Resent-Message-ID: <"8aPRU1.0.434.TuLZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2946 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, Jun 20, 1998 at 05:40:01PM +0200, becka@rz.uni-duesseldorf.de wrote: > Hey folks ! > > I thought I had made clear what those two trees are for. One for playing > around and one for a stable checkout. As of now the stable tree is useless ... > > Are all your changes that instable ? > > If all go back to "yeah - we'll hack around, leave that users that want > something to work with alone", I'll either : > > - take down the devel repository, so you _have_ to work by sending patches > - or mirror the stable repository to the devel one every sunday > > to incite some will to get your changes in the stable tree. > > I will _NOT_ wander around myselves and try to snatch the pieces from the > devel repository. This isn't doable for someone who has not actually written > the code. Imagine that. This is exactly what I predicted when I heard there would be two repositories. It is not doable to have people 'developing' against the devel repository and have someone approve stuff to go into the stable repsitory .. unless of course you expected the people doing the development to follow through with a commit to the devel repository and petition to get their code in the stable repository which it sounds like you were expecting but you never stated formally that you wanted this. So, now, it sounds like we ALL have to endure the headache of developing in one tree, and keeping track of the commits we make to make sure they get into the stable repository. *sigh* -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Sun Jun 21 12:43:04 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA18867; Sun, 21 Jun 1998 12:43:01 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA17772; Sun, 21 Jun 1998 12:29:49 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 12:29:49 -0700 (PDT) Message-ID: <19980621142418.07694@fries.net> Date: Sun, 21 Jun 1998 14:24:18 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: Where are the diffs ? References: <199806210845.KAA16857@zafir.e.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from Rodolphe Ortalo on Sun, Jun 21, 1998 at 11:48:59AM +0200 Resent-Message-ID: <"FH-1K1.0.ZL4.fyLZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2947 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, Jun 21, 1998 at 11:48:59AM +0200, Rodolphe Ortalo wrote: [..] > So, why do you see something annoying with this organization ? > Personnally, I'm very happy to have the devel rep. which is very > convenient for development; and very happy to have the stable repository > that is reviewed before anything I submit to it is actually commited (but, > I'm of the very-careful kind :-). I'm sure no one here is arguing with the ideals of why one needs to have a 'play-place' to test changes with other people, and why it is crutial to have a 'stable release' with quality assurance. However, there is no clean easy way to get from one to the other and thus people are not happy with the legwork required to make this happen in real life. I'm sure somehow somewhere there is an easy solution. But maybe not. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Sun Jun 21 13:47:24 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA18910; Sun, 21 Jun 1998 13:47:21 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA04994; Sun, 21 Jun 1998 13:51:45 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 13:51:45 -0700 (PDT) Date: Fri, 19 Jun 1998 01:53:38 +0200 (MEST) From: Matthias Grimrath To: ggi-develop@eskimo.com Subject: Re: KGI driver makefile system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"k9PSs2.0.uD1.W9NZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2948 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 18 Jun 1998, Brian Julin wrote: > On Thu, 18 Jun 1998, Hartmut Niemann wrote: > > Sounds good. > > While you're at it, could you write the necessary documentation about how to > > use this system when writing my own driver? > > Please -- and provide a .stubs directory like there is now. OK, I'll do both. I hope I have it finished by sunday. Matthias Grimrath From ggi-develop-request@eskimo.com Sun Jun 21 14:31:25 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA18927; Sun, 21 Jun 1998 14:31:18 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA03530; Sun, 21 Jun 1998 14:27:21 -0700 Resent-Date: Sun, 21 Jun 1998 14:27:21 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: O.K. - backported LibGGImisc to devel rep ... ARGH ! To: ggi-develop@eskimo.com Date: Sun, 21 Jun 1998 20:46:27 +0200 (MET DST) In-Reply-To: <199806211601.SAA15905@zafir.e.kth.se> from "Marcus Sundberg" at Jun 21, 98 06:01:35 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"HTR7c1.0._s.tgNZr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2949 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > This happens only on the KGI target - right ? It hasn't been updated to > > recognize GGI_AUTO. Someone should finally do that ... C'mon it's easy ... > That will require the KGI drivers to export information about > what modes it can handle. Do we currently have an interface for > this? Not needed. The Thing to change are the KGI drivers to recognize the GGI_AUTO. They know. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 21 14:32:29 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA18932; Sun, 21 Jun 1998 14:32:28 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA03547; Sun, 21 Jun 1998 14:27:22 -0700 Resent-Date: Sun, 21 Jun 1998 14:27:22 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: O.K. - backported LibGGImisc to devel rep ... ARGH ! To: ggi-develop@eskimo.com Date: Sun, 21 Jun 1998 20:52:28 +0200 (MET DST) In-Reply-To: from "Steve Cheng" at Jun 21, 98 01:30:15 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"o-rMj1.0.Jt.vgNZr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2950 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Steve: You sent me patches for the non-X targets for getAPI. could you re-send > > or commit them to devel ? Thanks. > > Committed them to devel. [and fixed conflicts with LIBGGI_*] Thanks ... pity I tried the same ... but you were faster :-). > However the current devel tree did not compile out-of-the-box. I'll check into that ... CU, ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 21 18:15:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA19085; Sun, 21 Jun 1998 18:15:05 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA23504; Sun, 21 Jun 1998 18:13:03 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 18:13:03 -0700 (PDT) Date: Sun, 21 Jun 1998 17:57:32 -0700 (PDT) From: Jesse Barnes To: ggi-develop@eskimo.com Subject: Re: Dali segfault In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"IckAj1.0.5l5.S-QZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2951 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com No, this happens under all of the targets that I've tried (KGI, X, SVGAlib). Under X, a window pops up for an instant, then disappears when the segfault happens. Jesse Barnes "To err is human -- to blame it on the computer is even more so." - Anonymous On Sun, 21 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Hi ! > > > > I recently downloaded ggi-dali-final.tar.gz and all compiled correctly. > > > However, when I try to run any of the demos, they segfault when they try > > > to set the mode. I debugged the stars demo and the segfault happened > > > during the call to ggiSetGraphMode(vis, GGI_AUTO, GGI_AUTO...). gdb > > > reported the following: > > > Program received signal SIGSEGV, Segmentation fault. > > > 0x40783a82 in GGIdlinit (visual=0x6e696c64, > > > version=0x47007469
) at visual.c:43 > > > 43 visual->opcolor->mapcolor=GGImapcolor; > > > > I think I got this problem too. I didn't look at it too deeply, but putting > > LIBGGI_DEBUG=255,gave me the distinct impression that something was trying to > > use values of -1 instead > > of thinking "-1 == GGI_AUTO therefore I must figure out a value for myself". > > I am not sure this is right though, since I didn't look into it. > > > > Everything works if you explicitly give it values, instead of useing > > GGI_AUTO. > > This happens only on the KGI target - right ? It hasn't been updated to > recognize GGI_AUTO. Someone should finally do that ... C'mon it's easy ... > > CU,Andy > > -- > = Andreas Beck | Email : = > From ggi-develop-request@eskimo.com Sun Jun 21 19:08:49 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA19095; Sun, 21 Jun 1998 19:08:47 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA06056; Sun, 21 Jun 1998 19:13:55 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 19:13:55 -0700 (PDT) Date: Sun, 21 Jun 1998 19:04:49 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: LibGGI for X Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Mfuy73.0.VU1.WtRZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2952 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I'd like to compile the latest libGGI for X-Windows only. I am using Debian 2.0, with glibc 2 installed. Can I do this? Especially with all the discussion about who screwed up what? :-) If so, what are the procedures to do so? Note that I have no interest in KGI or EvStack yet. I am going to look into those a bit later on, when I'm more familiar with hosing the kernel and restoring it to normal operation under Debian... :-) I'm doing this to prepare myself for porting libGGI to Dolphin 0.4. Note that Dolphin 0.4 is VERY far off into the future, but I can at least perform a partial port for 0.3. :-) (Note also: web site for Dolphin 0.3 does not have up-to-date source code for 0.3. I will fix this whenever I get around to it. Too busy hacking away at Dolphin's kernel right now, though.) Thanks for the information. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Sun Jun 21 19:21:38 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA19100; Sun, 21 Jun 1998 19:21:36 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA07661; Sun, 21 Jun 1998 19:25:09 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 19:25:09 -0700 (PDT) Message-ID: <19980621113817.13400@3e8.com> Date: Sun, 21 Jun 1998 11:38:17 -0500 From: Jim Ursetto To: ggi-develop@eskimo.com Subject: Re: degas vga driver now working! References: <19980621011839.10828@3e8.com> <358CF19D.38D7B1B9@daimi.aau.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <358CF19D.38D7B1B9@daimi.aau.dk>; from Martin Eli Erhardsen on Sun, Jun 21, 1998 at 01:42:21PM +0200 X-System: Linux alice 2.1.105 X-Deities: e38 Resent-Message-ID: <"hg2VI3.0.bt1.-1SZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2953 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com At 01:42 PM on 1998 June 21, Martin Eli Erhardsen did write: > I'll have a look at the graphics mode negotiation code, if the driver > works. > It shouldn't be too difficult to implement full specification. OK. Any call to set a mode (other than initial insertion) isn't working right now, because kgi complains that the mode is already set. I haven't looked too deep yet but it may be that the mode isn't being released, or it's trying to acquire the wrong mode. But definitely take a look at the initial mode set. -- Jim Ursetto | Doctrines are scaffolding poles cast aside, ursetto@uiuc.edu | Some are too long, others too short, e38 | There's none that suits my purpose -------------------> Save e38. -- With apologies to Sage Ninomiya From ggi-develop-request@eskimo.com Sun Jun 21 19:29:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA19105; Sun, 21 Jun 1998 19:29:39 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA09797; Sun, 21 Jun 1998 19:34:04 -0700 (PDT) Resent-Date: Sun, 21 Jun 1998 19:34:04 -0700 (PDT) Date: Sun, 21 Jun 1998 19:31:34 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: LibGGI patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"S5LFe.0.yO2.QASZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2954 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Apply to lib/libggi/extensions/Makefile - it thinks a "misc" directory is there and it isn't which breaks toplevel "make clean". --- Makefile.old Sun Jun 21 19:23:17 1998 +++ Makefile Sun Jun 21 19:23:24 1998 @@ -19,7 +19,7 @@ MFLAGS=DLLDIR=$(DLLDIR) -SUBDIRS=test misc +SUBDIRS=test include $(LIBGGI_TOPLEVEL)/Makerules Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sun Jun 21 19:57:24 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA19110; Sun, 21 Jun 1998 19:57:19 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA10811; Sun, 21 Jun 1998 19:59:05 -0700 Resent-Date: Sun, 21 Jun 1998 19:59:05 -0700 Date: Sun, 21 Jun 1998 22:58:47 -0400 (EDT) From: Steve Cheng Sender: steve@maxt7m48.ipoline.com To: ggi-develop@eskimo.com Subject: Re: LibGGI for X In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"MUez23.0.pe2.uXSZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2955 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 21 Jun 1998, KC5TJA wrote: > I'd like to compile the latest libGGI for X-Windows only. I am using > Debian 2.0, with glibc 2 installed. Can I do this? Especially with all > the discussion about who screwed up what? :-) If so, what are the > procedures to do so? Yes it is possible. In fact I don't use kgi/evstack [yet]. Simply go into the directory lib/libggi, then make config (selects which display targets you want, etc.) make make install Current compile might fail with extensions/misc/display/svgalib. Either wait for the fix or comment it out from extensions/misc/display/Makefile. -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Sun Jun 21 20:36:21 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA19151; Sun, 21 Jun 1998 20:36:18 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id UAA15502; Sun, 21 Jun 1998 20:37:18 -0700 Resent-Date: Sun, 21 Jun 1998 20:37:18 -0700 Date: Sun, 21 Jun 1998 20:37:08 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: CVS write access Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"_OGBR2.0.6o3.j5TZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2956 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I am accumulating a lot of changes that need to be committed, and Emmanuel has not yet applied the new crypted passwd entry I sent him so I only have read-only guest access to cvsdevel right now. I am getting nervous about this - the longer these changes stay out, the more likely it is that someone else's changes will clash with mine. Could someone with write access please "lend" me their username/password until I get my own working properly? I realize this is irregular, but I would really appreciate it. The changes I have made are mostly in two areas: - The Glide LibGGI display target now works again, is properly integrated with the make system and is represented in libggi.conf. It now works as well as it did in Dali - No GGI_AUTO yet and demo.c hangs somewhere, but testpattern.c runs to completion. I have not tried XGGI yet, but it is unlikely it will work as Glide wants to grab stdin for its own purposes and X closes stdin, thus hanging Glide. Can anyone think of a possible way around this? - The Trio64V+ KGI driver does NOT yet work, but all the necessary directories, .configure files, etc are in place and the driver compiles OK but segfaults on init somewhere. I just want to get the files and directories set up in CVS before I go much further... also, after the driver is working as it did in Dali, I plan on converting the S3 driver system over to the one used by the Matrox drivers, which removes the need for those .inc files. VGA should go this way as well. But, this change will affect a lot of drivers and so I need to coordinate my efforts with the other S3 driver coders to ensure that it all goes smoothly. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sun Jun 21 20:51:19 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA19156; Sun, 21 Jun 1998 20:51:08 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id UAA16839; Sun, 21 Jun 1998 20:49:03 -0700 Resent-Date: Sun, 21 Jun 1998 20:49:03 -0700 Date: Sun, 21 Jun 1998 20:42:11 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: LibGGI for X In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"wXjza3.0._64.lGTZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2957 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Current compile might fail with extensions/misc/display/svgalib. Either > wait for the fix or comment it out from extensions/misc/display/Makefile. I don't have SVGALIB installed anyway -- never installed any games for it, so I don't have a need for it. :) Thanks for the information. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Mon Jun 22 00:07:53 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA19224; Mon, 22 Jun 1998 00:07:51 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id AAA04283; Mon, 22 Jun 1998 00:03:54 -0700 Resent-Date: Mon, 22 Jun 1998 00:03:54 -0700 Date: Mon, 22 Jun 1998 00:03:42 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: Don't need to borrow a CVS login after all Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"lD4Bq2.0.k21.Q7WZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2958 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I got through to Emmanuel and all is well. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Mon Jun 22 01:02:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA19370; Mon, 22 Jun 1998 01:02:13 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA09855; Mon, 22 Jun 1998 00:54:41 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 00:54:41 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Message-Id: <199806220749.JAA28350@sunserver1.rz.uni-duesseldorf.de> Subject: Re: LibGGI patch In-Reply-To: from "Jon M. Taylor" at "Jun 21, 98 07:31:34 pm" To: ggi-develop@eskimo.com Date: Mon, 22 Jun 1998 09:49:08 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"RhFcv3.0.iP2.-sWZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2959 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Apply to lib/libggi/extensions/Makefile - it thinks a "misc" > directory is there and it isn't which breaks toplevel "make clean". ??? It isn't ? It should be - I checked it in ... will investigate ... CU,ANdy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 22 01:06:43 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA19386; Mon, 22 Jun 1998 01:06:41 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id AAA09255; Mon, 22 Jun 1998 00:55:55 -0700 Resent-Date: Mon, 22 Jun 1998 00:55:55 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806220755.JAA00862@sunserver1.rz.uni-duesseldorf.de> Subject: Re: LibGGI for X In-Reply-To: from Steve Cheng at "Jun 21, 98 10:58:47 pm" To: ggi-develop@eskimo.com Date: Mon, 22 Jun 1998 09:55:08 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"mBjxi3.0.VG2.BuWZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2960 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > Current compile might fail with extensions/misc/display/svgalib. Either > wait for the fix or comment it out from extensions/misc/display/Makefile. The Makefile should detect if SVGAlib is configured or not and not try to build it, if it ain't configured. Could someone with a working SVGAlib actually check if my "out of the blue" hack works as expected ? Misctest should draw a bunch of rays and then use splitline. The one doing that could also add some RayPos tests to misctest ... CU,ANdy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 22 01:39:05 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA19411; Mon, 22 Jun 1998 01:38:59 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA15466; Mon, 22 Jun 1998 01:32:34 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 01:32:34 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806220824.KAA24962@cip8.e-technik.uni-erlangen.de> Subject: Re: CVS stuff To: ggi-develop@eskimo.com Date: Mon, 22 Jun 1998 10:24:37 +0200 (MESZ) In-Reply-To: <199806170845.KAA20789@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at Jun 17, 98 10:45:08 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"H3Xcd1.0.Xn3.XQXZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2961 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com You convinced me to remove all but sgml and txt from the repository. Currently preformatted documents can only be retrieved using my web site. I plan to do some (autommated) uploading to ftp.ggi-project.org as well. > Compromise: > we'll put only sgml, txt, html and dvi into the CVS and the snapshots > (that makes uncompressed volume go down from 3M to <1M). > > I have put a copy of the html tree onto my homepage, along with > tar.gz's of all types (txt, sgml, html, tex, dvi, ps). > You'l find the link from our ggi home page->links->misc links->more links. > > Now somebody has to tell me how to remove files and directories from > a CVS. It looks like the ps, tex, dvi and html directories are still present somewhere in the repository. It's not mission critical, but if someone who knows (Todd?) can have a look how to remove them entirely? > Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 22 02:47:51 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA19464; Mon, 22 Jun 1998 02:47:44 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id CAA17091; Mon, 22 Jun 1998 02:28:43 -0700 Resent-Date: Mon, 22 Jun 1998 02:28:43 -0700 X-Sender: ortalo@poptsf.laas.fr Message-Id: In-Reply-To: <19980621142418.07694@fries.net> References: ; from Rodolphe Ortalo on Sun, Jun 21, 1998 at 11:48:59AM +0200 <199806210845.KAA16857@zafir.e.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro F3.1.3 Date: Mon, 22 Jun 1998 11:31:02 +0200 To: ggi-develop@eskimo.com From: Rodolphe Ortalo Subject: Re: Where are the diffs ? Resent-Message-ID: <"fMhVU3.0.rA4.AFYZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2962 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >Todd Fries .. toddf@acm.org : >I'm sure no one here is arguing with the ideals of why one needs to >have a 'play-place' to test changes with other people, and why it is >crutial to have a 'stable release' with quality assurance. However, >there is no clean easy way to get from one to the other and thus >people are not happy with the legwork required to make this happen in >real life. I'm sure somehow somewhere there is an easy solution. But >maybe not. Well, in my opinion, this _is_ the easy solution. I mean: we all work in the devel tree (and this is normal as we are devel-opers). And we know when we have to commit things into it. We know also when we have to build a patch and send it to the stable tree. Whats the problem ? I see the development cycle ;-) like this: cd /usr/local/degas-devel {emacs,vi} newfile.c [{emacs,vi} ; make ]* cvs add newfile.c; cvs commit newfile.c [{emacs,vi} ; make ]* cvs commit newfile.c [{emacs,vi} ; make; gdb; xxgdb; strace; [cup of coffee]* ]* cvs commit newfile.c pine; [{emacs,vi} ; make; gdb; xxgdb; strace; [bottle of coffee]* ]* cvs commit newfile.c sleep 86400*{2,3,4} # not the machine: the developper... # note that this is _before_ building the patch ;-) cd /usr/local/degas-stable cvs update make patch STABLE=/usr/local/degas-stable FILES="newfile.c Makefile" mail big_boss@ggi-project.org and attach patch_me_newfile_dd_mm_yy and then turn to newfile2.c... AArrggg. It's not so difficult... No ? Rodolphe From ggi-develop-request@eskimo.com Mon Jun 22 05:04:35 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA19536; Mon, 22 Jun 1998 05:04:33 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA01501; Mon, 22 Jun 1998 04:59:13 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 04:59:13 -0700 (PDT) From: Andrew Apted Message-ID: <19980622143649.41245@ajax.netspace.net.au> Date: Mon, 22 Jun 1998 14:36:49 +1000 To: ggi-develop@eskimo.com Subject: Re: Where are the diffs ? Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from becka@rz.uni-duesseldorf.de on Sun, Jun 21, 1998 at 02:00:47PM +0200 Resent-Message-ID: <"-fI443.0.LN.FSaZr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2963 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andy writes: > So I'd suggest we do the following: > > We go as Linux kernel does, developing on a devel-tree, introducing a > feature freeze from time to time, calling the result a stable tree > and then starting over. > > However we need to have a much more rapid development cycle at this > stage, so what I propose is: > > 1. We set a release-cycle of 1 month. > > 2. Development goes normally from the 1st to the 24th each month. > > 3. Feature freeze sets in at the 25th each month. That should leave about a > week to set things straight until the devel tree is moved to the stable > tree at the first of each month. > > 4. If bugs are reported from the stable tree, _everyone_ that know what is > going on should try to fix those ASAP in _both_ trees (sort of how we > came to Linux 2.0.34). > > Would that be acceptable ? Fine with me. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Mon Jun 22 05:11:16 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA19541; Mon, 22 Jun 1998 05:11:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA01905; Mon, 22 Jun 1998 05:06:04 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 05:06:04 -0700 (PDT) Message-ID: <19980622070034.00900@fries.net> Date: Mon, 22 Jun 1998 07:00:34 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: LibGGI patch References: <199806220749.JAA28350@sunserver1.rz.uni-duesseldorf.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199806220749.JAA28350@sunserver1.rz.uni-duesseldorf.de>; from becka@rz.uni-duesseldorf.de on Mon, Jun 22, 1998 at 09:49:08AM +0200 Resent-Message-ID: <"0uXCX2.0.YT.eYaZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2964 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, Jun 22, 1998 at 09:49:08AM +0200, becka@rz.uni-duesseldorf.de wrote: > > Apply to lib/libggi/extensions/Makefile - it thinks a "misc" > > directory is there and it isn't which breaks toplevel "make clean". > > ??? It isn't ? It should be - I checked it in ... will investigate ... I saw you check it into the stable repo. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Mon Jun 22 05:33:12 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA19570; Mon, 22 Jun 1998 05:33:05 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA29497; Mon, 22 Jun 1998 05:09:45 -0700 Resent-Date: Mon, 22 Jun 1998 05:09:45 -0700 Date: Mon, 22 Jun 1998 13:09:12 +0100 Message-Id: <199806221209.NAA23391@pcsw104b.ukc.ac.uk> To: ggi-develop@eskimo.com Cc: Charles Briscoe-Smith From: Charles Briscoe-Smith Subject: Debian packages available; here are the patches Resent-Message-ID: <"2tju53.0.nC7.8caZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2965 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com [ I originally tried to send this on Saturday, but I don't think it got through... This is the second try. ] Hi all, I've now got some Debian packages of libGGI built, and have put them at They should also appear in the current Debian unstable distribution (slink) soon. I used the 980619 snapshot of the stable tree, but had to make quite a few patches to get it to build and clean properly. I couldn't build these programs in lib/libggi/demos, since ggiDrawCircle has been removed: demo.c saver.c testpattern.c subdemo.c tunemode.c Lintian (the Debian package-checking tool) pointed out that xf86dga.so contains code which isn't compiled with -fPIC. It seems to be the code linked in from these files which causes it: /usr/X11R6/lib/libXxf86dga.a /usr/X11R6/lib/libXxf86vm.a There don't seem to be .so versions of these libraries, so I'm not sure what should be done here. Does anyone know whether this actually causes any problems in practice? Now the patches. This makes sure all the libraries are cleaned up; previously some were left after a "make clean": ---------------------------------------------------------------------- --- ggi-stable-980619.orig/lib/libggi/Makerules +++ ggi-stable-980619/lib/libggi/Makerules @@ -152,7 +152,7 @@ $(SHBINLINKER) $(SHBINCFLAGS) $(CFLAGS) -o $@ $(PATCHLIBOBJS) rmfiles=$(wildcard $(OBJECTS) $(DLTARGET) $(ARTARGET) $(SONAME) ) \ - $(wildcard $(DLLDIR)/$(DIR).$(DLLEXT) libggi.$(DLLEXT) core *~ ) \ + $(wildcard $(DLLDIR)/$(DIR).$(DLLEXT) $(LIBGGI) core *~ ) \ $(wildcard $(SHLIB) $(EXPORTSFILE) $(SHLIBGGI_A) $(EXTRARMFILES) ) \ $(wildcard $(SHBIN) $(SHBINS) $(SHLIBOBJECTS) $(SHBINOBJECTS) ) \ $(wildcard $(PATCHLIB) $(PATCHLIBOBJS) $(LIBGGICONF) $(SHLIBGGI) ) ---------------------------------------------------------------------- The svgalib target doesn't build without this: ---------------------------------------------------------------------- --- ggi-stable-980619.orig/lib/libggi/display/svgalib/mode.c +++ ggi-stable-980619/lib/libggi/display/svgalib/mode.c @@ -29,15 +29,16 @@ #include "ggi-dl.h" #include "vgavisual.h" +#include "../../extensions/misc/misc.h" int GGIwaitraypos(ggi_visual *vis,sint32 *x,sint32 *y) { - if (*y == GGIRP_SYNC && *x == GGIRP_DONTCARE) { + if (*y == GGI_RP_SYNC && *x == GGI_RP_DONTCARE) { vga_waitretrace(); return 0; } - *x = GGIRP_DONTCARE; - *y = GGIRP_SYNC; + *x = GGI_RP_DONTCARE; + *y = GGI_RP_SYNC; return 1; } --- ggi-stable-980619.orig/lib/libggi/extensions/misc/display/svgalib/mode.c +++ ggi-stable-980619/lib/libggi/extensions/misc/display/svgalib/mode.c @@ -29,15 +29,16 @@ #include "ggi-dl.h" #include "vgavisual.h" +#include "../../misc.h" int GGIwaitraypos(ggi_visual *vis,sint32 *x,sint32 *y) { - if (*y == GGIRP_SYNC && *x == GGIRP_DONTCARE) { + if (*y == GGI_RP_SYNC && *x == GGI_RP_DONTCARE) { vga_waitretrace(); return 0; } - *x = GGIRP_DONTCARE; - *y = GGIRP_SYNC; + *x = GGI_RP_DONTCARE; + *y = GGI_RP_SYNC; return 1; } ---------------------------------------------------------------------- This allows exttest1 to be built, and removes both it and misctest correctly on clean: ---------------------------------------------------------------------- --- ggi-stable-980619.orig/lib/libggi/extensions/test/Makefile +++ ggi-stable-980619/lib/libggi/extensions/test/Makefile @@ -1,10 +1,11 @@ -CFLAGS=-O2 -Wall -I../../include -I/usr/local/include -L../.. +CFLAGS=-O2 -Wall -I../../include -I/usr/local/include -L../.. \ + -I../../../../include exttest1: exttest1.o test1.o test2.o $(CC) $(CFLAGS) $^ -lggi -o $@ clean: - rm -f *.o + rm -f *.o exttest1 install: --- ggi-stable-980619.orig/lib/libggi/extensions/misc/demos/Makefile +++ ggi-stable-980619/lib/libggi/extensions/misc/demos/Makefile @@ -4,7 +4,7 @@ $(CC) $(CFLAGS) $^ -lggimisc -lggi -o $@ clean: - rm -f *.o + rm -f *.o misctest install: ---------------------------------------------------------------------- There seem to be some files missing in lib/libggi/extensions/misc/display/svgalib. I'm sure this is not the right fix, but it does stop the build process from bombing out: ---------------------------------------------------------------------- --- ggi-stable-980619.orig/lib/libggi/extensions/misc/display/svgalib/Makefile +++ ggi-stable-980619/lib/libggi/extensions/misc/display/svgalib/Makefile @@ -17,7 +17,8 @@ # # ---------------------------------------------------------------------------- -SOURCES=visual.c mode.c color.c events.c hline.c vline.c pixel.c box.c +#SOURCES=visual.c mode.c color.c events.c hline.c vline.c pixel.c box.c +SOURCES=visual.c mode.c SUBLIB=$(DIR)-misc ---------------------------------------------------------------------- -- Charles Briscoe-Smith White pages entry, with PGP key: PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 From ggi-develop-request@eskimo.com Mon Jun 22 06:22:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA19588; Mon, 22 Jun 1998 06:22:55 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA07984; Mon, 22 Jun 1998 06:13:56 -0700 Resent-Date: Mon, 22 Jun 1998 06:13:56 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806221253.OAA10293@sunserver1.rz.uni-duesseldorf.de> Subject: Re: Debian packages available; here are the patches In-Reply-To: <199806221209.NAA23391@pcsw104b.ukc.ac.uk> from Charles Briscoe-Smith at "Jun 22, 98 01:09:12 pm" To: ggi-develop@eskimo.com Date: Mon, 22 Jun 1998 14:53:38 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"65jl22.0.ey1.KYbZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2966 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I've now got some Debian packages of libGGI built, and have put them at > Thanks ! > I couldn't build these programs in lib/libggi/demos, since ggiDrawCircle > has been removed: > > demo.c this should have been fixed in the meantime ... will check further. > Lintian (the Debian package-checking tool) pointed out that xf86dga.so > contains code which isn't compiled with -fPIC. It seems to be the code > linked in from these files which causes it: > /usr/X11R6/lib/libXxf86dga.a > /usr/X11R6/lib/libXxf86vm.a > There don't seem to be .so versions of these libraries, so I'm not sure > what should be done here. Does anyone know whether this actually causes > any problems in practice? Hmm IIRC this will result in page-sharing for the resulting library to fail, thus a separate copy of it will be loaded for each program that uses it. Shouldn't be much of a deal. Someone here with working XF86DGA to check that ? > Now the patches. This makes sure all the libraries are cleaned up; > previously some were left after a "make clean": Thanks. I'll have a look at those and try to fix these issues in both the stable and the devel tree. Anyone else who wants to work on those, please notify me, to avoid double work. > The svgalib target doesn't build without this: > > ---------------------------------------------------------------------- > --- ggi-stable-980619.orig/lib/libggi/display/svgalib/mode.c > +++ ggi-stable-980619/lib/libggi/display/svgalib/mode.c > @@ -29,15 +29,16 @@ > > #include "ggi-dl.h" > #include "vgavisual.h" > +#include "../../extensions/misc/misc.h" > > int GGIwaitraypos(ggi_visual *vis,sint32 *x,sint32 *y) > { > - if (*y == GGIRP_SYNC && *x == GGIRP_DONTCARE) { > + if (*y == GGI_RP_SYNC && *x == GGI_RP_DONTCARE) { > vga_waitretrace(); > return 0; > } > - *x = GGIRP_DONTCARE; > - *y = GGIRP_SYNC; > + *x = GGI_RP_DONTCARE; > + *y = GGI_RP_SYNC; > > return 1; > } This is a bug. It needs to be moved to the Misc extension. CU, ANdy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 22 07:39:23 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA19612; Mon, 22 Jun 1998 07:39:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA10535; Mon, 22 Jun 1998 06:26:30 -0700 Resent-Date: Mon, 22 Jun 1998 06:26:30 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806221310.PAA14054@sunserver1.rz.uni-duesseldorf.de> Subject: Re: LibGGI patch In-Reply-To: <19980622070034.00900@fries.net> from "Todd T. Fries" at "Jun 22, 98 07:00:34 am" To: ggi-develop@eskimo.com Date: Mon, 22 Jun 1998 15:10:44 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ZQya6.0.Ua2.5kbZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2967 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > > Apply to lib/libggi/extensions/Makefile - it thinks a "misc" > > > directory is there and it isn't which breaks toplevel "make clean". > > ??? It isn't ? It should be - I checked it in ... will investigate ... > I saw you check it into the stable repo. I also checked it into the devel repo. Have just checked. Whoever had the problem : Please reget your snapshot - maybe you missed the "-PAd" at CVS update ? This way the Makfile will be updated, but it won't search for new directories ... CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 22 07:44:04 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA19628; Mon, 22 Jun 1998 07:44:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA27602; Mon, 22 Jun 1998 07:35:41 -0700 Resent-Date: Mon, 22 Jun 1998 07:35:41 -0700 Date: Mon, 22 Jun 1998 10:35:23 -0400 (EDT) From: Steve Cheng Sender: steve@maxt4m05.ipoline.com To: ggi-develop@eskimo.com Subject: Re: Debian packages available; here are the patches In-Reply-To: <199806221253.OAA10293@sunserver1.rz.uni-duesseldorf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"7Uo6j.0.5l6.xkcZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2969 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 22 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > > Lintian (the Debian package-checking tool) pointed out that xf86dga.so > > contains code which isn't compiled with -fPIC. It seems to be the code > > linked in from these files which causes it: > > /usr/X11R6/lib/libXxf86dga.a > > /usr/X11R6/lib/libXxf86vm.a > > There don't seem to be .so versions of these libraries, so I'm not sure > > what should be done here. Does anyone know whether this actually causes > > any problems in practice? > > Hmm IIRC this will result in page-sharing for the resulting library to fail, > thus a separate copy of it will be loaded for each program that uses it. > Shouldn't be much of a deal. Someone here with working XF86DGA to check that ? XFree86 installs these, and I see they aren't -fPIC. But you couldn't use more than one XF86DGA app at a time anyway, because it greedily grabs the whole framebuffer and doesn't give it up until the app exits. If you really need -fPIC then you'll have to get XFree86 source and compile it... > Anyone else who wants to work on those, please notify me, to avoid double > work. > > - if (*y == GGIRP_SYNC && *x == GGIRP_DONTCARE) { > > + if (*y == GGI_RP_SYNC && *x == GGI_RP_DONTCARE) { > This is a bug. It needs to be moved to the Misc extension. Ah, this is the bug I reported yesterday. It is in devel yesterday too. I'll leave someone else to fix since I'm not too familiar with the extensions mechanism yet. -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Mon Jun 22 07:46:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA19634; Mon, 22 Jun 1998 07:46:50 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA23792; Mon, 22 Jun 1998 07:36:03 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 07:36:03 -0700 (PDT) Date: Mon, 22 Jun 1998 07:26:52 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com cc: Charles Briscoe-Smith Subject: Re: Debian packages available; here are the patches In-Reply-To: <199806221209.NAA23391@pcsw104b.ukc.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"n_ixe1.0.cp5.HlcZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2968 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 22 Jun 1998, Charles Briscoe-Smith wrote: > I've now got some Debian packages of libGGI built, and have put them at > Will this also work with Hamm (Debian 2.0)? ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Mon Jun 22 08:02:53 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA19683; Mon, 22 Jun 1998 08:02:50 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA26094; Mon, 22 Jun 1998 07:51:40 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 07:51:40 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806221444.QAA03988@cip8.e-technik.uni-erlangen.de> Subject: libggi issues: alpha To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Mon, 22 Jun 1998 16:44:21 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"U7x2W2.0.cN6.wzcZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2970 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! Round three is open, it looks like the consensus is near in most cases. For alpha, there seems to be agreement that the base libggi will not support alpha-value-aware graphic primitives. One question remains: Do we want to change ggi_color from rgb to rgba? This - avoids having a separate rgba color somewhere else - makes ggi_color properly aligned (4 shorts) - probably makes the alpha value range 0..0xffff as the rgb value range? Yes or no? Andy? -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 22 08:16:58 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA19704; Mon, 22 Jun 1998 08:16:57 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA29993; Mon, 22 Jun 1998 08:17:04 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 08:17:04 -0700 (PDT) Date: Mon, 22 Jun 1998 08:02:48 -0700 (PDT) From: KC5TJA To: ggi Mailingliste Subject: Re: libggi issues: alpha In-Reply-To: <199806221444.QAA03988@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"l6ubX1.0.SK7.iLdZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2971 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > This > - avoids having a separate rgba color somewhere else > - makes ggi_color properly aligned (4 shorts) > - probably makes the alpha value range 0..0xffff as the rgb value range? > > Yes or no? > Andy? I think it should be done. What's the worst that can happen: Alpha channel be ignored? ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Mon Jun 22 09:23:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA19761; Mon, 22 Jun 1998 09:23:48 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA10382; Mon, 22 Jun 1998 09:12:34 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 09:12:34 -0700 (PDT) Date: Mon, 22 Jun 1998 18:01:22 +0200 (MEST) Reply-To: Uwe Maurer To: ggi-develop@eskimo.com Subject: Mesa, GLUT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: 08142597465-0001@t-online.de From: Uwe_Maurer@t-online.de (Uwe Maurer) Resent-Message-ID: <"O04__3.0.5Y2.m9eZr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2972 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! The new ggimesa-patch (including glut for ggi) is at http://home.t-online.de/home/uwe_maurer/ggimesa.htm Keyboard and Mouse-input don't work with the new libggi. (I have only tested it with display-X) Uwe From ggi-develop-request@eskimo.com Mon Jun 22 09:47:05 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA19837; Mon, 22 Jun 1998 09:47:00 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA09111; Mon, 22 Jun 1998 09:45:18 -0700 Resent-Date: Mon, 22 Jun 1998 09:45:18 -0700 Message-ID: <524299DFAB41D11193EF00805F8598026AA06F@brekka.ch2m.com> From: "Fulgham, Brent/SCO" To: "'ggi-develop@eskimo.com'" Subject: Some more makefile suggestions Date: Mon, 22 Jun 1998 10:45:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2120.0) Content-Type: text/plain Resent-Message-ID: <"9Y_ym.0.AE2.TeeZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2973 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This is relatively minor, but I keep having to fix it each time I synch with CVS and recompile my LibGGI (hoping and hoping that mesaGGI will work :) ) ANSI C no longer recognizes the "inline" keyword. The makefiles for LibGGI treat this as a warning and just complain on-screen, but other software that uses the LibGGI.h header files aren't as forgiving. I have to manually remove the "inline" keyword from the header file if I want to compile Mesa (and possibly other things). I noticed that the makefile checks for some compilers that don't allow the "inline" keyword, but it flags GNU as accepting it. Can we adjust the makefile so that it registers "egcs" as a compiler that won't allow the inline keyword? -Brent From ggi-develop-request@eskimo.com Mon Jun 22 09:56:14 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA19878; Mon, 22 Jun 1998 09:56:07 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA18069; Mon, 22 Jun 1998 09:58:59 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 09:58:59 -0700 (PDT) Sender: wouter@cistron.nl Message-ID: <358E8BC3.5982591F@cistron.nl> Date: Mon, 22 Jun 1998 18:52:19 +0200 From: Wouter Scholten X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: I'm back Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"5n0t-2.0.CQ4.GreZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2974 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all, been away a bit. I still don't see the stuff I uploaded to synergy (descent, gsi, patches) anywhere. What's going on? Will make one or more replies to a few posts later (one on licensing in particular; I think the license back to yourself clause isn't needed as I mentioned before) Going to read the archive now.. Wouter From ggi-develop-request@eskimo.com Mon Jun 22 10:10:51 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA19892; Mon, 22 Jun 1998 10:10:50 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA12928; Mon, 22 Jun 1998 10:06:15 -0700 Resent-Date: Mon, 22 Jun 1998 10:06:15 -0700 Sender: wouter@cistron.nl Message-ID: <358E8F2E.736042B4@cistron.nl> Date: Mon, 22 Jun 1998 19:06:54 +0200 From: Wouter Scholten X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Open Source Certification (yet more licensing comments) (teunis) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7kmdy3.0.r93.6yeZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2975 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com ME: > Well, this is simply NOT correct. This would mean for example that I can > never change the license for software, that I cannot reuse my own code > that I give away. That's silly and not what copyright law is about. > Copyright conditions are for those who receive things, not for those who > create things. If this were true, then I cannot make a commercial > derivative of a program I put under GPL for example (which I know I > can). Teunis: ----------- Sorry - copyright protects the owner of the copywrite, not the author. This licence modification protects the -AUTHOR- as well! (I worked for a company where all work I did was copyright them. This is a perfectly normal situation but it's very irritating if you want to use any of your work anywhere else.....) ------------------- This is precisely what I mean. When I write it, I put it under a copyright; when I write it for someone else, I actually sell it, so I don't own the copyright any more [I made that point elsewhere]. So, my point is, that the copyright owner should be allowed to do whatever he wants with the code. If this is not the case, which Kendall implies (although I'm not convinced at all by 'lawyers believe' etc; probably just a priori protection from insane litigation practices in the USA) then this has some very silly and nasty consequences which just aren't acceptable (eg. being unable to undo (partially) a mistake in a license). Wouter From ggi-develop-request@eskimo.com Mon Jun 22 11:06:47 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA19982; Mon, 22 Jun 1998 11:06:36 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA30998; Mon, 22 Jun 1998 11:03:51 -0700 Resent-Date: Mon, 22 Jun 1998 11:03:51 -0700 Date: Tue, 23 Jun 1998 11:02:18 -0700 (MST) From: teunis To: Peter Amstutz cc: ggi-develop@eskimo.com Subject: Re: Misc libggi stuff (threading) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"RlOLi3.0.7a7.4ofZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2976 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 20 Jun 1998, Peter Amstutz wrote: > On Sat, 20 Jun 1998, teunis wrote: > > > Hmmm - now how to -test- thread-compliance? Gonna have to think of > > How about a mandelbrot using some n^2 threads, where each thread renders > its square and try to draw simultaniously via (hopefully threadsafe) > libggi? That sounds good - but perhaps something like "demo" done in multiple windows simultaneously (to test different functions). Or perhaps both this + demo... (and 'stars' :) Haveta think. > > something.... BTW - anyone running GGI under an SMP (or equiv) > > architecture? > > 2.1.103-SMP /w dual p200 right here. Not using a ggi kernel at the moment > though *sigh* What do you want to know? I take it then the GGI kernel isn't ready? But how well do GGI processes share? Are there any probs with X? (just curious) I don't think any of what I'm really wondering can be found out outside of KGI though as AFAIK X handles SMP properly... (and GGI in a multiprocessing system wouldn't change... Only multithreading should mess up if it messes up at all) G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Mon Jun 22 11:55:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA20020; Mon, 22 Jun 1998 11:55:53 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA17463; Mon, 22 Jun 1998 11:55:04 -0700 Resent-Date: Mon, 22 Jun 1998 11:55:04 -0700 Date: Tue, 23 Jun 1998 11:53:42 -0700 (MST) From: teunis To: GGI Developers Subject: ViRGE driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"GqsJ23.0.lG4.8YgZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2977 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Okay - on following email a bit I'm going to wait until the VGA driver is operational.... (that should handle the last cleanup of bugs :) Hopefully this won't take long (I'll start looking at the VGA driver as soon as I can figure out what's crashing my computer -this- time *grr*.) G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Mon Jun 22 12:27:35 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA20028; Mon, 22 Jun 1998 12:27:25 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA23251; Mon, 22 Jun 1998 12:23:39 -0700 Resent-Date: Mon, 22 Jun 1998 12:23:39 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Where are the diffs ? To: ggi-develop@eskimo.com (mailing list GGI) Date: Mon, 22 Jun 1998 20:03:05 +0200 (MET DST) In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jun 21, 98 02:00:47 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"RpxeI1.0.6h5.xygZr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2978 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com O.K. - noone opposed to it, so this is our new scheme : > 1. We set a release-cycle of 1 month. > > 2. Development goes normally from the 1st to the 24th each month. > > 3. Feature freeze sets in at the 25th each month. That should leave about a > week to set things straight until the devel tree is moved to the stable > tree at the first of each month. > > 4. If bugs are reported from the stable tree, _everyone_ that know what is > going on should try to fix those ASAP in _both_ trees (sort of how we > came to Linux 2.0.34). So I announce a feature freeze for Thursday, 25th of June. >From that date on, we will be busy fixing any bugs reported, testing installation and such. Anyone checking in new features at that time without the approval of the respective maintainer (me, Steffen, Jason, Emmanuel or Hartmut) will wish he hadn't done it *evil grin*. CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 22 14:25:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA20160; Mon, 22 Jun 1998 14:25:49 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA01911; Mon, 22 Jun 1998 14:27:06 -0700 Resent-Date: Mon, 22 Jun 1998 14:27:06 -0700 Date: Mon, 22 Jun 1998 23:26:59 +0200 (MET DST) From: Rodolphe Ortalo X-Sender: ortalo@schubert To: ggi-develop@eskimo.com Subject: I don't understand football rules... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"YXY9f3.0.iT.fmiZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2980 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com ...and helicopters scouting in the town sky at midnight, looking for hords of wandering hooligans. Dr. Ortalo, from Toulouse, France - GGI Information Center. From ggi-develop-request@eskimo.com Mon Jun 22 14:27:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA20165; Mon, 22 Jun 1998 14:27:38 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA03717; Mon, 22 Jun 1998 14:21:10 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 14:21:10 -0700 (PDT) Date: Mon, 22 Jun 1998 23:12:45 +0200 (MEST) From: Jan Kneschke To: GGI Developers Subject: Re: ViRGE driver In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"y4R8M1.0.xv.2hiZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2979 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 23 Jun 1998, teunis wrote: > Okay - on following email a bit I'm going to wait until the VGA driver is > operational.... (that should handle the last cleanup of bugs :) > > Hopefully this won't take long (I'll start looking at the VGA driver as > soon as I can figure out what's crashing my computer -this- time *grr*.) is the new kgi-driver-guide already out ?? or which specs guide you through the black forest of wisdom ?? > > G'day, eh? :) > - Teunis > > thats all Jan --- Project: GGI - S3-Vision-driver -- http://www.ggi-project.org/ -)= Jan (Weigon) Kneschke -- Kiel -- Northern Germany =(- From ggi-develop-request@eskimo.com Mon Jun 22 15:04:02 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA20193; Mon, 22 Jun 1998 15:03:58 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA12540; Mon, 22 Jun 1998 15:05:09 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 15:05:09 -0700 (PDT) Date: Mon, 22 Jun 1998 23:56:54 +0200 (MEST) From: Jan Kneschke To: ggi-develop@eskimo.com Subject: Re: I don't understand football rules... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"w_QH21.0.p33.IKjZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2981 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 22 Jun 1998, Rodolphe Ortalo wrote: > ...and helicopters scouting in the town sky at midnight, looking > for hords of wandering hooligans. > > Dr. Ortalo, from Toulouse, France - GGI Information Center. i just wanna say that damaging is not discribe in german or english football rules. i hope that the people in lens are prepared if the english are fired out of the cup on the 26.6., same for the german in on day earlier in montpellier. i think that nigeria will win. (yes, i'm german .) thats all Jan --- Project: GGI - S3-Vision-driver -- http://www.ggi-project.org/ -)= Jan (Weigon) Kneschke -- Kiel -- Northern Germany =(- From ggi-develop-request@eskimo.com Mon Jun 22 15:16:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA20206; Mon, 22 Jun 1998 15:16:37 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA13134; Mon, 22 Jun 1998 15:09:09 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 15:09:09 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Debian packages available; here are the patches To: ggi-develop@eskimo.com Date: Mon, 22 Jun 1998 23:32:47 +0200 (MET DST) In-Reply-To: <199806221209.NAA23391@pcsw104b.ukc.ac.uk> from "Charles Briscoe-Smith" at Jun 22, 98 01:09:12 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"PY2lc.0.3D3.2OjZr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2982 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! I am currently applying the changes you suggested to the _devel_ repository. We will move this over to stable at the 1st of July. > I couldn't build these programs in lib/libggi/demos, since ggiDrawCircle > has been removed: > > demo.c > saver.c > testpattern.c Were already fixed in the meantime. > subdemo.c > tunemode.c I fixed those somewhat ugly by using a new file mycircle.inc which basically has the circle algorithm ... We should fade that out ... > Now the patches. This makes sure all the libraries are cleaned up; > previously some were left after a "make clean": > > ---------------------------------------------------------------------- > --- ggi-stable-980619.orig/lib/libggi/Makerules > +++ ggi-stable-980619/lib/libggi/Makerules > @@ -152,7 +152,7 @@ > $(SHBINLINKER) $(SHBINCFLAGS) $(CFLAGS) -o $@ $(PATCHLIBOBJS) > > rmfiles=$(wildcard $(OBJECTS) $(DLTARGET) $(ARTARGET) $(SONAME) ) \ > - $(wildcard $(DLLDIR)/$(DIR).$(DLLEXT) libggi.$(DLLEXT) core *~ ) \ > + $(wildcard $(DLLDIR)/$(DIR).$(DLLEXT) $(LIBGGI) core *~ ) \ Are you sure ? Where does that one get defined ? (I always get lost in those Makefiles ...) > The svgalib target doesn't build without this: It's broken. I'm trying to fix it ... Pretty hard when your SVGAlib doesn't work :-). > --- ggi-stable-980619.orig/lib/libggi/display/svgalib/mode.c > +++ ggi-stable-980619/lib/libggi/display/svgalib/mode.c I removed this section. It doesn't belong there. > --- ggi-stable-980619.orig/lib/libggi/extensions/misc/display/svgalib/mode.c > +++ ggi-stable-980619/lib/libggi/extensions/misc/display/svgalib/mode.c Correct on that one. > This allows exttest1 to be built, and removes both it and misctest > correctly on clean: > --- ggi-stable-980619.orig/lib/libggi/extensions/misc/demos/Makefile > +++ ggi-stable-980619/lib/libggi/extensions/misc/demos/Makefile O.K. Should work now. > There seem to be some files missing in > lib/libggi/extensions/misc/display/svgalib. I'm sure this is not the > right fix, but it does stop the build process from bombing out: Yeah. Was quite right. O.K. - will commit the fixed version ASAP. CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 22 15:25:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA20213; Mon, 22 Jun 1998 15:25:39 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id PAA15090; Mon, 22 Jun 1998 15:24:40 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 15:24:40 -0700 (PDT) Message-Id: <199806222217.AAA06255@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: CVS mirrors and guest access. Date: Tue, 23 Jun 1998 00:17:13 +0200 From: Marcus Sundberg Resent-Message-ID: <"r7in62.0.gh3.bcjZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2983 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Wasn't there supposed to be some mirrors of the CVS repository? Regardless of whether there are mirrors or not we need to either turn off guest access or get a faster repository. Durin (european) daytime the repository works fine, but unfortunately I'm at work behind a firewall all days. And in the evening the repository is almost dead - it responds to pings at ~500ms and 20-30% loss, but it's impossible to do any CVS stuff. Could we please resolve this issue so we can use CVS for what it was meant for - development. //Marcus From ggi-develop-request@eskimo.com Mon Jun 22 15:35:40 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA20245; Mon, 22 Jun 1998 15:35:36 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA24241; Mon, 22 Jun 1998 15:34:59 -0700 Resent-Date: Mon, 22 Jun 1998 15:34:59 -0700 Date: Tue, 23 Jun 1998 00:34:53 +0200 (MET DST) From: Rodolphe Ortalo X-Sender: ortalo@schubert To: ggi-develop@eskimo.com Subject: Re: I don't understand football rules... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"r45Zb2.0.aw5.JmjZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2984 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 22 Jun 1998, Jan Kneschke wrote: > On Mon, 22 Jun 1998, Rodolphe Ortalo wrote: > > > ...and helicopters scouting in the town sky at midnight, looking > > for hords of wandering hooligans. > > > > Dr. Ortalo, from Toulouse, France - GGI Information Center. > > i just wanna say that damaging is not discribe in german or english football > rules. > i hope that the people in lens are prepared if the english are fired out of > the cup on the 26.6., same for the german in on day earlier in montpellier. NB: I did not want to offend anyone... It's just that, being in the right place, I thought you would like to have some direct information. In fact, the real info is, as someone said, "much to do about nothing". (GGI Info. Center: dated 23/6/98, 00H30) Our rulers put out a lot of police forces: I've never seen an helicopter doing more than 10 circles around the city center until tonight. (Maybe useful: the weather is very hot here in Toulouse, so some breathing might be interesting.) It seems all ends well (I have only two eyes, even in the right place). Everything is quiet here (and, if it wasn't, I would be really in the center of the storm, so I guess you can sleep well). > i think that nigeria will win. (yes, i'm german) Not sure. If they don't put helicopters all over the stadiums when GB or Germany plays (that might disturb players don't you think?), they may even win... But France never forgave you the 1/2 final of 1986 (or maybe it was in 1982 ?). AT least, it's disturbing for coding. ;-) Rodolphe Oh, BTW: Roumanie 2 - Angleterre 1. From ggi-develop-request@eskimo.com Mon Jun 22 15:37:47 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA20257; Mon, 22 Jun 1998 15:37:44 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA24796; Mon, 22 Jun 1998 15:37:32 -0700 Resent-Date: Mon, 22 Jun 1998 15:37:32 -0700 Message-Id: <199806222241.AAA08752@orb.suntech.fr> X-Sender: core@orb.suntech.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 23 Jun 1998 00:34:52 +0200 To: ggi-develop@eskimo.com From: Emmanuel Marty Subject: Re: CVS mirrors and guest access. In-Reply-To: <199806222217.AAA06255@zafir.e.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"wcOn81.0.I36.hojZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2985 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >Wasn't there supposed to be some mirrors of the CVS repository? Todd T. Fries has been mirroring both CVS repositories since they came back; the mirror is in the US at anoncvs.ggi-project.org, but I don't know the exact :pserver path since this information never made it to the website for some reason unknown to me. I'm sure Todd will fill in the blanks. >Regardless of whether there are mirrors or not we need to >either turn off guest access or get a faster repository. Allright, from today, guest access to the main repository is disabled. People who need to do a guest readonly checkout, do it from Todd's server. As for speed, I can hardly do much more than I did, namely putting the CVS server on an unrestricted 2 mbps link. The problem comes from Unisource, the European-wide AT&T backbone to which we are connected, which is always messed up during the evenings. >Could we please resolve this issue so we can use CVS for >what it was meant for - development. Well, I have setup the repository because development was stalled without it and I thought it would help, but if you have a better host for it and want to administer the whole thing, I'll merrily move it there and care about other things. -- Emmanuel From ggi-develop-request@eskimo.com Mon Jun 22 16:25:57 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA20315; Mon, 22 Jun 1998 16:25:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA04714; Mon, 22 Jun 1998 16:25:42 -0700 Resent-Date: Mon, 22 Jun 1998 16:25:42 -0700 Date: Mon, 22 Jun 1998 19:30:06 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi Mailingliste Subject: Re: libggi issues: alpha In-Reply-To: <199806222321.TAA00302@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Wew68.0.H91.rVkZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2986 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 22 Jun 1998, Hartmut Niemann wrote: > One question remains: > Do we want to change ggi_color from rgb to rgba? > > This > - avoids having a separate rgba color somewhere else > - makes ggi_color properly aligned (4 shorts) I'm all for it, basically for precisely those reasons. Were we to start having two different ggi_color structures that we have to convert on time, we would have a real mess on our hands. Plus most modern architectures aren't very happy if you don't align on neat 4 or 8 byte boundaries. -=MenTaLguY=- From ggi-develop-request@eskimo.com Mon Jun 22 16:39:28 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA20358; Mon, 22 Jun 1998 16:39:26 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA08916; Mon, 22 Jun 1998 16:39:03 -0700 Resent-Date: Mon, 22 Jun 1998 16:39:03 -0700 Date: Tue, 23 Jun 1998 16:37:24 -0700 (MST) From: teunis To: GGI Developers Subject: Re: ViRGE driver In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"YhKP41.0.CB2.MikZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2987 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 22 Jun 1998, Jan Kneschke wrote: > On Tue, 23 Jun 1998, teunis wrote: > > > Okay - on following email a bit I'm going to wait until the VGA driver is > > operational.... (that should handle the last cleanup of bugs :) > > > > Hopefully this won't take long (I'll start looking at the VGA driver as > > soon as I can figure out what's crashing my computer -this- time *grr*.) > > is the new kgi-driver-guide already out ?? or which specs guide you through > the black forest of wisdom ?? Don't care *grin*. I've been using EvStack-based kernels since last septembre and have taken a number of cracks at getting a working S3 driver going :) The VGA driver is pretty straightforeward and I'd like to know what's changed. S3 textmode may be completely incompatible but at least I can get an idea of what will need coding.... G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Mon Jun 22 17:42:57 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA20430; Mon, 22 Jun 1998 17:42:53 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id RAA10607; Mon, 22 Jun 1998 17:40:57 -0700 Resent-Date: Mon, 22 Jun 1998 17:40:57 -0700 Message-ID: <19980622193735.17638@fries.net> Date: Mon, 22 Jun 1998 19:37:35 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: CVS mirrors and guest access. References: <199806222217.AAA06255@zafir.e.kth.se> <199806222241.AAA08752@orb.suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199806222241.AAA08752@orb.suntech.fr>; from Emmanuel Marty on Tue, Jun 23, 1998 at 12:34:52AM +0200 Resent-Message-ID: <"MkqWN.0.Yb2.OclZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2988 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, Jun 23, 1998 at 12:34:52AM +0200, Emmanuel Marty wrote: > Todd T. Fries has been mirroring both CVS repositories since they > came back; the mirror is in the US at anoncvs.ggi-project.org, > but I don't know the exact :pserver path since this information > never made it to the website for some reason unknown to me. I'm sure > Todd will fill in the blanks. 1. :pserver: incarnation of access requires you to do 'cvs login' before 'cvs get degas' with one of the two CVSROOT's: :pserver:anoncvs@anoncvs.us.ggi-project.org:/cvs :pserver:anoncvs@anoncvs.us.ggi-project.org:/cvsdevel 2. ssh incarnation of access requires you to set 'CVS_RSH=ssh' as an environment variable, then use the following for a CVSROOT: anoncvs@anoncvs.us.ggi-project.org:/cvs anoncvs@anoncvs.us.ggi-project.org:/cvsdevel > Allright, from today, guest access to the main repository is > disabled. People who need to do a guest readonly checkout, do it > from Todd's server. Hrm, I hope I'm ready! -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Mon Jun 22 18:03:25 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA20458; Mon, 22 Jun 1998 18:03:23 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA16979; Mon, 22 Jun 1998 18:02:29 -0700 Resent-Date: Mon, 22 Jun 1998 18:02:29 -0700 Date: Mon, 22 Jun 1998 18:02:07 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: ViRGE driver In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"rKXYn1.0.B94.awlZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2989 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 23 Jun 1998, teunis wrote: > On Mon, 22 Jun 1998, Jan Kneschke wrote: > > > On Tue, 23 Jun 1998, teunis wrote: > > > > > Okay - on following email a bit I'm going to wait until the VGA driver is > > > operational.... (that should handle the last cleanup of bugs :) > > > > > > Hopefully this won't take long (I'll start looking at the VGA driver as > > > soon as I can figure out what's crashing my computer -this- time *grr*.) > > > > is the new kgi-driver-guide already out ?? or which specs guide you through > > the black forest of wisdom ?? > > Don't care *grin*. I've been using EvStack-based kernels since last > septembre and have taken a number of cracks at getting a working S3 > driver going :) > > The VGA driver is pretty straightforeward and I'd like to know what's > changed. > > S3 textmode may be completely incompatible but at least I can get an idea > of what will need coding.... I am working on porting the Trio64V+ driver which should reduce your work. And AFAIK the VGA driver *is* operational - I got working textmodes and graphics modes (via testvid) last night. No ModeX though. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Mon Jun 22 21:55:26 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA20657; Mon, 22 Jun 1998 21:55:21 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA10015; Mon, 22 Jun 1998 21:56:34 -0700 (PDT) Resent-Date: Mon, 22 Jun 1998 21:56:34 -0700 (PDT) From: Andrew Apted Message-ID: <19980623144514.00989@ajax.netspace.net.au> Date: Tue, 23 Jun 1998 14:45:14 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi issues: alpha Reply-To: ggi-develop@eskimo.com References: <199806221444.QAA03988@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806221444.QAA03988@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Mon, Jun 22, 1998 at 04:44:21PM +0200 Resent-Message-ID: <"3pmSi.0.HS2.-LpZr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2990 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann writes: > One question remains: > Do we want to change ggi_color from rgb to rgba? > > This > - avoids having a separate rgba color somewhere else > - makes ggi_color properly aligned (4 shorts) > - probably makes the alpha value range 0..0xffff as the rgb value range? I vote Yes. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Mon Jun 22 22:50:42 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA20672; Mon, 22 Jun 1998 22:50:40 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA24010; Mon, 22 Jun 1998 22:46:29 -0700 Resent-Date: Mon, 22 Jun 1998 22:46:29 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: libggi issues: alpha To: ggi-develop@eskimo.com Date: Tue, 23 Jun 1998 00:20:29 +0200 (MET DST) In-Reply-To: <199806221444.QAA03988@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at Jun 22, 98 04:44:21 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"pmbgJ3.0._s5.q4qZr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2991 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > For alpha, there seems to be agreement that the base libggi will not > support alpha-value-aware graphic primitives. Yes. Too much effort for too few uses. > One question remains: > Do we want to change ggi_color from rgb to rgba? I'd say yes, because: > - avoids having a separate rgba color somewhere else well ... minor candy ... > - makes ggi_color properly aligned (4 shorts) Yes. I think this is quite a plus. E.g. when copying ranges of ggi_colors around ... > - probably makes the alpha value range 0..0xffff as the rgb value range? Yes. Sets a reasonable "default" avoiding that something comes up with 8 bit and needs expansion later :-). Other opinions ? CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 23 01:47:44 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA20864; Tue, 23 Jun 1998 01:47:41 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA17726; Tue, 23 Jun 1998 01:44:08 -0700 Resent-Date: Tue, 23 Jun 1998 01:44:08 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <358F6ADE.F053ECE5@e.kth.se> Date: Tue, 23 Jun 1998 10:44:14 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: I don't understand football rules... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"fcZFN2.0.mK4.NhsZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2992 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Rodolphe Ortalo wrote: > > ...and helicopters scouting in the town sky at midnight, looking > for hords of wandering hooligans. Well, I do understand football, and to some extent helicopters, but for hooligans I haven't got a clue. Have you tried converting them to EvStacks? //Marcus From ggi-develop-request@eskimo.com Tue Jun 23 01:53:24 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA20876; Tue, 23 Jun 1998 01:53:22 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA29306; Tue, 23 Jun 1998 01:47:41 -0700 (PDT) Resent-Date: Tue, 23 Jun 1998 01:47:41 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <358F69F0.318FCC41@e.kth.se> Date: Tue, 23 Jun 1998 10:40:16 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: core@suntech.fr, ggi-develop@eskimo.com Subject: Re: CVS mirrors and guest access. References: <199806222241.AAA08752@orb.suntech.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-vNfA.0.n97.hksZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2993 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Emmanuel Marty wrote: > >Could we please resolve this issue so we can use CVS for > >what it was meant for - development. > > Well, I have setup the repository because development was stalled > without it and I thought it would help, but if you have a better host > for it and want to administer the whole thing, I'll merrily move it > there and care about other things. I'm sorry if I was a bit harsh yesterday - I was tired and really needed to get some sleep before todays work. So I just got annoyed when I couldn't commit the changes I'd been hacking on for the last four hours. I'm very grateful that we finally got a working CVS repository again and didn't mean to blame you for anything. //Marcus From ggi-develop-request@eskimo.com Tue Jun 23 01:57:04 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA20889; Tue, 23 Jun 1998 01:56:57 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA17969; Tue, 23 Jun 1998 01:49:20 -0700 Resent-Date: Tue, 23 Jun 1998 01:49:20 -0700 From: Hartmut Niemann Message-Id: <199806230835.KAA19979@cip8.e-technik.uni-erlangen.de> Subject: Re: Move gamma functions to misc ? To: andreas.beck@ggi-project.org Date: Tue, 23 Jun 1998 10:35:52 +0200 (MESZ) Cc: ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jun 19, 98 08:33:37 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"p-qc81.0.aO4.FmsZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2994 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Hi ! > > Should we move > > int ggiGetGamma(ggi_visual_t vis,ggi_float *r,ggi_float *g,ggi_float *b); > int ggiSetGamma(ggi_visual_t vis,ggi_float r,ggi_float g,ggi_float b); > > int ggiGetGammaMap(ggi_visual_t vis,int s,int len,ggi_color *gammamap); > int ggiSetGammaMap(ggi_visual_t vis,int s,int len,ggi_color *gammamap); > > to the "misc" extension ? > > It can be done generically there (i.e. every target would support it then, > as soon as it is linked to libggimisc), by just having the default behaviour > override (un)MapColor and friends. > > On targets that support gamma mapping in HW (like some KGI drivers), this > could still be used ... > > So should we move it over or keep it in LibGGI ? > > No demo seems to use it, so we could just move it over - right ? > > CU,Andy > > -- > = Andreas Beck | Email : = > > Move it to misc. Hartmut -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Tue Jun 23 01:57:14 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA20894; Tue, 23 Jun 1998 01:57:12 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA18009; Tue, 23 Jun 1998 01:49:27 -0700 Resent-Date: Tue, 23 Jun 1998 01:49:27 -0700 From: Hartmut Niemann Message-Id: <199806230745.JAA12589@cip8.e-technik.uni-erlangen.de> Subject: Re: I don't understand football rules... To: ggi-develop@eskimo.com Date: Tue, 23 Jun 1998 09:45:44 +0200 (MESZ) In-Reply-To: from "Jan Kneschke" at Jun 22, 98 11:56:54 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"SgTQk2.0.GP4.MmsZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2995 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Maybe all hooligans who are convicted of throwing something heavier than an empty plastic cup should be sentenced to walk home on foot ... British hooligans: foot and rowing boat. Hartmut -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Tue Jun 23 04:42:25 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA21029; Tue, 23 Jun 1998 04:42:23 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id EAA11928; Tue, 23 Jun 1998 04:27:49 -0700 (PDT) Resent-Date: Tue, 23 Jun 1998 04:27:49 -0700 (PDT) Sender: mee@daimi.aau.dk Message-ID: <358F8F7F.EE77CE38@daimi.aau.dk> Date: Tue, 23 Jun 1998 13:20:31 +0200 From: Martin Eli Erhardsen X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX64 6.4 IP30) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: degas vga driver now working! References: <19980621011839.10828@3e8.com> <358CF19D.38D7B1B9@daimi.aau.dk> <19980621113817.13400@3e8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"WSwPO3.0.Ew2.p4vZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2996 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jim Ursetto wrote: > > OK. Any call to set a mode (other than initial insertion) isn't working > right now, because kgi complains that the mode is already set. I haven't > looked too deep yet but it may be that the mode isn't being released, or > it's trying to acquire the wrong mode. But definitely take a look at the > initial mode set. > I have got the driver to set 320x200x8, so it definitely works, but when I try to use the keyboard nothing happens. I have added some code for GGI_AUTO, and I'll probably try the other monitor drivers, and maybe get the VGA driver to suggest a lower graphmode when appropriate. From ggi-develop-request@eskimo.com Tue Jun 23 06:36:10 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA21122; Tue, 23 Jun 1998 06:36:07 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA21777; Tue, 23 Jun 1998 06:28:08 -0700 Resent-Date: Tue, 23 Jun 1998 06:28:08 -0700 Message-ID: <19980623152637.A408@bengburken.dyn.ml.org> Date: Tue, 23 Jun 1998 15:26:37 +0200 From: =?iso-8859-1?Q?Jonas_Borgstr=F6m?= To: ggi-develop@eskimo.com Subject: Linux selection added.. Reply-To: jonas_b@bitsmart.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.91.1i Resent-Message-ID: <"8TRVB2.0.5K5.drwZr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2997 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all, I have now committed the first version of "selection.c". It will allow tools like gpm to work. You need to recompile the kernel to test it, it also works as a module. But you to recompile the kernel anyway because I have changed some lines in "kgiscroll.c". :-( Don't forget to select "linux selection support" in menuconfig under the ggi section. There is a bug which changes the colors most right column of the screen if you move the mouse to the most right column of the screen. I think it's a bug in kgiscroll.c, but I'm not sure. CU -- -------------------------------------- Jonas Borgström From ggi-develop-request@eskimo.com Tue Jun 23 07:07:57 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA21163; Tue, 23 Jun 1998 07:07:55 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA01152; Tue, 23 Jun 1998 07:01:47 -0700 Resent-Date: Tue, 23 Jun 1998 07:01:47 -0700 From: Hartmut Niemann Message-Id: <199806231401.QAA01330@cip8.e-technik.uni-erlangen.de> Subject: libggi open issues To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Tue, 23 Jun 1998 16:01:37 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"AEbW11.0.pH.ALxZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2998 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! On my list of open issues there are only two remaining. 1) switch-away and switch-back Ther is no solution that looks complete, AFAIK. The only thing that seems clear to me is that the libggi or the kernel WILL NOT save any screen content or palette, and there will be an redraw event or signal on reactivation. 2) graphtypes and specifying the pixel setup The problems 'getbuffer' and 'opotimised memory target' have been reduced to this: the mode struct will be enhaced to include pixel layout information good enough to construct optimal memory visuals, and/or to negotiate buffer layouts. a field ggi_common_plb_setup ggimode.pixelfmt was suggested. I have two questions here: 1 could this pixelfmt and the graphtype (which, actually, contains a subset of the pixelfmt information) be folded into one (64bit) value? This would make things *a lot* easier. 2 How do we need to change graphtype? I like the idea Andrew and Brian suggested, using the graphtype as a bit field, but either solution would have to be cleanded up. So can we have some suggestions about the switchaway-switchback, and is there a possibility to integrate the current graphtype and ggi_common_plb_setup enums into one type? Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Tue Jun 23 07:48:34 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA21214; Tue, 23 Jun 1998 07:48:27 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA00390; Tue, 23 Jun 1998 07:43:18 -0700 (PDT) Resent-Date: Tue, 23 Jun 1998 07:43:18 -0700 (PDT) Date: Tue, 23 Jun 1998 15:35:28 +0100 Message-Id: <199806231435.PAA26555@pcsw104b.ukc.ac.uk> To: KC5TJA Cc: ggi-develop@eskimo.com From: Charles Briscoe-Smith Subject: Re: Debian packages available; here are the patches In-reply-to: Your message of "Mon, 22 Jun 1998 07:26:52 PDT." Resent-Message-ID: <"hwN0a.0.z5.3yxZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/2999 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com In message , KC5TJA writes: >On Mon, 22 Jun 1998, Charles Briscoe-Smith wrote: > >> I've now got some Debian packages of libGGI built, and have put them at >> > >Will this also work with Hamm (Debian 2.0)? I built them on an up-to-date hamm system, so they certainly ought to work there... Generally, any Debian package should work on any Debian system where the dependencies allow it to be installed -- so the libGGI packages should work on any libc6 Debian box. While the bo -> hamm transition requires a somewhat critical, all-at-once upgrade sequence, all future versions of Debian should be fully upwardly-compatible and incrementally upgradable. You should be able to take any package from slink (currently the development version of Debian 2.1) and install it on a 2.0 system without problems. -- Charles Briscoe-Smith White pages entry, with PGP key: PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 From ggi-develop-request@eskimo.com Tue Jun 23 07:54:05 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA21229; Tue, 23 Jun 1998 07:54:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA16467; Tue, 23 Jun 1998 07:47:18 -0700 Resent-Date: Tue, 23 Jun 1998 07:47:18 -0700 To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: libggi open issues Date: 23 Jun 1998 14:50:47 GMT Organization: OnTV Pittsburgh, L.P. Lines: 25 Sender: Jason McMullan Distribution: local Message-ID: <6mofc7$n9o$1@butter.visus.com> References: <6modfu$mhr$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.34 (i586)) Resent-Message-ID: <"saQFd3.0.714.r_xZr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3000 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote with confidence: > 1) switch-away and switch-back > Ther is no solution that looks complete, AFAIK. > The only thing that seems clear to me is that the libggi or the kernel > WILL NOT save any screen content or palette, and there will be an > redraw event or signal on reactivation. Bingo. libGGI (KGI) will get the signals, and translate them into `redraw now' events or callbacks. > I like the idea Andrew and Brian suggested, using the graphtype > as a bit field, but either solution would have to be cleanded up. As do I. Very nice. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Tue Jun 23 08:21:21 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA21239; Tue, 23 Jun 1998 08:21:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA27521; Tue, 23 Jun 1998 08:16:36 -0700 Resent-Date: Tue, 23 Jun 1998 08:16:36 -0700 Sender: paul@os.inf.tu-dresden.de To: ggi-develop@eskimo.com Subject: Re: libggi open issues References: <6modfu$mhr$1@butter.visus.com> <6mofc7$n9o$1@butter.visus.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII From: Torsten Paul Date: 23 Jun 1998 17:16:26 +0200 In-Reply-To: Jason McMullan's message of 23 Jun 1998 14:50:47 GMT Message-ID: <7q7m28up11.fsf@carola.inf.tu-dresden.de> Lines: 20 X-Mailer: Gnus v5.3/Emacs 19.34 Resent-Message-ID: <"ac5po1.0.tj6.KRyZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3001 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jason McMullan writes: > > The only thing that seems clear to me is that the libggi or the kernel > > WILL NOT save any screen content or palette, and there will be an > > redraw event or signal on reactivation. > > Bingo. libGGI (KGI) will get the signals, and translate > them into `redraw now' events or callbacks. > Are those `redraw now' events associated to a region or the whole screen? ciao, Torsten. -- Torsten Paul Es ist leichter, einen Atomkern zu paul@os.inf.tu-dresden.de // spalten als ein Vorurteil. __________________________ooO_(+ +)_Ooo________Albert Einstein_(1879-1955) U From ggi-develop-request@eskimo.com Tue Jun 23 08:30:42 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA21258; Tue, 23 Jun 1998 08:30:40 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA05339; Tue, 23 Jun 1998 08:23:52 -0700 (PDT) Resent-Date: Tue, 23 Jun 1998 08:23:52 -0700 (PDT) Date: Tue, 23 Jun 1998 10:16:30 -0500 (CDT) From: Steven Engelhardt X-Sender: sengelha@eesn24.ews.uiuc.edu To: ggi-develop@eskimo.com Subject: NT port of libggi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"S2Sfm1.0.DJ1.4YyZr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3002 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I would like to express my interest in assisting with the NT port of libggi. Is there a 'project coordinator' as such, or a CVS branch, or an existing framework with which I can work on? I tried reviewing the mailing list archives but I was unable to discern clear answers for these questions. Hope I can help... Thank you, Steven Engelhardt sengelha@uiuc.edu http://www.uiuc.edu/ph/www/sengelha A lost ounce of gold may be found, a lost moment of time never. From ggi-develop-request@eskimo.com Tue Jun 23 10:02:04 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA21287; Tue, 23 Jun 1998 10:02:01 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA04279; Tue, 23 Jun 1998 09:59:03 -0700 Resent-Date: Tue, 23 Jun 1998 09:59:03 -0700 From: Steffen Seeger Message-Id: <199806231658.SAA01278@legrelle.physik.tu-chemnitz.de> Subject: 3Dlabs drivers To: ggi-develop@eskimo.com (GGI GGI) Date: Tue, 23 Jun 1998 18:58:08 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"dGTRr.0.f21.MxzZr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3003 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello, this is just to inform you that I will be allowed to release 3Dlabs driver sources after approval by 3Dlabs. We have to check out the details, but basically I got permission to publish them. The time frame could not have been better. So, have a good beer, Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- ------------- The GGI Project: http://www.ggi-project.org ------------- From ggi-develop-request@eskimo.com Tue Jun 23 10:41:37 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA21318; Tue, 23 Jun 1998 10:41:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA17794; Tue, 23 Jun 1998 10:36:52 -0700 Resent-Date: Tue, 23 Jun 1998 10:36:52 -0700 Date: Tue, 23 Jun 1998 18:36:42 +0100 (BST) From: David McCanney <9504506m@udcf.gla.ac.uk> X-Sender: 9504506m@lenzie.cent.gla.ac.uk To: ggi-develop@eskimo.com Subject: Re: I don't understand football rules... In-Reply-To: <199806230745.JAA12589@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"yW7ki1.0.pL4.pU-Zr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3004 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 23 Jun 1998, Hartmut Niemann wrote: > Maybe all hooligans who are convicted of throwing something > heavier than an empty plastic cup should be sentenced to walk > home on foot ... > British hooligans: foot and rowing boat. Whoah there! _English_ hooligans. -- David McCanney (A Scot :-) ) email: D.McCanney@udcf.gla.ac.uk #include From ggi-develop-request@eskimo.com Tue Jun 23 11:16:18 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA21349; Tue, 23 Jun 1998 11:16:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA30108; Tue, 23 Jun 1998 11:12:50 -0700 Resent-Date: Tue, 23 Jun 1998 11:12:50 -0700 Date: Tue, 23 Jun 1998 14:12:39 -0400 (EDT) From: Jonathan C Day X-Sender: j.c.day@express.larc.nasa.gov To: ggi-develop@eskimo.com Subject: Obtaining development versions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"G5XtY2.0.0M7.V0_Zr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3006 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi, There was an earlier message about public CVS access to the development branch being switched from cvs.ggi-project.org to another server, in the US (anoncvs.us.ggi-project.org). I'm having problems accessing it & am wondering if there's a problem with the server, or if the original message missed some information. The errors I'm getting are: cvs checkout: warning: unrecognized response `cvs: setgroups: Operation not permitted' from cvs server protocol error: directory '/projects/ggi/cvsdevel/degas' not within root '/cvsdevel' Apologies if this is an "obvious" one Jonathan From ggi-develop-request@eskimo.com Tue Jun 23 11:23:47 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA21362; Tue, 23 Jun 1998 11:23:44 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA26952; Tue, 23 Jun 1998 11:05:33 -0700 Resent-Date: Tue, 23 Jun 1998 11:05:33 -0700 Message-Id: <199806231805.UAA00208@zafir.e.kth.se> To: ggi-develop@eskimo.com cc: sengelha@uiuc.edu Subject: Re: NT port of libggi In-reply-to: Your message of "Tue, 23 Jun 1998 10:16:30 CDT." Date: Tue, 23 Jun 1998 20:05:26 +0200 From: Marcus Sundberg Resent-Message-ID: <"IIpt8.0.xa6.hv-Zr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3005 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Steven Engelhardt wrote: > > I would like to express my interest in assisting with the NT port > of libggi. Is there a 'project coordinator' as such, or a CVS branch, or > an existing framework with which I can work on? I tried reviewing the > mailing list archives but I was unable to discern clear answers for these > questions. Hope I can help... Andreas Beck is the project leader/coordinator responsible for libggi as a whole. If you mean a coordinator for the NT port there's not an official one. But as I am currently the only one working on this, and I also know libggi pretty well I suppose I could take that task. As for the existing framework/CVS branch it's all in the regular CVS devel-repository. The core libggi is mostly pure ANSI C and doesn't require any changes to compile on win32. The only non-portable part of libggi is the dl.c file, in which dlopen()/dlsym()/dlclose() will have to be replaced with their equivalents under other OSes. In the win32 case this is LoadLibrary()/GetProcAddress()/FreeLibrary(). I have allready done this, but I'm not sure it will work in all cases so I haven't commited it yet. Currently I'm working on getting a fully working win32 cross-development system running on my Linux box, and I hope to have this done by tonight or tomorrow. (I allready have such a system running, and it's available from http://www.stacken.kth.se/~mackan/ggi/ but it only support a small part of win32, notably DirectX is missing) So basicly the things that are to be done for the win32 port are: * Write DirectX target - if noone takes this before I have mingw32 properly setup I'll start hacking on it. * Write GDI target * Write makefiles/building-scripts for native win32 compilers * Make a nice installation-system for binary win32 distributions Are there any freely available installers a'la installshield ? * Port other targets that can be of interrest: + Glide + VNC + Xlib (I'll probably give this a try) * Exotic stuff: + Port KGI to win32 - any takers ? *grin* + Write a DirectX wrapper (Stefan?) + Write a GDI wrapper - would be cool to run with the Xlib target. //Marcus From ggi-develop-request@eskimo.com Tue Jun 23 11:28:34 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA21373; Tue, 23 Jun 1998 11:28:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA02657; Tue, 23 Jun 1998 11:28:41 -0700 Resent-Date: Tue, 23 Jun 1998 11:28:41 -0700 To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: libggi open issues Date: 23 Jun 1998 18:32:09 GMT Organization: OnTV Pittsburgh, L.P. Lines: 26 Sender: Jason McMullan Distribution: local Message-ID: <6mosb9$sal$1@butter.visus.com> References: <6moifd$oqb$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.34 (i586)) Resent-Message-ID: <"D4d3y2.0.Ff.NF_Zr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3007 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com In article <6moifd$oqb$1@butter.visus.com> you wrote: > Jason McMullan writes: >> > The only thing that seems clear to me is that the libggi or the kernel >> > WILL NOT save any screen content or palette, and there will be an >> > redraw event or signal on reactivation. >> >> Bingo. libGGI (KGI) will get the signals, and translate >> them into `redraw now' events or callbacks. >> > Are those `redraw now' events associated to a region or the whole screen? The KGI signals will imply the whole screen, but the libGGI events should be able to specify a rectangular region. (in the KGI case, the entire screen, under X just what was exposed, etc). BeckA, how's that libGGI clipping coming along? -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Tue Jun 23 13:23:24 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA21482; Tue, 23 Jun 1998 13:23:20 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA03636; Tue, 23 Jun 1998 13:18:37 -0700 Resent-Date: Tue, 23 Jun 1998 13:18:37 -0700 Message-Id: <199806232018.WAA14614@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: svgalib-misc now works Date: Tue, 23 Jun 1998 22:18:28 +0200 From: Marcus Sundberg Resent-Message-ID: <"DSBud2.0.cu.Ss0ar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3008 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I have know fixed the svgalib-misc target to work, including the splitline feature. But there's one bug somwhere which causes a sig11 in GGIdlclose. According to gdb it is called with vis = 0x1, but the x-misc target works fine so I can't figure out this behaviour. Any ideas? I've also removed all traces of splitline and raypos from lib/libggi/include, so most targets will have to be fixed. (They should go into the misc extension if anyone didn't get that yet.) Now, could anyone please post a list of all the API- changes/decisions that are decided on, so we can put those in before thursday. This is a high priority! It won't be of much use if we release a "stable" snapshot by the end of this month, and then the API is completely changed by next month. Actually I don't think there's much point in releasing a "stable" snapshot until all non-compatible API-changes are done. //Marcus From ggi-develop-request@eskimo.com Tue Jun 23 14:35:03 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA21509; Tue, 23 Jun 1998 14:34:57 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA12993; Tue, 23 Jun 1998 14:30:31 -0700 (PDT) Resent-Date: Tue, 23 Jun 1998 14:30:31 -0700 (PDT) Date: Tue, 23 Jun 1998 14:21:20 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: Online source tree is still Dali Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"KyFrl1.0.tA3.qv1ar"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3009 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I just noticed this. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Tue Jun 23 15:08:48 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA21572; Tue, 23 Jun 1998 15:08:43 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA21480; Tue, 23 Jun 1998 15:08:11 -0700 Resent-Date: Tue, 23 Jun 1998 15:08:11 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: I don't understand football rules... To: ggi-develop@eskimo.com Date: Tue, 23 Jun 1998 19:31:21 +0200 (MET DST) In-Reply-To: <358F6ADE.F053ECE5@e.kth.se> from "Marcus Sundberg" at Jun 23, 98 10:44:14 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"vFKAu.0.uE5.AT2ar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3010 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > ...and helicopters scouting in the town sky at midnight, looking > > for hords of wandering hooligans. > Well, I do understand football, and to some extent helicopters, > but for hooligans I haven't got a clue. > Have you tried converting them to EvStacks? I'd rather suggest to pipe those directly to /dev/null. Another alternative which is unfortunately not compatible with law and public health care would be putting all of them in a big arena, equipping them well and closing the door. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 23 15:55:01 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA21639; Tue, 23 Jun 1998 15:54:58 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA04565; Tue, 23 Jun 1998 15:55:57 -0700 Resent-Date: Tue, 23 Jun 1998 15:55:57 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Alpha in ggi_color ... To: ggi-develop@eskimo.com (mailing list GGI) Date: Tue, 23 Jun 1998 19:46:00 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"O15AU1.0.A71.y93ar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3011 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com HI folks ! O.K. - who does the alpha change, then ? Whoever it is: Take care ! E.g. IBM/clut.inc assumes that the struct is in rrggbbrrggbb format ... Make sure you catch _all_ those nasty places ! CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 23 15:55:15 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA21644; Tue, 23 Jun 1998 15:55:12 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA04645; Tue, 23 Jun 1998 15:56:05 -0700 Resent-Date: Tue, 23 Jun 1998 15:56:05 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Mesa, GLUT and fun ... To: ggi-develop@eskimo.com (mailing list GGI) Date: Wed, 24 Jun 1998 00:07:10 +0200 (MET DST) In-Reply-To: from "Uwe Maurer" at Jun 22, 98 06:01:22 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"o0Pcy2.0.H81.3A3ar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3012 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Hi ! > The new ggimesa-patch (including glut for ggi) is at > http://home.t-online.de/home/uwe_maurer/ggimesa.htm VERY GOOD JOB, Uwe ! Hope this allows anyone to easily install MesaGGI. Ann.: DO READ Uwe's README and _follow_ it. I should have done ... would have saved me five minutes of figuring out what went wrong :-) ... > Keyboard and Mouse-input don't work with the new libggi. > (I have only tested it with display-X) It seems they do when using your "special" demos. The GLUT demos don't get it right it seems. Well ... Now for the fun part ... ask anyone, if he can do this with a mere setting of a envvar : begin 644 Mesatileggi.gif M1TE&.#=A3`'@`/<`````````$```&```(```*```,```.```0```2```4``` M6```:```H``$0``$2``$4``$6``$8``$:``$<``$>``$@``$B``$D``$F``0 M"``<^``H"``L"``P"``PF``T"``X"``\"`!`$`!$$`!($`!,$`!0$`!4$`!8 M$`!<$`!<&`!@&`!D&`!H&`!L&`!P&`!T&`!X&`!\&`!\(`"`(`"$(`"((`", M(`"0(`"4(`"8(`"8R`"<(`"@*`"D*`"H*`"L*`"P*`#`,`@$.`@(,`@(.`@( M4`@(6`@(8`@(:`@(<`@(>`@(@`@(B`@,0`@,2`@,8`@,:`@,>`@,@`@,D!`0 M$!`02!`04!`06!`08!`0:!`0>!`48!`4:!`4!`4@!`4D!`8,!@(2!@0 M2!@42!@4>!@88!@8!@8@!@8B!@<4!@<8!@<!@"`@@"`@B"`@F"`@H"`@J"`D:"`D<"`D@"`DL"`D MN"`DP"!08"@$`"@4."@D:"@HP"@HR"@HT"@HV"@LV#`$`#`P,#`P\#!D8#@$ M`#@(`#@@&#@H(#@T(#CX,$`(`$!8N$"@P$@(`$A(V%`(`%!$>%!04%!0\%!0 M^%!44%!4^%@(`%@,`%A4X%A<^%C@^&`,`&!$4&!D\&!D^&@,`&A("`^("$^(@0`(B( M^(B8L)`0`)"0^)@`8)@0`)@4`)B4Z)B8F)B<^)C,R*`4`*"@^*"DH*@``*@4 M`*AT4*BH^*BL^+`4`+"PL+"X^+#`V+BXN+B\^,`8`,#4X,B88,C$^,C,^,C\ M^-`P0-"TB-@``-B$2-B02-BHD-C0Z-C8V-C/C0H/CX^/C\`/C\^"P`````3`'@```(_@`)"1Q(L*#!@P@3*ES(L*'# MAQ`C,@0@L:+%BQ@S:JQXJJ/'CR`_$@I)LJ3)DRA3JES)LJ7'D2Y/$:(84V;- MFSASZJP)T^7(C4"#"AT:5"9-HDB3*ETJT&;/E4]W2IU*-6I*JRA_'O5)M:O7 MG%A/AC7YTR;+IE_3JLTZEB1:J%K+GFV[MF[7MRKQ7BT+,Y/?OX`!HPU,N+#A MPX@3*U[,V/#@Q8\5-YTIEW'DQI@S:][<^#)BSX/CPS+4+)R.'+KMCJ2-_E;>#=[T].SHMV,O;)P[YN6!X0OF6QYW?9?'\1Z-=D6YT2GH*]\:?>?K'YIQZ`Z5%('H/V89A8<_<]UR%F`(;H MX(.J^6?A=B=F"!A(A,SW828:'IB;=\K1N)B(AE%HW6LFCNA:BAORQJ*+,?I5 M)(<*9I6)@3G^QII^3SX(X81.^B@@;EFL&1R&.5/[;'9FA9'CCGAPINR:5XHQ4I MV)TO,J:GE'X&"BB54$89*'&>,:BHC(@N>6AECA8(::DW:J=FIF@"NBJ9_E:V M662BA\;HZ:@)PFCGF,6I>BFK3?[W*ZRP@48KG"L:ZB*I"YT*VWD"OKJ:J\-. M&^"`77X*JJVF+DI9H\WRVFMZ4DI[;8G57GME=XAJZVRRRH(ZGHK/FMA?B>M. MR^>(DVY6F[N7R430LKE>2-R3ON)+::_[MJJN9O]^>9_``RVK&[WK9:PQIW@B M:]^W'2^*ZL8DEUQCI!*/;''(VYKL\LLGJRQR>""C7"O,.,/,Y,YT+ICSSR7S M;#/!\\H*]-$9"RVSO!<;C?336`X],WDU+_TNU%B_Q_+5;?(%$<5,A9T4V`V1 MS1"C/WTM]MI(F;V0VPK!S?;<=*]-4=UXYQVV_E&^H::!!JG]W??@A!=NN-^` M'Q[XWXDC+KCCC3\BN>2I36[YY9AGKCGEBA,^8^>@AR[ZZ*27;OKI@_-%..,` ML(ZZZ8\?_OCLB<<>.P"3=[[Y[IJ?_OGKP`N_.FW M(]_XXJM/SSGH1&3/^^ZH_U[\]^"'+WYJQ_?=O."T(VYX].8W[QO[S$^OOO2O M9T_$]KW[CO;X_/?O/^GE>Q_@!DC`Y[4N>NZ#G?S:Y[@#-G!^J+,?_B[W.N_] M[X(8Q&``XT<]^#TP?:7SH`#G!T('`D^"$WP$\"R8P1:Z\'L;I!X)77=`&M;0 MA*(38?L&N#@>UG"!_J5#(?Y6N+\7&O&(1-0*$I=8/^UM+W@L9*(4I^B;&%*1 M-4),(07!E\7,"2^*5PPC$JTH1@`X48N6&U\7MYC$HY3QC6-T"AS[=D8T]J^. MF/MB$>?(QPN2\8UXG.`=`YD[*.ZQCX@3\M^L]^C%_ENG M/--9/'N.SI\C9*#B[!E`?,,*/I8MU!U+E"9RN0@#@=J0V).M)CJHV$" M\5F]C`*QA`*=)_Q$2L_.D52&"16H-F6(TL0=[Y@:9>A!IQ?3A1;3H=4T*#FW M&?HD*4VG"L%G!K6@SFQF58&J M50<>U9T@C:=.][F^AS)UHB6TW0-1PU'ZH3.H.%VJ4]LYSGS"]:Y;S6LT4VI3 M$YH3KV3U:52SFE+Z!7:P M!K2L0XVM3+UZTMZ^7/A$Y[@!">@ M,8V&:RMSQSO;49;QNNA5Q"VUN]TG?%>%BA,O>9D[71>F%[N\,V)[MZO)C"*R`XP?DM78,='$L(]P_! MZ'TO?#.(A2N8&,&;LZ8;./#\8B M+B0&N<"%+-08"SG6L7EY3%X?BP_(01[Q!;O0!2)S`H3&4N9%?),^'R_GR='#XPSQB#:/#"F*F<9#2K>GB*,K1!E#*;ASW'V MPIGM?.?QLKG-%XZRE/FG!C7\.0UH&+3^:%OH8![ZR7SNL__@L(9&.WJ]A*ZT MI?,=-PX'2C,QQJ4=1]A;<1?9UE\?."#L(?=WU=26MF69/:!GLVK;O*$ MBWCIZ5T$*Q>!WJZSFC4I'GC8Q1Y&HXOOZN_E>MK77N"4%X[=OAPZW5]H]_#A M_>G75?LJO]Z_#0^^A87_WN&?KNG&"_[Q&8P\\4Y.^:?_S_&8]Z/-PSCYSDN< M?Z`/O?\T/SRS:]&6I@>OY6>N>B.R?GA$(';.4TGYSU^^]K-?\AQSSW@S0C+V M0D;][X&OR-&+L93LAB3L.^][VC,_\\Y__O1E_H_%X[]^^YEKAOB5;_WKBY[L M?21DX:0_P6A$P_C@OUPL8B'^\8,O]>:'8?8!R?W!L7][[A>`O&`PW-[2`2!FZ,)$BB!\5>! M%GB!!SA)<\>!YR=\#@:"FJ,)(CB"`<@[)UB`UX"!;81^+%A]+@A@,(@Y,CB$ M[G<-1FB$)7B#L7"$3*AE"=B#][=_RQ6$ES.$,LB$3+@[2HB%1M@WP``,@?>$ M4%@\'O@_]M=]`VB%5\B%UP!^6\B&OO&%'H(2!&8B&%*B&FL"& M;0A[2KB$@,@:8C+2XC,PXBGWTC+FXB]N(.T)(C:N8B==HA-EXB%PX6ROHC1HHA7`DCN.( M@5CH&[YHA>N8@X/8C^WXA86HC/(87_3X1O;XC,U0B*FQCT/8C^)W@_V(C=E( MC`19D(K8C.&8D(4`C!+HD!.9@Q&)@P!YC,3H1AI9/$"PDBP)!/E7AN'#_I&Y MZ)$?B8[7J(>O>(TF>9(7&3HD0`(MV9+7!Y/@(Y,=29,!:),AN93&N([PF)+# M\Y,_&90L"7Q$^3U&N8XT^)!+V95'J(U.B9+@2#Q2*954N9*$@P,T=Y7%DY5: MN95>&9>=V(_DLS][.#YEF9=GZ9*L@0-^J98%QY;$XY9O.8)Q>9@4.9&HT0PS M$HGADY>0N9>H\9>466^".3R$69B(N9E+67^-:8K@`YFBN9>469J`Z6J723C# M,#J9R9FN^9HBR9AHLXO?(YJV29JF^9>H>9#^,PR^20RATYJP.9Q>B8&?29O" M8YO*"91GF9NZ66BIR1J^.9V_V3G"29S8"9&>_CF;T7B7A.,#H+.Q+">A2-^,IF=\!F2QLF=Y'@-A>,#^-DYXBF>9RD$SNF77':>Z3F@ MP[">P,D:D)B0\;F@-[F=(%.?Y>@;^#FAX&DX^[F?0I"A&OJ?S\EAYUD(!*J> M!KJ8I6B/#'JB7*B'QUE_#)D:%/JBA'.A&*JA&6]JE72I^C:F8 M8TJF9?JB+9FFD+FF_C7:IC1J:%:JH[E(G==HIZ6(IY`Z(WS:IQO@IW\ZH8$J MJ"1`J(5JHVM*7XE:E',Z#!,)I'H(J9&*-G3)&I7:JI=*H4$IJ)SJGY[ZJ*K2RIK=OJG-[ZK6-Y M01Q)KO;*AN:ZB>B:KL+ZJAD:J[:YK=Q*F=N*J.`:KD)ZKPIKA/GZCH3#K^I: MIE$*L'DIL#50F@)KL/-*K^*ZL/?:L$U8.!";KDM*J%19E@*;H35PL6Y:_K`: M>XM,Y*P>.ZX@>X02N*\CVZ_X.:MG^9,I^[,:6J4'B[#/.+/V6K/70(/O1ZTY M*ZPIVY]`^[-!\+)7-`P=:[3/BK1*ZWXNVK35^K,M&;5`&P1D.[7+NK'_,YU7 MB[6I"C*`N+4WBY]>Z[1/"P1B.[9E2[9=-K3BDYX)R[:^JJIL"+<22*%SNP%W MF[BSFK>,VV&A"CK>>3@ARJ6`V[9'88F$6[@3ZK6*V[E1RKB@"TJ15PNUT)W2 M.;E'6;E=JK5;RX4OVK2>&[N@.[N55'BD2[K=67\\:K6JBZ=(F[1%"(Q+FK.Q MZ[FSR[@9FDBV>[NEF[OBM[N]2Z2_.Y%E"K'%_FN\H*NLTO6XA\.\M^N\STN@ MT2N]@KN9E\JOUZNX9>NR!L>WBN.]W@N^=#J^0SJ]$QD$YTNWZ;N_08M(1@>_ M\>N\C$J_]5N^FTFV^5NI_+O`R=N^:"LZ`,R\6-B=I$K`!>RVG,FX"D" M6NS$&NP#4:RXH71[E&O%1\O$ZZC%:.P"7+R^7WRWCNN^K#G&9`RM/WR$:9S& ML]O&./S&#XPZLQQW,:W!,.G\,R+YKQH!(R(4DZ MRI5+_@,W M4`,T(`,Q8,XM$,W3',Q[/,6)/#B9V]#P2](E[2)^P,3V@-"3=1&_<\+G,-^_=>!+=B5*SIKV]-8_)HZH`.^++8_ M,-ITS=4Y<-6?=G!B[6*O-G$:=*`^-F?G=6*"P2CS=@^L-5= M?0,<3-FLC1JN[=I0W;NE4Z_AC-@3B=O0#=2[_LW;O4W7.C#G^VY.;"2U>W%V+W:VMTYW-W=L4V_I_.>N^SYGV] M/["245S6[PW?\3T*2ES?S,W9FQR7^EW>A@S&B%SS']BW>";Z4"P[= M#0ZT<`KA$7[<,/PZC5#AM8W?3)CAN+WA*8NC3@T`W$W"P-,((Q[>L"G(*)[B M*IZQ`7;$KAWBKR,)D3#CACV<@ERI*)[C.K[C+1[A,`X\EP#D,D[;G%G'PKK@ M2)[D'1[@I$/@%@P\,G@)EQ#D0E[54V[BZ/G]-V*B#"I+^UY4^Z/<]WNOHF\7\ MZ83*XHY.."#.MJ_#"KANZI,>Z)9^":M^X2')Z:V:LMJ3#,GPXC,+ M//.7ZZ?.Z[](YYI^F)U>[%%Z`MJN[?*LXL<./LJN[!*^L*]3"[3P[*R@ZZ@^ M[27.ZEW9Z32Z[?*^[=V^X7N.[*,3[OH^[O>*.KB`"^:.[ND>[;]^Z)LY[P@_ M[TA^[\.C[PZ_[+7>[Z;3"_\.\+50@-!."LWM[EZ9\!Z_\*$./`__\!%O_J^F M`PR]D/+_3KKG'@O0OO'`;NT>C_!\7>^@KM!./?(ZW^,*>_(HK_(KW_*X?M@< MOY0S3_.'G!HVK[TX#^$Z__3+[K&DXYMRF/(4O_(7/XPP;_"(>?0*3]9]L_3] MV^CX3CA0#_7-'CK)0`S3^8567_$LK\HF;HE>+^])WS>QSO"D<_9HG_:*H^]L M3_5N#_0`+_=%KYAUK^W$+O9Y_["'^NV*S/2K^RD[ANEZ/"8/_B]@*(173A'#_JAS_2[YF.Y*/F]2PS) M@($!N(N`W_8""?LF#CH?/ZN*SJF!&:K/V/?1_CL,O5]_O[_ZX1[XPP`,Y,OY MI9/PR)_\MG_[S-_\DV_!T._[TZ^'EU_!FLSU#FLZ=L^IQ*O\R^^^]NCP/5S^ MYA\-U(_ZC7SXK[/M`"%$X$"!``QN0)@0(4&&!AT^A!A1XD2*%2U>Q!B1T*F- MA#)&+!129+)DUTR>1)E2Y4J6+5V^3#DL63.:-*/=K)FS64F8/7V:[`B@8\N/ M%D\P+/A084*D`XL^A1I5JD:.'*>*%/E3ZU:N+(G-K'DSFLYF7V M>PE?QISYLF%"B"-?_F3J]O-HTI/I9M6<6O5JEYQ=DK:XL"%LVH]-GR[$6O=N MU:X]UY:X&/APNK=/\T:>O+!5M;^)/X=>U_AQY=6MO_3].OIV[E"G1[X>WGIV M[=W-GY?X_7$O]NTMBX>_F?GAGNCMVU=OM_W^7JCC_U_.H^9>NJ_`[O*CBS_^ M0@*P0;/((]!`"8E#D"T%%M2E55`\8S55$[E9-!6 M2W'-5=-=>471UPU=13588?F$K%=C4WPU664?'?8C9UUB)=MBGUTMVEFG);1: M:UO*MMQRN=W-6U+!S5/N6677X899I1+EKAFFV_&.><6=>:Y9Y]]`@X(`#L` ` end CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 23 16:16:05 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA21672; Tue, 23 Jun 1998 16:16:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA11927; Tue, 23 Jun 1998 16:16:26 -0700 Resent-Date: Tue, 23 Jun 1998 16:16:26 -0700 Date: Tue, 23 Jun 1998 16:15:55 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: 3Dlabs drivers In-Reply-To: <199806231658.SAA01278@legrelle.physik.tu-chemnitz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"USTOu1.0.Aw2.9T3ar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3013 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 23 Jun 1998, Steffen Seeger wrote: > Hello, > > this is just to inform you that I will be allowed to release 3Dlabs > driver sources after approval by 3Dlabs. We have to check out the > details, but basically I got permission to publish them. Good news indeed! Full 3D accel support too? > The time frame could not have been better. Yes. Now if 3Dfx and Riva would also allow this.... Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Tue Jun 23 16:25:16 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA21677; Tue, 23 Jun 1998 16:25:10 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA14108; Tue, 23 Jun 1998 16:24:47 -0700 Resent-Date: Tue, 23 Jun 1998 16:24:47 -0700 Sender: injector@clubneon.dyn.ml.org Message-ID: <359038FA.387649DC@stu.ac.cc.md.us> Date: Tue, 23 Jun 1998 19:23:38 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Online source tree is still Dali References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BDQDm.0.FS3.-a3ar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3014 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon M. Taylor wrote: > > I just noticed this. Wow something on the website that isn't my fault lately. It is on the freiburg.linux.de server. Anyway if anyone would like I could keep an unpacked copy of the stable and devel trees on the main web site too. Anyone? If you have noticed the web site updates lagged for the last 2 weeks, this is my fault. We have had sort of a family crisis at my house and I haven't felt much like working on the page (or anything else). But I'm back now. For the rest of the week I'll be going through all the mailing list and personal mails to me to get everything back up to date. I'll have a slightly overhauled page up this weekend. Thanks for understanding. On the overhaul note: Would anyone like to see a little more flash on the page? I'd promiss to keep it professional looking, fast loading, and probally make it even better looking in Lynx (at least the couple of table based pages). Oh one last thing: Could anyone help me get a CVS server running on Synergy to help maintain the mirrors? I know the user side of CVS okay, but nothing about the server side. -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Tue Jun 23 16:26:01 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA21682; Tue, 23 Jun 1998 16:25:59 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA15199; Tue, 23 Jun 1998 16:27:11 -0700 Resent-Date: Tue, 23 Jun 1998 16:27:11 -0700 Date: Tue, 23 Jun 1998 16:26:41 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: Web page stuff Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cAx6A3.0.Lj3.Ed3ar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3015 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com There are some web page issues that should be resolved: - The online browseable source tree is still from Dali. - The Malaysian mirror seems to be offline and the UK and US mirrors are out of date. - The note on scrdrv.tgz still says that there is some stuff in there that has yet to be ported to Degas, which AFAIK is no longer correct...Andy? Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Tue Jun 23 16:29:07 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA21687; Tue, 23 Jun 1998 16:29:03 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA24570; Tue, 23 Jun 1998 16:33:25 -0700 (PDT) Resent-Date: Tue, 23 Jun 1998 16:33:25 -0700 (PDT) Date: Tue, 23 Jun 1998 16:26:05 -0700 (PDT) From: Dan Hollis To: GGI GGI Subject: Re: 3Dlabs drivers In-Reply-To: <199806231658.SAA01278@legrelle.physik.tu-chemnitz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ZeX252.0.o_5.4j3ar"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3016 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 23 Jun 1998, Steffen Seeger wrote: > this is just to inform you that I will be allowed to release 3Dlabs > driver sources after approval by 3Dlabs. We have to check out the > details, but basically I got permission to publish them. This is the Glint stuff, yes? -Dan From ggi-develop-request@eskimo.com Wed Jun 24 00:05:15 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA22064; Wed, 24 Jun 1998 00:05:13 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA19180; Wed, 24 Jun 1998 00:01:13 -0700 (PDT) Resent-Date: Wed, 24 Jun 1998 00:01:13 -0700 (PDT) From: Andrew Apted Message-ID: <19980624164944.31638@ajax.netspace.net.au> Date: Wed, 24 Jun 1998 16:49:44 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi open issues Reply-To: ggi-develop@eskimo.com References: <199806231401.QAA01330@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806231401.QAA01330@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Tue, Jun 23, 1998 at 04:01:37PM +0200 Resent-Message-ID: <"qRdi82.0.ah4.uGAar"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3017 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut writes: > Hi! > On my list of open issues there are only two remaining. > > 1) switch-away and switch-back > Ther is no solution that looks complete, AFAIK. > > The only thing that seems clear to me is that the libggi or the kernel > WILL NOT save any screen content or palette, and there will be an > redraw event or signal on reactivation. As for the palette, I think LibGGI should always keep a copy of it, as a new field in ggi_visual (ggi_color *palette). This would allow the palette to be easily restored on switch-back. Also, some sub-libs already keep copies of the palette, so doing this will clean those up. The values stored in vis->palette would the exact ones set by the program. That lets us emulate ggiSetGamma(), for example, by calculating new values when setting the hardware palette. Agreed ? > 2) graphtypes and specifying the pixel setup > The problems 'getbuffer' and 'opotimised memory target' have been > reduced to this: > > the mode struct will be enhaced to include pixel layout information > good enough to construct optimal memory visuals, and/or to > negotiate buffer layouts. > > a field ggi_common_plb_setup ggimode.pixelfmt was suggested. > > I have two questions here: > 1 could this pixelfmt and the graphtype (which, actually, contains > a subset of the pixelfmt information) be folded into one > (64bit) value? This would make things *a lot* easier. Hmmm, I was about to say something against this, when it struck me as being a really good idea ! If you look at the ggi_common_plb_setup, there are four components: depth (e.g. 16), scheme (e.g. RGB), sub-scheme (e.g. r5g6b5) and access (e.g. 16). Then if you look at my graphtype proposal, there are two components: depth (e.g. 16) & scheme (e.g. RGB). Thus one is just a more specialized version of the other. > 2 How do we need to change graphtype? For the external LibGGI API, I would like to keep the graphtypes simple, nearly as simple as the current values. This is because programs won't, in general, want modes as specific as a "planar" mode or a "RGB 565" mode or a "CMYK with 32 bits of Z buffer and 12 bits of alpha" mode :-). Such programs would be very limited in what hardware / targets they ran on anyway. OK, here is my proposal (new and improved ! :-). I'll go into the details, so it could be rather long. Andy, please comment. Let's make the graphtype consist of three components: depth, scheme, and sub-scheme, as follows : #define GT_SCHEME_MASK 0xff0000 #define GT_SUBSCHEME_MASK 0x00ff00 #define GT_DEPTH_MASK 0x0000ff The schemes would be : #define GT_RGB 0x010000 #define GT_INDEXED 0x020000 #define GT_GREYSCALE 0x030000 #define GT_TEXT 0x040000 The depth is just what you'd expect. The sub-scheme doesn't make any sense on its own. Its only purpose would be to differentiate all the possible pixel formats within a particular scheme + depth combination. Here's how the current ggi_common_plb_setup values would be defined : ggi_common_plb_setup scheme sub-scheme depth sp1a8lbl = GT_INDEXED | 1 << 8 | 1 sp1a8hbl = GT_INDEXED | 2 << 8 | 1 sp2a8lpl = GT_INDEXED | 1 << 8 | 2 sp2a8hpl = GT_INDEXED | 2 << 8 | 2 sp4a8lnl = GT_INDEXED | 1 << 8 | 4 sp4a8hnl = GT_INDEXED | 2 << 8 | 4 sp8a8i8 = GT_INDEXED | 1 << 8 | 8 sp16a16r5g5b5A1 = GT_RGB | 1 << 8 | 16 sp16a16r5g5b5A1rev = GT_RGB | 2 << 8 | 16 sp16a16b5g5r5A1 = GT_RGB | 3 << 8 | 16 sp16a16b5g5r5A1rev = GT_RGB | 4 << 8 | 16 sp16a16r5g6b5 = GT_RGB | 5 << 8 | 16 sp16a16r5g6b5rev = GT_RGB | 6 << 8 | 16 sp16a16b5g6r5 = GT_RGB | 7 << 8 | 16 sp16a16b5g6r5rev = GT_RGB | 8 << 8 | 16 sp24a8b8g8r8 = GT_RGB | 1 << 8 | 24 sp24a8r8g8b8 = GT_RGB | 2 << 8 | 24 sp32a32b8g8r8A8 = GT_RGB | 1 << 8 | 32 sp32a32b8g8r8A8rev = GT_RGB | 2 << 8 | 32 sp32a32r8g8b8A8 = GT_RGB | 3 << 8 | 32 sp32a32r8g8b8A8rev = GT_RGB | 4 << 8 | 32 Here's how the current graphtypes would be defined : GT_1BIT = GT_INDEXED | 1 GT_2BIT = GT_INDEXED | 2 GT_4BIT = GT_INDEXED | 4 GT_8BIT = GT_INDEXED | 8 GT_16BIT = GT_RGB | 16 GT_24BIT = GT_RGB | 24 GT_32BIT = GT_RGB | 32 GT_TEXT16 = GT_TEXT | 16 GT_TEXT32 = GT_TEXT | 32 Now, using zero in one of the fields has a special meaning, not unlike GGI_AUTO. Usually a program will use ggiSetGraphMode() with something like GT_RGB | 16, leaving the sub-scheme field zero. The display target then fills in that field with the actual pixel format (e.g. becoming GT_RGB | 5<<8 | 16 for a sp16a16r5g6b5 framebuffer). If a program really wanted a certain format (and this would be especially valid with the memory target), then it is free to call ggiSetGraphMode() with GT_RGB | 5<<8 | 16, for example. If that particular format wasn't available, the setmode would just fail. Also, a program could use "GT_RGB" (leaving the depth 0), which would be interpreted as "give me the best RGB mode you've got", and the result could come back as GT_RGB | 1<<8 | 24 (== sp24a8b8g8r8). The full graphtype also [A] serves as the buffer format for ggiGetBox() and ggiPutBox() and others, and [B] serves as the pixel format for ggiGetPixel(), ggiPutPixel(), ggiSetGCForeground() and others. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Wed Jun 24 00:13:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA22091; Wed, 24 Jun 1998 00:13:48 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id AAA20234; Wed, 24 Jun 1998 00:18:41 -0700 (PDT) Resent-Date: Wed, 24 Jun 1998 00:18:41 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806240711.JAA24650@cip8.e-technik.uni-erlangen.de> Subject: Re: Obtaining development versions To: ggi-develop@eskimo.com Date: Wed, 24 Jun 1998 09:11:23 +0200 (MESZ) In-Reply-To: from "Jonathan C Day" at Jun 23, 98 02:12:39 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Fa0xQ1.0.zx4.FXAar"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3018 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Hi, > > There was an earlier message about public CVS > access to the development branch being switched > from cvs.ggi-project.org to another server, in > the US (anoncvs.us.ggi-project.org). I'm having > problems accessing it & am wondering if there's > a problem with the server, or if the original > message missed some information. > > The errors I'm getting are: > > cvs checkout: warning: unrecognized response `cvs: setgroups: Operation > not permitted' from cvs server > protocol error: directory '/projects/ggi/cvsdevel/degas' not within root > '/cvsdevel' > > Apologies if this is an "obvious" one > > Jonathan > > > Jonathan, could it be that you checked out your original tree from cvs? The problem seems to be that cvs stores the server directory name in your local tree, so if you update from a different server, the directory names get messed up. (Todd? Help?) A fresh check out should do, but I don't know whether you made changes to your tree you don't want to lose. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 24 02:16:46 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA22292; Wed, 24 Jun 1998 02:16:44 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA29129; Wed, 24 Jun 1998 02:16:00 -0700 (PDT) Resent-Date: Wed, 24 Jun 1998 02:16:00 -0700 (PDT) X-Sender: ortalo@poptsf.laas.fr Message-Id: In-Reply-To: References: from "Uwe Maurer" at Jun 22, 98 06:01:22 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro F3.1.3 Date: Wed, 24 Jun 1998 11:11:23 +0200 To: ggi-develop@eskimo.com From: Rodolphe Ortalo Subject: Re: Mesa, GLUT and fun ... Resent-Message-ID: <"8Bl8F1.0.177.FFCar"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3019 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com >Now for the fun part ... ask anyone, if he can do this with a mere setting >of a envvar : Grrr... If everyone succeeds in having multiple windows _without_ libgwt I'm gonna stop the work !!! GWT: now gets renamed the Generally too late Windowing Toolkit Rodolphe ;-)) PS: Excellent posting Andreas ! From ggi-develop-request@eskimo.com Wed Jun 24 02:40:31 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA22316; Wed, 24 Jun 1998 02:40:29 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA00451; Wed, 24 Jun 1998 02:37:22 -0700 (PDT) Resent-Date: Wed, 24 Jun 1998 02:37:22 -0700 (PDT) Message-ID: From: Paul Sargent To: "'ggi-develop@eskimo.com'" Subject: RE: 3Dlabs drivers Date: Wed, 24 Jun 1998 10:15:59 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"az3vg3.0.x6.HZCar"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3020 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Well Steffen's drivers are Permedia, but I would expect some GLINT stuff soon (From SuSE / XFree86, if no one else. They also have permission) Paul -- Paul Sargent, 3Dlabs Inc. Ltd, >-----Original Message----- >From: Dan Hollis [SMTP:goemon@sasami.anime.net] >Sent: Wednesday, June 24, 1998 12:26 AM >To: GGI GGI >Subject: Re: 3Dlabs drivers > >On Tue, 23 Jun 1998, Steffen Seeger wrote: >> this is just to inform you that I will be allowed to release 3Dlabs >> driver sources after approval by 3Dlabs. We have to check out the >> details, but basically I got permission to publish them. > >This is the Glint stuff, yes? > >-Dan > From ggi-develop-request@eskimo.com Wed Jun 24 03:34:22 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA22380; Wed, 24 Jun 1998 03:34:19 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA03883; Wed, 24 Jun 1998 03:17:25 -0700 (PDT) Resent-Date: Wed, 24 Jun 1998 03:17:25 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3590D085.C3F2EDD5@e.kth.se> Date: Wed, 24 Jun 1998 12:10:13 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: libggi open issues References: <199806231401.QAA01330@cip8.e-technik.uni-erlangen.de> <19980624164944.31638@ajax.netspace.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7Q2Pu.0.Zy.p8Dar"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3021 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andrew Apted wrote: > Hmmm, I was about to say something against this, when it struck me as > being a really good idea ! > > If you look at the ggi_common_plb_setup, there are four components: > depth (e.g. 16), scheme (e.g. RGB), sub-scheme (e.g. r5g6b5) and access > (e.g. 16). Then if you look at my graphtype proposal, there are two > components: depth (e.g. 16) & scheme (e.g. RGB). Thus one is just a > more specialized version of the other. > > > 2 How do we need to change graphtype? > > For the external LibGGI API, I would like to keep the graphtypes simple, > nearly as simple as the current values. This is because programs won't, > in general, want modes as specific as a "planar" mode or a "RGB 565" > mode or a "CMYK with 32 bits of Z buffer and 12 bits of alpha" mode :-). > Such programs would be very limited in what hardware / targets they ran > on anyway. > > OK, here is my proposal (new and improved ! :-). I'll go into the > details, so it could be rather long. Andy, please comment. > > Let's make the graphtype consist of three components: depth, scheme, and > sub-scheme, as follows : > > #define GT_SCHEME_MASK 0xff0000 > #define GT_SUBSCHEME_MASK 0x00ff00 > #define GT_DEPTH_MASK 0x0000ff > > The schemes would be : > > #define GT_RGB 0x010000 > #define GT_INDEXED 0x020000 > #define GT_GREYSCALE 0x030000 > #define GT_TEXT 0x040000 > > The depth is just what you'd expect. > > The sub-scheme doesn't make any sense on its own. Its only purpose > would be to differentiate all the possible pixel formats within a > particular scheme + depth combination. > > Here's how the current ggi_common_plb_setup values would be defined : > > ggi_common_plb_setup scheme sub-scheme depth > > sp1a8lbl = GT_INDEXED | 1 << 8 | 1 > sp1a8hbl = GT_INDEXED | 2 << 8 | 1 > > sp2a8lpl = GT_INDEXED | 1 << 8 | 2 > sp2a8hpl = GT_INDEXED | 2 << 8 | 2 > > sp4a8lnl = GT_INDEXED | 1 << 8 | 4 > sp4a8hnl = GT_INDEXED | 2 << 8 | 4 > > sp8a8i8 = GT_INDEXED | 1 << 8 | 8 > > sp16a16r5g5b5A1 = GT_RGB | 1 << 8 | 16 > sp16a16r5g5b5A1rev = GT_RGB | 2 << 8 | 16 > sp16a16b5g5r5A1 = GT_RGB | 3 << 8 | 16 > sp16a16b5g5r5A1rev = GT_RGB | 4 << 8 | 16 > sp16a16r5g6b5 = GT_RGB | 5 << 8 | 16 > sp16a16r5g6b5rev = GT_RGB | 6 << 8 | 16 > sp16a16b5g6r5 = GT_RGB | 7 << 8 | 16 > sp16a16b5g6r5rev = GT_RGB | 8 << 8 | 16 > > sp24a8b8g8r8 = GT_RGB | 1 << 8 | 24 > sp24a8r8g8b8 = GT_RGB | 2 << 8 | 24 > > sp32a32b8g8r8A8 = GT_RGB | 1 << 8 | 32 > sp32a32b8g8r8A8rev = GT_RGB | 2 << 8 | 32 > sp32a32r8g8b8A8 = GT_RGB | 3 << 8 | 32 > sp32a32r8g8b8A8rev = GT_RGB | 4 << 8 | 32 > > Here's how the current graphtypes would be defined : > > GT_1BIT = GT_INDEXED | 1 > GT_2BIT = GT_INDEXED | 2 > GT_4BIT = GT_INDEXED | 4 > GT_8BIT = GT_INDEXED | 8 > > GT_16BIT = GT_RGB | 16 > GT_24BIT = GT_RGB | 24 > GT_32BIT = GT_RGB | 32 > > GT_TEXT16 = GT_TEXT | 16 > GT_TEXT32 = GT_TEXT | 32 > > Now, using zero in one of the fields has a special meaning, not unlike > GGI_AUTO. Usually a program will use ggiSetGraphMode() with something > like GT_RGB | 16, leaving the sub-scheme field zero. The display target > then fills in that field with the actual pixel format (e.g. becoming > GT_RGB | 5<<8 | 16 for a sp16a16r5g6b5 framebuffer). > > If a program really wanted a certain format (and this would be > especially valid with the memory target), then it is free to call > ggiSetGraphMode() with GT_RGB | 5<<8 | 16, for example. If that > particular format wasn't available, the setmode would just fail. > > Also, a program could use "GT_RGB" (leaving the depth 0), which would be > interpreted as "give me the best RGB mode you've got", and the result > could come back as GT_RGB | 1<<8 | 24 (== sp24a8b8g8r8). > > The full graphtype also [A] serves as the buffer format for ggiGetBox() > and ggiPutBox() and others, and [B] serves as the pixel format for > ggiGetPixel(), ggiPutPixel(), ggiSetGCForeground() and others. I like this! Two comments though: How will you fit 2048 (8<<8) into the one byte subscheme field? ;-) We'll need two fields for the depth - one that specifies the physical size of the pixel, and one that specifies the number of significant bits. (The significant bits can not be implicitly specified with the subscheme field - if you want't a 15 bit mode you shouldn't have to try 4 different subschemes of 16 bit mode and see which works. Also for a planar 5/6/7 bit mode libggi would most probably want to work with one byte per pixel.) This shouldn't cause any problems as we have one unused byte in the above scheme. //Marcus From ggi-develop-request@eskimo.com Wed Jun 24 08:47:10 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA22691; Wed, 24 Jun 1998 08:47:07 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA03776; Wed, 24 Jun 1998 08:41:18 -0700 Resent-Date: Wed, 24 Jun 1998 08:41:18 -0700 Date: Wed, 24 Jun 1998 16:41:11 +0100 (BST) From: "Dr S.M. Huen" To: andreas.beck@ggi-project.org cc: ggi-develop@eskimo.com Subject: Re: I don't understand football rules...(Way off topic) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"gdA4L.0.ew.SuHar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3022 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 23 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > > > > ...and helicopters scouting in the town sky at midnight, looking > > > for hords of wandering hooligans. > > Well, I do understand football, and to some extent helicopters, > > but for hooligans I haven't got a clue. > > Have you tried converting them to EvStacks? > > I'd rather suggest to pipe those directly to /dev/null. > > Another alternative which is unfortunately not compatible with law and public > health care would be putting all of them in a big arena, equipping them well > and closing the door. > I think that's called an England vs Germany game...... David From ggi-develop-request@eskimo.com Wed Jun 24 09:09:14 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA22714; Wed, 24 Jun 1998 09:09:12 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA13205; Wed, 24 Jun 1998 09:03:59 -0700 Resent-Date: Wed, 24 Jun 1998 09:03:59 -0700 From: Hartmut Niemann Message-Id: <199806241603.SAA11193@cip8.e-technik.uni-erlangen.de> Subject: Re: libggi open issues To: ggi-develop@eskimo.com Date: Wed, 24 Jun 1998 18:03:24 +0200 (MESZ) In-Reply-To: <3590D085.C3F2EDD5@e.kth.se> from "Marcus Sundberg" at Jun 24, 98 12:10:13 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"W6inL1.0.3E3.jDIar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3023 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com The discussion makes clear that we do not need the current graphtype and an additional pixel setup, as the information is almost identical; they can (and IMHO should) be folded into a new graphtype definition. Now I have got about four suggestions and some thoughts myself, and I want to come up with this scheme for a new graphtype which integrates the old graphtype and plb_common_setup, and hopefully all other suggestions I got: The new graphtype is an integer with (currently) at least 32 bit. As users should use ggi_graphtype, they shouldn't be affected if we need to change this to 64 bits some day. bits 7-0 contain the bits per pixel actually used, this means: padding bits are not counted, a 15 bpp mode has 15 here. I would like to suggest to count the number of *foreground colours* possible, which makes most text modes ==4. bits 15:8 contain the bits per pixel occupied in memory. Marcus pointed out that one might want not to code that into the 'subtypes' field. bits 23:16 contain the subtypes. Subtype 0 always means: don't know/don't care. Other types are allocated as needed, together with a proper define along the 'old' common_plb_setup's. bit 24: 1 for text mode bit 25: 1 for indexed mode (think of it, you can specify an indexed text mode in YUV, and it makes some sense ...) bit 31:28 enumerated color space definitions: (are there more than 16?) 1:RGB 2: YUV 3: ... 4: RGB double precision floats ?? (two spare bits :-) If everything is 'hidden' by defines, nobody will ever want to deal with that bitmap in detail anyway ... #define GT_TEXTMODE 0x01000000 #define GT_INDEXED 0x02000000 #define GT_RGB 0x10000000 #define GT_YUV 0x20000000 #define GT_MODE(x,bpp,consumed,sub) x+bpp+(consumed<<8)+(sub<<16) #define sp16a16r5g5b5A1rev GT_MODE(GT_RGB,15,16,1) /* 15 bit BGR 5/5/5 reverse endian */ #define sp16a16b5g5r5A1 GT_MODE(GT_RGB,15,16,2) /* 15 bit RGB 5/5/5 native endian */ int ggiModeBpp(graphtype g){return (g&&0xff)}; .... One important question is: do we want to make this change now, before the feature freeze, which could make the july1st-release unstable, or do we want to make it on july 1st, which might make the july1st release binary incompatible with the next releases to come? Andy? What do you think? Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 24 09:30:06 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA22726; Wed, 24 Jun 1998 09:30:04 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA18706; Wed, 24 Jun 1998 09:19:11 -0700 Resent-Date: Wed, 24 Jun 1998 09:19:11 -0700 From: Hartmut Niemann Message-Id: <199806241618.SAA11426@cip8.e-technik.uni-erlangen.de> Subject: Re: libggi open issues To: jmcc@ontv.com Date: Wed, 24 Jun 1998 18:18:22 +0200 (MESZ) Cc: ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: <6mofc7$n9o$1@butter.visus.com> from "Jason McMullan" at Jun 23, 98 02:50:47 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"mAt9P.0.3a4.-RIar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3024 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > Hartmut Niemann wrote with confidence: > > 1) switch-away and switch-back > > Ther is no solution that looks complete, AFAIK. > > > The only thing that seems clear to me is that the libggi or the kernel > > WILL NOT save any screen content or palette, and there will be an > > redraw event or signal on reactivation. > > Bingo. libGGI (KGI) will get the signals, and translate > them into `redraw now' events or callbacks. Sorry for being so pedantic: what do you mean with OR? To make my position clear: I want to finish the libggi documentation, and prepare ground for Peter's libggi tutorial. I want to know how the libggi+system combo will behave. I don't want to know (yet) how that's implemented. Will a program receive signals or events? Can it have the choice? What happens if a program does not check/catch them? What if a program is in between to hlines, when it gets deactivated? Will it be paused? Will the commands be ignored? What happens if 'attention' comes back? Does the palette get restored by the system or does the program have to do it? One comment suggested that most targets have a copy of the palette anyway, so it would be no problem to let libggi do the CLUT update. Does the program get as redraw event with a redraw rectangle (I guess X does it this way for X applications), and possibly a series of redraw events for several rectangles, or a simple 'do it all again'? If a signal, what signal? What will be the default signal handler? If an event, what event? Can a program request to be stopped when deactivated? How? Can a program request that all drawing requests are /dev/null-ed? How? Or will all drawing commands simply fail ,i.e. return -1? Or will it get a signal every time it tries to draw, and do only signal processing from that point? What for targets that would make 'lost attention' continuing, like the X target with its memory, possible? Will they behave like the targets that can't, like accellerated KGI? Probably good answers for this, and a good concept next month is better than a bad concept tomorrow, but I would like to know the answer tomorrow anyway :-) Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Wed Jun 24 10:04:29 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA22755; Wed, 24 Jun 1998 10:04:23 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA19257; Wed, 24 Jun 1998 10:05:59 -0700 (PDT) Resent-Date: Wed, 24 Jun 1998 10:05:59 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: libggi open issues Date: 24 Jun 1998 17:02:23 GMT Organization: OnTV Pittsburgh, L.P. Lines: 27 Sender: Jason McMullan Distribution: local Message-ID: <6mrbev$rno$1@butter.visus.com> References: <6mqkmd$irg$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.34 (i586)) Resent-Message-ID: <"6Dj8A2.0.hi4.r7Jar"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3025 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Andrew Apted wrote: >> The schemes would be : >> >> #define GT_RGB 0x010000 >> #define GT_INDEXED 0x020000 >> #define GT_GREYSCALE 0x030000 >> #define GT_TEXT 0x040000 >> >> The depth is just what you'd expect. I really like it, but (for the sake of generarality) could you #define GT_TILE GT_TEXT ? The proper way to think of IBM text is of a tile display with a bank of 256 two-bit tiles. This way you can extend it to cover (say) the Nintendo display system, with is (IIRC) a 32x24 grid of 8x8 4 color tiles. -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Wed Jun 24 10:35:34 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA22794; Wed, 24 Jun 1998 10:35:27 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA12309; Wed, 24 Jun 1998 10:33:04 -0700 Resent-Date: Wed, 24 Jun 1998 10:33:04 -0700 Date: Wed, 24 Jun 1998 10:25:46 -0700 (PDT) From: KC5TJA To: Jason McMullan cc: ggi-develop@eskimo.com Subject: Re: libggi open issues In-Reply-To: <6mrbev$rno$1@butter.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"vh9Yx1.0.D03.FXJar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3026 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I really like it, but (for the sake of generarality) could > you #define GT_TILE GT_TEXT ? The proper way to think of IBM text > is of a tile display with a bank of 256 two-bit tiles. This 1 bit tiles only. You either have a foreground color, or a background color. Some video cards have an "extended" text mode that does allow for four color (used for anti-aliasing usually), but it is NOT a standard. Also, IBM VGAs support 512 tiles too. The extra 'bit' is kept in the "bright/blink" bit if I recall correctly. Of course, you need to set certain VGA registers to get this mode. :) ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Wed Jun 24 12:01:13 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA22956; Wed, 24 Jun 1998 12:01:09 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA13100; Wed, 24 Jun 1998 12:01:51 -0700 Resent-Date: Wed, 24 Jun 1998 12:01:51 -0700 Message-Id: <199806241901.VAA11391@paris.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: ggi-develop@eskimo.com Subject: Re: I have seen the stars... In-reply-to: Your message of "Thu, 18 Jun 1998 20:46:40 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jun 1998 21:01:24 +0200 From: Marcus Sundberg Resent-Message-ID: <"C2r3b1.0.TC3.UqKar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3028 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > - It's under the GPL (not LGPL), which only allows GPLed > > code to be linked with it. > > They said they were going to fix that a while back -- it should be fixed by > now. You have the most recent version, right? Fixed? Cygnus offers non GPLed licenses for cygwin.dll if you pay them, which I think is perfectly alright - if you want to make money from someone elses software you should pay them. //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Wed Jun 24 12:03:59 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA22965; Wed, 24 Jun 1998 12:03:51 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA11699; Wed, 24 Jun 1998 11:58:40 -0700 Resent-Date: Wed, 24 Jun 1998 11:58:40 -0700 Message-Id: <199806241858.UAA11369@paris.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: ggi-develop@eskimo.com Subject: Re: libggi open issues In-reply-to: Your message of "Wed, 24 Jun 1998 18:03:24 +0200." <199806241603.SAA11193@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jun 1998 20:58:10 +0200 From: Marcus Sundberg Resent-Message-ID: <"wKpAR3.0.gs2.WnKar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3027 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > bit 24: 1 for text mode > bit 25: 1 for indexed mode > (think of it, you can specify an indexed text mode in YUV, and > it makes some sense ...) > > bit 31:28 enumerated color space definitions: (are there more than 16?) > 1:RGB > 2: YUV > 3: ... > 4: RGB double precision floats ?? > (two spare bits :-) I would suggest: bit 24-25: enumerated colorspace definitions 0: Don't care 1: RGB 2: YUV 3: allocated when needed bit 26-29: allocated when we need them bit 30: 1 for indexed mode bit 31: 1 for text mode This will allow us to expand both the enumeration values and the flags when needed. //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Wed Jun 24 12:30:10 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA23003; Wed, 24 Jun 1998 12:30:09 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA26033; Wed, 24 Jun 1998 12:25:26 -0700 Resent-Date: Wed, 24 Jun 1998 12:25:26 -0700 Date: Thu, 25 Jun 1998 12:23:58 -0700 (MST) From: teunis To: ggi-develop@eskimo.com Subject: Re: libggi open issues In-Reply-To: <199806241858.UAA11369@paris.e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"7t-cK3.0.dM6.bALar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3029 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 24 Jun 1998, Marcus Sundberg wrote: > > bit 24: 1 for text mode > > bit 25: 1 for indexed mode > > (think of it, you can specify an indexed text mode in YUV, and > > it makes some sense ...) > > > > bit 31:28 enumerated color space definitions: (are there more than 16?) > > 1:RGB > > 2: YUV > > 3: ... > > 4: RGB double precision floats ?? > > (two spare bits :-) > > I would suggest: > bit 24-25: enumerated colorspace definitions > 0: Don't care > 1: RGB > 2: YUV > 3: allocated when needed Aside : there's in the range of ~10 standard colour mappings... I'll have to look them up again though. There's 3 on my videocard (ViRGE): RGB, YUV, YCbCr (not a lot of differences between the last two but they ARE different). > bit 26-29: allocated when we need them > > bit 30: 1 for indexed mode > bit 31: 1 for text mode > > This will allow us to expand both the enumeration > values and the flags when needed. Good idea though! G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Wed Jun 24 13:47:59 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA23078; Wed, 24 Jun 1998 13:47:55 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA24746; Wed, 24 Jun 1998 13:48:01 -0700 Resent-Date: Wed, 24 Jun 1998 13:48:01 -0700 Date: Wed, 24 Jun 1998 22:47:54 +0200 (MET DST) From: Rodolphe Ortalo X-Sender: ortalo@schubert To: ggi-develop@eskimo.com Subject: libggi compile problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"mjZO5.0.V26.0OMar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3031 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Since yesterday, with an up-to-date devel degas source tree, I am not able to compile libggi. I get the error message at the end of this mail. Apart from the ANSI C warning which is only annoying, I cannot find where these "{GGI}setsplitline" field should be. In my opinion, some header file needs some clean up. As none mentioned this problem, here is the error log. Rodolphe [....] make[2]: Entering directory `/usr/local/degas/lib/libggi/display/kgi' gcc -fPIC -O2 -funroll-loops -fomit-frame-pointer -m486 -malign-functions=2 -malign-loops=2 -malign-jumps=2 -pedantic -I/usr/local/degas/lib/libggi/include -I/usr/local/degas/lib/libggi/../../include -I/usr/local/degas/lib/libggi/../../driver/include -Wall -Wstrict-prototypes -g -DDEBUG -DGGICONFFILE=\"/etc/ggi/libggi.conf\" -c -o visual.o visual.c In file included from /usr/local/degas/lib/libggi/../../include/ggi/types.h:268, from /usr/local/degas/lib/libggi/../../include/ggi/ggi.h:28, from /usr/local/degas/lib/libggi/../../include/kgi/ioctl.h:36, from visual.c:31: /usr/local/degas/lib/libggi/../../include/ggi/events.h:67: warning: ANSI C restricts enumerator values to range of `int' visual.c: In function `GGIdlinit': visual.c:65: structure has no member named `setsplitline' visual.c:65: `GGIsetsplitline' undeclared (first use this function) visual.c:65: (Each undeclared identifier is reported only once visual.c:65: for each function it appears in.) make[2]: *** [visual.o] Error 1 make[2]: Leaving directory `/usr/local/degas/lib/libggi/display/kgi' make[1]: *** [SUBDIRS-all] Error 1 make[1]: Leaving directory `/usr/local/degas/lib/libggi/display' make: *** [SUBDIRS-all] Error 1 From ggi-develop-request@eskimo.com Wed Jun 24 13:50:23 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA23087; Wed, 24 Jun 1998 13:50:21 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA23234; Wed, 24 Jun 1998 13:45:57 -0700 Resent-Date: Wed, 24 Jun 1998 13:45:57 -0700 Sender: thomas@eskimo.com Message-ID: <3591649A.1992375A@gmx.de> Date: Wed, 24 Jun 1998 22:42:02 +0200 From: Thomas Tanner X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: libggi open issues References: <199806241603.SAA11193@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"CsH4d2.0.tg5.3MMar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3030 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > The new graphtype is an integer with (currently) at least 32 bit. > As users should use ggi_graphtype, they shouldn't be affected if > we need to change this to 64 bits some day. Do we really need to save _so much_ memory for mode setting? If we change one bit we would get into trouble... Is this really necessary? I would suggest a simple mode struct. > bit 31:28 enumerated color space definitions: (are there more than 16?) > 1:RGB > 2: YUV > 3: ... > 4: RGB double precision floats ?? > (two spare bits :-) indexed, greyscale, RGB, HSV, HLS, YUV, YCrCb, CMY, CYMK, CIE L*a*b*, CIE L*u*v, CIE uvY, CIE xyY, CIE XYZ (most general) ... This are 14 color spaces, and with integer/double precision we have 28. > What do you think? Looks nice at the first glance but it would cause many problems in future. -- Thomas Tanner ----------------------------- email: tanner@gmx.de tanner@ggi-project.org web: http://home.pages.de/~tanner GGI: http://www.ggi-project.org From ggi-develop-request@eskimo.com Wed Jun 24 13:59:13 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA23111; Wed, 24 Jun 1998 13:59:09 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA21193; Wed, 24 Jun 1998 13:57:03 -0700 (PDT) Resent-Date: Wed, 24 Jun 1998 13:57:03 -0700 (PDT) Sender: ken@uno.canit.se Message-ID: <35917469.E0EBB205@canit.se> Date: Wed, 24 Jun 1998 23:49:30 +0200 From: Kenneth Johansson X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: CVS mirrors and guest access. References: <199806222217.AAA06255@zafir.e.kth.se> <199806222241.AAA08752@orb.suntech.fr> <19980622193735.17638@fries.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"USBEd2.0.0B5.TWMar"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3032 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Todd T. Fries wrote: > On Tue, Jun 23, 1998 at 12:34:52AM +0200, Emmanuel Marty wrote: > > Todd T. Fries has been mirroring both CVS repositories since they > > came back; the mirror is in the US at anoncvs.ggi-project.org, > > but I don't know the exact :pserver path since this information > > never made it to the website for some reason unknown to me. I'm sure > > Todd will fill in the blanks. > > 1. :pserver: incarnation of access > requires you to do 'cvs login' before 'cvs get degas' with one of the > two CVSROOT's: > :pserver:anoncvs@anoncvs.us.ggi-project.org:/cvs > :pserver:anoncvs@anoncvs.us.ggi-project.org:/cvsdevel > Password ?? Well I guesed right but not on my fisrt try (anoncvs) > Hrm, I hope I'm ready! hmm how is this mirroring done? I'am updating from you now but I got the postscrip files and they was deleted on the main repository quite a while ago. If the cvs mirror is so much behinde it is going to make some confusion. From ggi-develop-request@eskimo.com Wed Jun 24 14:55:10 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA23202; Wed, 24 Jun 1998 14:55:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA14804; Wed, 24 Jun 1998 14:54:18 -0700 Resent-Date: Wed, 24 Jun 1998 14:54:18 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Dropped off ? Or all all quiet ? To: ggi-develop@eskimo.com (mailing list GGI) Date: Wed, 24 Jun 1998 20:33:49 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"enPOj3.0.0d3.8MNar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3034 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! - Subject says it all ... CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 24 14:55:12 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA23205; Wed, 24 Jun 1998 14:55:06 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA15062; Wed, 24 Jun 1998 14:54:40 -0700 Resent-Date: Wed, 24 Jun 1998 14:54:40 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: libggi open issues To: ggi-develop@eskimo.com (mailing list GGI) Date: Wed, 24 Jun 1998 21:58:39 +0200 (MET DST) In-Reply-To: <6mosb9$sal$1@butter.visus.com> from "Jason McMullan" at Jun 23, 98 06:32:09 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"7E-Oc2.0.9g3.TMNar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3038 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > Are those `redraw now' events associated to a region or the whole screen? > > The KGI signals will imply the whole screen, but the libGGI events > should be able to specify a rectangular region. (in the KGI case, > the entire screen, under X just what was exposed, etc). > > BeckA, how's that libGGI clipping coming along? ??? LibGGI should clip fine. Anyone seen something else ? In that case fix it ! CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 24 14:56:04 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA23211; Wed, 24 Jun 1998 14:56:01 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA14928; Wed, 24 Jun 1998 14:54:34 -0700 Resent-Date: Wed, 24 Jun 1998 14:54:34 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: 3Dlabs drivers To: ggi-develop@eskimo.com Date: Wed, 24 Jun 1998 21:53:57 +0200 (MET DST) In-Reply-To: <199806231658.SAA01278@legrelle.physik.tu-chemnitz.de> from "Steffen Seeger" at Jun 23, 98 06:58:08 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"GQNEr.0.xe3.NMNar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3036 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > this is just to inform you that I will be allowed to release 3Dlabs > driver sources after approval by 3Dlabs. We have to check out the > details, but basically I got permission to publish them. Great - so I'm safe to buy myself a ELSA Winner 2000 Office AGP 8MB ? Or is there any catch to watch out for (like AGP doesn't work or something like that ...) ? CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 24 14:58:10 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA23216; Wed, 24 Jun 1998 14:58:07 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA13306; Wed, 24 Jun 1998 14:51:01 -0700 Resent-Date: Wed, 24 Jun 1998 14:51:01 -0700 Message-Id: <199806242150.XAA18877@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: libggi compile problem In-reply-to: Your message of "Wed, 24 Jun 1998 22:47:54 +0200." Date: Wed, 24 Jun 1998 23:50:55 +0200 From: Marcus Sundberg Resent-Message-ID: <"OmPFs3.0.iF3.3JNar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3033 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Since yesterday, with an up-to-date devel degas source tree, I am not > able to compile libggi. I get the error message at the end of this > mail. Apart from the ANSI C warning which is only annoying, I cannot > find where these "{GGI}setsplitline" field should be. In my opinion, some > header file needs some clean up. > As none mentioned this problem, here is the error log. On the contrary - header files being cleaned up is the cause of this problem: Yesterday I wrote: > I've also removed all traces of splitline and raypos from > lib/libggi/include, so most targets will have to be fixed. > (They should go into the misc extension if anyone didn't > get that yet.) //Marcus From ggi-develop-request@eskimo.com Wed Jun 24 14:59:07 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA23221; Wed, 24 Jun 1998 14:59:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA15159; Wed, 24 Jun 1998 14:54:51 -0700 Resent-Date: Wed, 24 Jun 1998 14:54:51 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: libggi open issues To: ggi-develop@eskimo.com Date: Wed, 24 Jun 1998 23:41:31 +0200 (MET DST) In-Reply-To: <199806231401.QAA01330@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at Jun 23, 98 04:01:37 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"67wV13.0.-e3.NMNar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3037 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > 1) switch-away and switch-back > Ther is no solution that looks complete, AFAIK. > > The only thing that seems clear to me is that the libggi or the kernel > WILL NOT save any screen content or palette, and there will be an > redraw event or signal on reactivation. O.K. - this is just a draft - didn't have the time to complete, but that's what I think of the matter: Hi folks ! I have been thinking over the VT-switchaway problem, and here is what came to my mind: 1. The only clean way to handle asynchronous events like these is to simply put them into the event queue as COMMAND events. Reasons: The only other way I can see would be callbacks. Most of the time, those could anyway only happen while checking events, as the backend event polling will only set in at those times, so the external sources notifying LibGGI about such things are only checked at that time. A few backends like the SVGAlib one however will generate fully asynchronous events (i.e. signals) which might cause nasty race conditions, if the handler would do something to some internal state. Other than that, it pushes the users to do the right thing and check for events often. We can still add a small gluelayer to the Event getting code to do callbacks, though they are done in a defined state, then (at the end of some ggiEv* call ...). 2. The following events came to my mind a) (In)Visible When these are received, this is to be taken as a notification, that the application has somehow lost/regained visibility. This applies to X iconifying a window or VT switching on the console, as I think both actions are quite related. Actions might be stopping/restarting drawing and such. b) Redraw Parts of the Image have been destroyed. Please redraw your screen. This one will probably take parameters with the destroyed region. c) Move The place of the visual on its parent visual has changed. (e.g. by a window manager operation). This one will probably only be sent in context of the LibGWT extension. d) *Resize A resize of the visible area has been _requested_. It is up to you to grant it using a new SetMode call. Thus you can decide on how to proceed. e) *VirtMove The placement of the viewport on the virtual screen is requested to be changed. I do not know of a target/windowing system that has such a capability (though ... a window with scrollbars would effectively represent such a thing ...). You would grant it using SetOrigin. f) *NewVisual and Mode The program is requested to move its display to a new visual and mode. This can be very useful for e.g. moving doom from X-win to fullscreen. Parts (i.e. the visual or the mode) may be marked as "keep" to avoid changing them. The idea is to provide a generic interface for doing things like this. I'd love to be able to tell some X-app _at runtime_ "go, move yourself over to DISPLAY=1.2.3.4:0.0 - I'll continue working from there.". Note that the Events marked with a (*) do only _request_ to change a given property. That is the application has still full control over granting such requests and in what way to handle them. A resize could e.g. be handled by either giving a bigger vieport into the virtual playfield or scaling up the scene. Also note, that no explicit action is required on _any_ of those events. The * events will just silently "deny" the request. Not noticing "Move" shouldn't hurt, ignoring "InVisible" might waste CPU for playing a movie in an invisible window and not reacting to "Redraw" will give a bad picture ... [ ... sorry ... incomplete here ... ] An advantage of that solution would be: - No additional calls needed, just defining a few EvCommand type events. - Thus backwards-compatible. - We can easily add in things like transparent backing store in an extension. Default is what should be default: Redraw on Request. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 24 15:07:10 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA23246; Wed, 24 Jun 1998 15:07:08 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA14861; Wed, 24 Jun 1998 14:54:25 -0700 Resent-Date: Wed, 24 Jun 1998 14:54:25 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Web page stuff To: ggi-develop@eskimo.com Date: Wed, 24 Jun 1998 20:54:29 +0200 (MET DST) In-Reply-To: from "Jon M. Taylor" at Jun 23, 98 04:26:41 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"JcQF_.0.td3.GMNar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3035 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > - The note on scrdrv.tgz still says that there is some stuff in there that > has yet to be ported to Degas, which AFAIK is no longer correct...Andy? Note sure - can anybody think of anything ? CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 24 17:44:25 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA23407; Wed, 24 Jun 1998 17:44:23 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id RAA10004; Wed, 24 Jun 1998 17:42:45 -0700 Resent-Date: Wed, 24 Jun 1998 17:42:45 -0700 Date: Wed, 24 Jun 1998 19:41:11 -0500 (CDT) From: "Edward S. Marshall" To: Marcus Sundberg Cc: ggi-develop@eskimo.com Subject: Re: I have seen the stars... In-Reply-To: <199806241901.VAA11391@paris.e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"RMsJc.0.AS2.4qPar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3039 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 24 Jun 1998, Marcus Sundberg wrote: > Cygnus offers non GPLed licenses for cygwin.dll if you pay them, > which I think is perfectly alright - if you want to make money from > someone elses software you should pay them. Consider, though, that you're dealing with a 3M+ library here; unless there are other applications making use of cygwin.dll, that's a good chunk of resources to lose for a compatibility layer to shore up a single app. The minimal package (which doesn't make use of cygwin.dll) would alleviate both the licensing concern (since things linked against libggi would also be linked against cygwin.dll, your application is tainted - as would be libggi...this isn't a trivial point, since the license of libggi is still a point of some debate) and any concerns over performance degradation and resources involved with libggi running on a large compatibility library like Cygnus' DLL. -- -------------------. emarshal at logic.net .--------------------------------- Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/ Linux labyrinth 2.1.106 #9 SMP Sun Jun 14 14:50:43 CDT 1998 i586 unknown 7:30pm up 2 days, 5:09, 2 users, load average: 0.74, 0.23, 0.07 From ggi-develop-request@eskimo.com Wed Jun 24 18:52:59 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA23455; Wed, 24 Jun 1998 18:52:56 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA00026; Wed, 24 Jun 1998 18:51:12 -0700 Resent-Date: Wed, 24 Jun 1998 18:51:12 -0700 Date: Wed, 24 Jun 1998 21:51:33 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com cc: Jason McMullan Subject: Re: libggi open issues In-Reply-To: <199806250032.UAA08522@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"WAEI_2.0.G.FqQar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3040 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 24 Jun 1998, KC5TJA wrote: > > I really like it, but (for the sake of generarality) could > > you #define GT_TILE GT_TEXT ? The proper way to think of IBM text > > is of a tile display with a bank of 256 two-bit tiles. This > > 1 bit tiles only. You either have a foreground color, or a background > color. Some video cards have an "extended" text mode that does allow for > four color (used for anti-aliasing usually), but it is NOT a standard. > > Also, IBM VGAs support 512 tiles too. The extra 'bit' is kept in the > "bright/blink" bit if I recall correctly. Of course, you need to set > certain VGA registers to get this mode. :) Yes, these concerns are just the sort of thing I'm trying to address in my general text library thingy that I'm trying to slap together a spec for right now. The four color text et. al. isn't standard, but it certainly could use some support for that hardware that has it. Being general-case enough to encompass things like a real tiled graphics system without making coding for the real basic stuff (VGA hardware) difficult is a pain. Bleah. I also need to figure out a good way to generally describe stuff like nonblink/512-char mode, etc... -=MenTaLguY=- From ggi-develop-request@eskimo.com Wed Jun 24 19:10:07 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA23509; Wed, 24 Jun 1998 19:10:00 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA06627; Wed, 24 Jun 1998 19:10:29 -0700 Resent-Date: Wed, 24 Jun 1998 19:10:29 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: New LIBGGI demo, iXalance To: ggi-develop@eskimo.com Date: Thu, 25 Jun 1998 00:30:25 +0200 (MET DST) Cc: jpaana@iki.fi In-Reply-To: from "Jarno Paananen" at Jun 20, 98 10:19:16 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"SbHFf.0.Kd1.J6Rar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3042 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I'll see what I can do, but for constant use I'd need a KGI that > allows me still to use XFree and SVGAlib (not so necessary though...) Yeah - working on that. The GGIcons version in the new repository should allow XFree to run, though with a few quirks (using a new console each time - but I think even this has been fixed yet ...). > > You should add an option in iXelata/libggi for it to use DirectBuffer > > instead of a memory visual and crossblit - half of the KGI drivers > > don't implement blit acceleration, so when ones displays through > > the KGI target it might be a good idea (just do it as an option > > to the end-user).. What do you think? > > I could do this. The only problems I see are that the demo code which > wants a linear 16-bit color buffer can't be altered anymore. And it > wants exactly the resolutions it requests. You could just ask the target to get you the right resolution and depth, and if it doesn't - well, that code is already there ... just fall back. > The other one is that the demos do pretty much reading from the buffer > too (alpha blending and such) and it's really slow from the actual > video memory. Yeah. This might be a problem, though few targets go right through to the framebuffer. You could simply add an option "-dont_use_db" or something like it to allow to force usage of the memory-target/crossblit method. > Btw. where does the X-target keep it's DirectBuffer? If that could be for > example the MITSHM-memory, at least one copy could be avoided I think. It is. It checks, if MITSHM is there and uses it, if available. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 24 19:10:40 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA23514; Wed, 24 Jun 1998 19:10:38 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA06607; Wed, 24 Jun 1998 19:10:27 -0700 Resent-Date: Wed, 24 Jun 1998 19:10:27 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Feature Freeze in effect ... To: ggi-develop@eskimo.com (mailing list GGI) Date: Thu, 25 Jun 1998 00:23:07 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"v8v3G2.0.1d1.I6Rar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3041 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi folks ! The feature freeze is now in effect. Please don't add new things to the repository now, but rather hunt bugs now. Anything reported to the list now should be fixed (or documented if fixing would be too complicated). Everyone should give killing off his GGIcons and/or LibGGI installation and reinstalling from scratch a try. Any newcomers that haven't dared yet, but are of a daring nature and want to help making it foolproof should try it out now, so we get some newbie feedback. (You know - we've been developing this thing for years, our subconscious knows all the pitfalls and avoids them ... :-). O.K. - let's get some work done ! CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Wed Jun 24 21:03:12 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA23573; Wed, 24 Jun 1998 21:03:09 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id VAA15242; Wed, 24 Jun 1998 21:06:33 -0700 (PDT) Resent-Date: Wed, 24 Jun 1998 21:06:33 -0700 (PDT) From: Andrew Apted Message-ID: <19980625135508.19601@ajax.netspace.net.au> Date: Thu, 25 Jun 1998 13:55:08 +1000 To: ggi-develop@eskimo.com Subject: Re: libggi open issues Reply-To: ggi-develop@eskimo.com References: <3590D085.C3F2EDD5@e.kth.se> <199806241603.SAA11193@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806241603.SAA11193@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Wed, Jun 24, 1998 at 06:03:24PM +0200 Resent-Message-ID: <"j_wrS1.0.0k3.5pSar"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3043 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut writes: > The new graphtype is an integer with (currently) at least 32 bit. > As users should use ggi_graphtype, they shouldn't be affected if > we need to change this to 64 bits some day. > > bits 7-0 contain the bits per pixel actually used, > this means: padding bits are not counted, a 15 bpp mode has 15 here. > I would like to suggest to count the number of *foreground colours* > possible, which makes most text modes ==4. Ok. We can call it "color depth" to be really precise. I also agree with using 4 for text modes. > bits 15:8 contain the bits per pixel occupied in memory. Marcus pointed > out that one might want not to code that into the 'subtypes' field. Ok. We can call it "access" as in the DirectBuffer stuff. > bits 23:16 contain the subtypes. > Subtype 0 always means: don't know/don't care. Well, I'm saying that when it is 0, it will get filled out by ggiSetMode() (like the way GGI_AUTO works). Is that what you meant too ? BTW, we also need a value that says "the subtype is private, so don't try to encode/decode the format, instead use ggiMapColor() and ggiUnmapPixel()". I suggest using all ones (i.e. 0xff << 16). > bit 24: 1 for text mode > bit 25: 1 for indexed mode > (think of it, you can specify an indexed text mode in YUV, and > it makes some sense ...) This doesn't make sense to me... could you please explain what you had in mind ? I am yet to be convinced that having either TEXT or INDEXED as an "or'd option" would actually be useful. For example, RGB | TEXT would imply that the text colors were encoded in the pixels with a mask for red, green and blue (e.g. rrggbbRRGGBBcccccccc), which is pretty silly IMHO. > bit 31:28 enumerated color space definitions: (are there more than 16?) > 1:RGB > 2: YUV > 3: ... > 4: RGB double precision floats ?? > (two spare bits :-) We should think very carefully before adding *any* extra colorspaces other than RGB. For example, just by including YUV we would need to change ggi_color to be a union, like this : typedef union ggi_color { struct { uint16 r, uint16 g, uint16 b, uint16 a } rgb; struct { uint16 y, uint16 u, uint16 v, uint16 a } yuv; } ggi_color; and while I'm not completely against this, I think it is a *big* step to take and needs to be discussed at length. > #define GT_MODE(x,bpp,consumed,sub) x+bpp+(consumed<<8)+(sub<<16) > #define sp16a16r5g5b5A1rev GT_MODE(GT_RGB,15,16,1) > /* 15 bit BGR 5/5/5 reverse endian */ > #define sp16a16b5g5r5A1 GT_MODE(GT_RGB,15,16,2) > /* 15 bit RGB 5/5/5 native endian */ Ok, Take II : The masks would be : #define GT_SCHEME_MASK 0xff000000 #define GT_SUBSCHEME_MASK 0x00ff0000 #define GT_ACCESS_MASK 0x0000ff00 #define GT_DEPTH_MASK 0x000000ff #define GT_MODE(scheme,sub,access,depth) \ (scheme + (sub << 16) + (access << 8) + depth) The schemes would be : #define GT_RGB 0x01000000 #define GT_INDEXED 0x02000000 #define GT_GREYSCALE 0x03000000 #define GT_TEXT 0x04000000 (possible future additions: GT_YUV, GT_CMYK, ...) Here's how the current ggi_common_plb_setup values would be defined : ggi_common_plb_setup scheme sub-scheme access depth sp1a8lbl = GT_MODE(GT_INDEXED, 1, 8, 1) sp1a8hbl = GT_MODE(GT_INDEXED, 2, 8, 1) sp2a8lpl = GT_MODE(GT_INDEXED, 1, 8, 2) sp2a8hpl = GT_MODE(GT_INDEXED, 2, 8, 2) sp4a8lnl = GT_MODE(GT_INDEXED, 1, 8, 4) sp4a8hnl = GT_MODE(GT_INDEXED, 2, 8, 4) sp8a8i8 = GT_MODE(GT_INDEXED, 1, 8, 8) sp16a16r5g5b5A1 = GT_MODE(GT_RGB, 1, 16, 15) sp16a16r5g5b5A1rev = GT_MODE(GT_RGB, 2, 16, 15) sp16a16b5g5r5A1 = GT_MODE(GT_RGB, 3, 16, 15) sp16a16b5g5r5A1rev = GT_MODE(GT_RGB, 4, 16, 15) sp16a16r5g6b5 = GT_MODE(GT_RGB, 5, 16, 16) sp16a16r5g6b5rev = GT_MODE(GT_RGB, 6, 16, 16) sp16a16b5g6r5 = GT_MODE(GT_RGB, 7, 16, 16) sp16a16b5g6r5rev = GT_MODE(GT_RGB, 8, 16, 16) sp24a8b8g8r8 = GT_MODE(GT_RGB, 1, 8, 24) sp24a8r8g8b8 = GT_MODE(GT_RGB, 2, 8, 24) sp32a32b8g8r8A8 = GT_MODE(GT_RGB, 1, 32, 24) sp32a32b8g8r8A8rev = GT_MODE(GT_RGB, 2, 32, 24) sp32a32r8g8b8A8 = GT_MODE(GT_RGB, 3, 32, 24) sp32a32r8g8b8A8rev = GT_MODE(GT_RGB, 4, 32, 24) Here's how the current graphtypes would be defined : #define GT_1BIT GT_MODE(GT_INDEXED, 0, 0, 1) #define GT_2BIT GT_MODE(GT_INDEXED, 0, 0, 2) #define GT_4BIT GT_MODE(GT_INDEXED, 0, 0, 4) #define GT_8BIT GT_MODE(GT_INDEXED, 0, 0, 8) #define GT_15BIT GT_MODE(GT_RGB, 0, 0, 15) #define GT_16BIT GT_MODE(GT_RGB, 0, 0, 16) #define GT_24BIT GT_MODE(GT_RGB, 0, 8, 24) #define GT_32BIT GT_MODE(GT_RGB, 0, 32, 24) #define GT_TEXT16 GT_MODE(GT_TEXT, 0, 16, 4) #define GT_TEXT32 GT_MODE(GT_TEXT, 0, 32, 4) Cheers ! _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Wed Jun 24 22:20:04 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA23602; Wed, 24 Jun 1998 22:20:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA19145; Wed, 24 Jun 1998 22:12:42 -0700 Resent-Date: Wed, 24 Jun 1998 22:12:42 -0700 Date: Thu, 25 Jun 1998 01:10:52 -0400 (EDT) From: "James M. J. Cassidy" X-Sender: jcassidy@mice To: GGI Development Subject: File permissions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"sRs8v1.0.xg4.9nTar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3044 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I've completely re-downloaded the devel tree from the CVS mirror. And the executable scripts don't appear to have the execute bit set. Same problem with the snapshots. I assume they are being taken from the mirror too, because when guest access was open on the main server I didn't have that problem. This isn't a big deal, but still annoying to have to go through set the execute bit manually :) -- Quantum Fire From ggi-develop-request@eskimo.com Wed Jun 24 23:12:23 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA23622; Wed, 24 Jun 1998 23:12:21 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA00779; Wed, 24 Jun 1998 23:09:49 -0700 Resent-Date: Wed, 24 Jun 1998 23:09:49 -0700 Date: Wed, 24 Jun 1998 23:09:06 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: Input drivers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"5_iW51.0.2C.icUar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3045 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com What is the situation with input drivers? I see nmouse.c in os/Linux/linux/drivers/console, which appears in the Linux kernel make config system's GGI console subsection as the serial mouse driver option. I also see os/Linux/input/[joystick,mouse], which contains drivers for serial mouse, ps2 mouse, mouse acceleration, normal joysticks and SpaceOrbs. There does not appear to be any link between this directory and the rest of Degas at present |-<. Also, the drivers should properly be located in drivers/console where the nmouse driver is right now, IMHO. I therefore propose that the input/ directory be moved to drivers/console, that the nmouse driver be put back into input/ for consistency's sake, and that options for these five drivers be added to the current GGI console Linux kernel config menu. I don't know how much work it will take to get the other drivers working properly, but it shouldn't be much. I will do this task myself if people think it is OK. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Wed Jun 24 23:48:58 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA23631; Wed, 24 Jun 1998 23:48:56 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA05790; Wed, 24 Jun 1998 23:41:18 -0700 Resent-Date: Wed, 24 Jun 1998 23:41:18 -0700 Date: Wed, 24 Jun 1998 23:40:34 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: EvStack-like discussion on linux-kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"24_IO2.0.MQ1.D4Var"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3046 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Right now there is a discussion going on in linux-kernel related to implementing 'uniform device input packets' which bears a striking resemblance to EvStack. I have mentioned EvStack a few times and a couple of people said they'd check it out. Those EvStack hackers on the list might want to have a look at that discussion.... Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Thu Jun 25 02:22:39 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA23862; Thu, 25 Jun 1998 02:22:37 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id CAA18642; Thu, 25 Jun 1998 02:12:20 -0700 (PDT) Resent-Date: Thu, 25 Jun 1998 02:12:20 -0700 (PDT) Date: Thu, 25 Jun 1998 11:01:34 +0200 (MET DST) From: Andre Werthmann To: ggi-develop@eskimo.com Subject: MPEG-Hardware Decoder Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"DSWax.0.9Z4.oHXar"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3047 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Is there a way to include support of an MPEG-Hardware-Decoder ? I own a ELSA-Motion (PCI) with the IIT-MPP Video-CPU. This chip doesn't use any DMA-channel. It uses an IRQ and an IO-port. It also uses 4*64kB Non-prefetchable 32 bit Memory. Anyone knows how to create drivers for it ? I even could send my Card out for testing (in Germany). From ggi-develop-request@eskimo.com Thu Jun 25 02:26:41 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA23869; Thu, 25 Jun 1998 02:26:39 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id CAA31955; Thu, 25 Jun 1998 02:22:54 -0700 Resent-Date: Thu, 25 Jun 1998 02:22:54 -0700 Sender: core@orb.suntech.fr Message-ID: <359216A8.B6742B1A@suntech.fr> Date: Thu, 25 Jun 1998 09:21:44 +0000 From: Emmanuel Marty Reply-To: core@suntech.fr Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: fbcon in the standard kernel (2.1.107) ! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"1ENl4.0._o7.jRXar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3048 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all, Andrew and I just got e-mail from Geert Uytterhoeven informing us that Linus applied Geert's very good "abstract consoles" subsystem, and my humble fbcon patches and improvements, to the standard kernel. Just download patch-2.1.107 from kernel.org and grep for ggi-project :) *very proud* What this means is that _today_, GGI applications can already run (through the fbcon target) fullscreen, using the vesafb framebuffer device, on a _standard_ kernel ! (with abstract consoles activated, but I'm sure Debian and RedHat will propose (at least as an alternative) a kernel defaulting to that soon, because it's the right approach, and Linus says so). And as for "tomorrow", once the KGI-fbcon wrapper is tackled (Andrew, what's the status? Do you need help ? We need it running soon now :), non-suid graphics will be possible on a stock kernel, not just using VESA but will full performance through our KGI drivers, just like under KGI - except no kernel patching or anything will be necessary, just compile and run ! This is _very good_ news for us, and even more, for GGI applications developers. It's a motivation to work twice as hard. Geert, Alan, Jes : you kept the promise of advocating it, and proved (if that was ever necessary) that you are trustable persons. Thanks ! Linus, if you ever read this, thanks as much :) -- Emmanuel From ggi-develop-request@eskimo.com Thu Jun 25 03:57:26 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA23921; Thu, 25 Jun 1998 03:57:25 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id DAA09472; Thu, 25 Jun 1998 03:54:18 -0700 Resent-Date: Thu, 25 Jun 1998 03:54:18 -0700 Message-ID: From: Paul Sargent To: "'andreas.beck@ggi-project.org'" Cc: "'ggi-develop@eskimo.com'" Subject: RE: 3Dlabs drivers Date: Thu, 25 Jun 1998 11:40:12 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"mi4LF.0.uJ2.PnYar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3049 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I don't think there are any problems (i.e. no AGP specific Code), but I haven't actually gone and tried it because I haven't got an AGP Linux Box :-( >-----Original Message----- >From: becka@rz.uni-duesseldorf.de [SMTP:becka@rz.uni-duesseldorf.de] >Sent: Wednesday, June 24, 1998 8:54 PM >To: ggi-develop@eskimo.com >Subject: Re: 3Dlabs drivers > >Hi ! > >> this is just to inform you that I will be allowed to release 3Dlabs >> driver sources after approval by 3Dlabs. We have to check out the >> details, but basically I got permission to publish them. > >Great - so I'm safe to buy myself a ELSA Winner 2000 Office AGP 8MB ? > >Or is there any catch to watch out for (like AGP doesn't work or something >like that ...) ? > >CU,ANdy > >-- >= Andreas Beck | Email : >= > From ggi-develop-request@eskimo.com Thu Jun 25 05:00:33 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA23941; Thu, 25 Jun 1998 05:00:27 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA17487; Thu, 25 Jun 1998 04:49:05 -0700 Resent-Date: Thu, 25 Jun 1998 04:49:05 -0700 Sender: torgeir@eskimo.com Message-ID: <3592544C.572DC092@vertech.no> Date: Thu, 25 Jun 1998 13:44:44 +0000 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i686) MIME-Version: 1.0 To: Linux GGI Subject: [Fwd: Uniform input - mailing list created] Content-Type: multipart/mixed; boundary="------------DBD7B6F1550212F4DA37F428" Resent-Message-ID: <"Tvkj4.0.6H4.maZar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3050 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This is a multi-part message in MIME format. --------------DBD7B6F1550212F4DA37F428 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Torgeir Veimo, Vertech AS, email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 --------------DBD7B6F1550212F4DA37F428 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Delivered-To: vertech-torgeir.veimo@vertech.no Received: (qmail 3075 invoked from network); 25 Jun 1998 13:38:52 -0000 Received: from sabre-wulf.nvg.ntnu.no (root@129.241.210.67) by 195.204.179.10 with SMTP; 25 Jun 1998 13:38:52 -0000 Received: from vger.rutgers.edu ([128.6.190.2] EHLO vger.rutgers.edu ident: root [port 12605]) by sabre-wulf.nvg.ntnu.no with ESMTP id <49473-4423>; Thu, 25 Jun 1998 13:30:44 +0200 Received: by vger.rutgers.edu id <971949-22453>; Thu, 25 Jun 1998 05:11:43 -0400 Received: from slip4.ms.mff.cuni.cz ([195.113.20.204]:3975 "EHLO twilight.ucw.cz" ident: "vojtech") by vger.rutgers.edu with ESMTP id <971967-22453>; Thu, 25 Jun 1998 05:06:45 -0400 Received: (from vojtech@localhost) by twilight.ucw.cz (8.8.5/8.8.5) id LAA06335; Thu, 25 Jun 1998 11:28:35 +0200 Message-ID: <19980625112835.29352@twilight.ucw.cz> Date: Thu, 25 Jun 1998 11:28:35 +0200 From: Vojtech Pavlik To: Mathieu Bouchard Cc: linux-kernel@vger.rutgers.edu, pavel@ucw.cz, short@ucw.cz, vojtech@ucw.cz, bsc@fleggaard.dk, jem@vistacom.fi, dossy@panoptic.com, artdodge@cs.bu.edu, root@jennifer-unix.dyn.ml.org Subject: Re: Uniform input - mailing list created References: <19980625091111.28920@twilight.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from Mathieu Bouchard on Thu, Jun 25, 1998 at 04:48:33AM -0400 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu On Thu, Jun 25, 1998 at 04:48:33AM -0400, Mathieu Bouchard wrote: > excellent, would allow me to drop the linux-kernel mailing list, because > I'm supposed to have more important concerns right now than working on > the kernel or even reading about it. if i could participate in the kernel > without having to get the linux-kernel mailing list it would be great. > Also, the linux-kernel manager should keep a list of all revolving > mailing-lists (might be already existing, i do not remember reading the > whole faq), and try to reduce the volume in the main mailing-list by > directing those specific discussions away. this should be done with any > thread that lasts over one month or is going to last over one month, one > month being a silly constant. Okay, the linux-input@atrey.karlin.mff.cuni.cz mailing list has been created. To subscribe to it, send a mail message with any subject and with one line body containing subscribe linux-input Your Name to listproc@atrey.karlin.mff.cuni.cz Have fun! Vojtech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu --------------DBD7B6F1550212F4DA37F428-- From ggi-develop-request@eskimo.com Thu Jun 25 05:12:23 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA23960; Thu, 25 Jun 1998 05:12:21 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA19798; Thu, 25 Jun 1998 05:08:27 -0700 Resent-Date: Thu, 25 Jun 1998 05:08:27 -0700 From: Andrew Apted Message-ID: <19980625202051.61251@ajax.netspace.net.au> Date: Thu, 25 Jun 1998 20:20:51 +1000 To: ggi-develop@eskimo.com Subject: Re: Input drivers Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Jon M. Taylor on Wed, Jun 24, 1998 at 11:09:06PM -0700 Resent-Message-ID: <"1WZ4d.0.Cr4.wsZar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3051 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon M. Taylor writes: > What is the situation with input drivers? The input drivers were being maintained by me, but right now I've lacking a VGA monitor (it blew up fairly recently :-() so I'm pretty stuffed. I really want to work on EvStack and KGI+fbdev and LibGGI and ... but it's just no good when all I've got is MDA. *sigh* > I also see os/Linux/input/[joystick,mouse], which contains drivers for > serial mouse, ps2 mouse, mouse acceleration, normal joysticks and > SpaceOrbs. There does not appear to be any link between this directory > and the rest of Degas at present |-<. Also, the drivers should properly > be located in drivers/console where the nmouse driver is right now, IMHO. Nmouse.c isn't the actual serial mouse driver(s), it is just the glue layer which allows multible serial-parsing beasties to all share the kernel's single N_MOUSE line discipline. So it doesn't really belong in the input/ directory with the actual drivers IMHO. > I therefore propose that the input/ directory be moved to > drivers/console OK with me. > I don't know how much > work it will take to get the other drivers working properly, but it > shouldn't be much. I will do this task myself if people think it is OK. Yeah, should be easy. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Thu Jun 25 05:23:13 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA23966; Thu, 25 Jun 1998 05:23:12 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id FAA29115; Thu, 25 Jun 1998 05:15:56 -0700 (PDT) Resent-Date: Thu, 25 Jun 1998 05:15:56 -0700 (PDT) From: Andrew Apted Message-ID: <19980625220251.14468@ajax.netspace.net.au> Date: Thu, 25 Jun 1998 22:02:51 +1000 To: ggi-develop@eskimo.com Subject: Re: fbcon in the standard kernel (2.1.107) ! Reply-To: ggi-develop@eskimo.com References: <359216A8.B6742B1A@suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <359216A8.B6742B1A@suntech.fr>; from Emmanuel Marty on Thu, Jun 25, 1998 at 09:21:44AM +0000 Resent-Message-ID: <"I9iM01.0.n67.wzZar"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3052 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! Emmanuel writes: > Andrew and I just got e-mail from Geert Uytterhoeven informing us that Linus > applied Geert's very good "abstract consoles" subsystem, and my humble fbcon > patches and improvements, to the standard kernel. Just download patch-2.1.107 > from kernel.org and grep for ggi-project :) *very proud* Wow ! (My message just said something about a patch being applied...) > And as for "tomorrow", once the KGI-fbcon wrapper is tackled (Andrew, > what's the status? Do you need help ? We need it running soon now :), Sorry, no further progress. My VGA monitor died on me... > non-suid graphics will be possible on a stock kernel, not just using > VESA but will full performance through The "non-suid" is a problem. There are some kernel ioctls that need root permission (especially VT_ACTIVATE), but hopefully this'll be pretty straightforward to fix... Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Thu Jun 25 06:20:25 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA24011; Thu, 25 Jun 1998 06:20:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA00758; Thu, 25 Jun 1998 06:19:48 -0700 Resent-Date: Thu, 25 Jun 1998 06:19:48 -0700 Date: Thu, 25 Jun 1998 15:21:15 +0200 (DFT) From: Massimiliano Ghilardi To: ggi-develop@eskimo.com Subject: Re: fbcon in the standard kernel (2.1.107) ! In-Reply-To: <19980625220251.14468@ajax.netspace.net.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cRUu01.0.hB.pvaar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3053 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 25 Jun 1998, Andrew Apted wrote: > The "non-suid" is a problem. There are some kernel ioctls that need > root permission (especially VT_ACTIVATE), but hopefully this'll be > pretty straightforward to fix... Well, this is plain false actually. I am running on an old, stock 2.0.33 and this is part of the strace of "chvt 2" ran from tty1: geteuid() = 501 getuid() = 501 getgid() = 100 getegid() = 100 open("/dev/console", O_RDONLY) = 3 ioctl(3, VT_ACTIVATE, 0x2) = 0 ioctl(3, VT_WAITACTIVE, 0x2) = 0 So no suid is needed. One thing I noticed is that a process can request "switch from my VC to another" but if requests "switch to my VC" the kernel refuses. This is a really good thing in my opinion as it avoids sneaky programs which grab the focus, fool the user by reproducing the look&feel of, say, /sbin/getty and steal your password. Massimiliano Ghilardi P.S. does ioctl(VT_ACTIVATE) really require root privileges on 2.1.x ? From ggi-develop-request@eskimo.com Thu Jun 25 06:33:27 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA24025; Thu, 25 Jun 1998 06:33:26 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA03635; Thu, 25 Jun 1998 06:32:24 -0700 Resent-Date: Thu, 25 Jun 1998 06:32:24 -0700 Sender: core@orb.suntech.fr Message-ID: <35925125.C414CD73@suntech.fr> Date: Thu, 25 Jun 1998 13:31:17 +0000 From: Emmanuel Marty Reply-To: core@suntech.fr Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fbcon in the standard kernel (2.1.107) ! References: <359216A8.B6742B1A@suntech.fr> <19980625220251.14468@ajax.netspace.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hg3VE1.0.bu.d5bar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3054 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Andrew Apted writes: > Hi ! > > Emmanuel writes: > > > Andrew and I just got e-mail from Geert Uytterhoeven informing us that Linus > > applied Geert's very good "abstract consoles" subsystem, and my humble fbcon > > patches and improvements, to the standard kernel. Just download patch-2.1.107 > > from kernel.org and grep for ggi-project :) *very proud* > > Wow ! (My message just said something about a patch being applied...) Yeah, we got the same, but I browsed through the patch for 2.1.107 and nearly felloff my chair .. When Linus is fast, he's FAST :) > > And as for "tomorrow", once the KGI-fbcon wrapper is tackled (Andrew, > > what's the status? Do you need help ? We need it running soon now :), > > Sorry, no further progress. My VGA monitor died on me... Oi.. We really ought to have it running soon - now that abstract consolesare in the kernel, no excuse :) I infortunately don't have the time at the moment to guarantee its completion, so does anyone on the list want to write it ? Basically it's a replacement for the KGI linux/i386 driver, by a driver that simulates KGI environment under a stock kernel by mapping KGI calls into fbcon calls, and providing stubs for the missing services. The result can either be compiled as a kernel module or directly with the kernel. Any taker ? > The "non-suid" is a problem. There are some kernel ioctls that need > root permission (especially VT_ACTIVATE), but hopefully this'll be > pretty straightforward to fix... IIRC you don't need root privileges to use that particular ioctl(), but I might be wrong.. -- Emmanuel From ggi-develop-request@eskimo.com Thu Jun 25 07:10:16 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA24039; Thu, 25 Jun 1998 07:10:11 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA11654; Thu, 25 Jun 1998 07:01:50 -0700 (PDT) Resent-Date: Thu, 25 Jun 1998 07:01:50 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: libggi open issues Date: 25 Jun 1998 13:58:23 GMT Organization: OnTV Pittsburgh, L.P. Lines: 20 Sender: Jason McMullan Distribution: local Message-ID: <6mtl1v$nl3$1@butter.visus.com> References: <6mrtn6$3i5$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.34 (i586)) Resent-Message-ID: <"Eiou53.0.-r2.BXbar"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3055 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com becka@rz.uni-duesseldorf.de wrote with confidence: > I have been thinking over the VT-switchaway problem, and here is > what came to my mind: > 1. The only clean way to handle asynchronous events like these > is to simply put them into the event queue as COMMAND events. I like the events, by why not make them `Information' events, as they really aren't commands, and we have agreed that command events should not be transmitted out of the kernel... -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Thu Jun 25 09:33:38 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA24227; Thu, 25 Jun 1998 09:33:36 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA24142; Thu, 25 Jun 1998 09:32:46 -0700 Resent-Date: Thu, 25 Jun 1998 09:32:46 -0700 Message-Id: <199806251634.MAA10003@dew.wserv.com> From: "Jordan Mendelson" To: Subject: RE: [Fwd: Uniform input - mailing list created] Date: Thu, 25 Jun 1998 12:32:38 -0400 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3592544C.572DC092@vertech.no> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Resent-Message-ID: <"G9kh61.0.4v5.jkdar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3056 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This all sounds like a clone of EvStacks to me. Anyway, the attachment didn't work for me (maybe my mail program is busted), so just in case: Either the attachment is broken or my mail is.. not sure what, but just in case: Okay, the linux-input@atrey.karlin.mff.cuni.cz mailing list has been created. To subscribe to it, send a mail message with any subject and with one line body containing subscribe linux-input Your Name to listproc@atrey.karlin.mff.cuni.cz Have fun! Vojtech From ggi-develop-request@eskimo.com Thu Jun 25 12:32:37 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA24404; Thu, 25 Jun 1998 12:32:31 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA00854; Thu, 25 Jun 1998 12:27:09 -0700 Resent-Date: Thu, 25 Jun 1998 12:27:09 -0700 Date: Thu, 25 Jun 1998 21:24:23 +0200 (CEST) From: Emmanuel Marty X-Sender: core@core To: ggi-develop@eskimo.com Subject: job offers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"8OFI4.0.BD.BIgar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3057 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all, No, I'm not offering real jobs, but I'm glad you opened this message anyway *grin* The subject isn't a joke though, the following two issues are rather urgent, and need a volunteer to solve them. 1) The KGI wrapper for fbcon This will allow fbcon, which is now (I'll say it again just because I still haven't touched the ground since I received Geert's mail this morning :) part of the standard kernel, to use KGI drivers for rendering. i.e. : USERSPACE | KERNELSPACE | libggi <-> fbcon target <- | -> fbcon <-> KGI driver (I know I have innate talents for ASCII art, shush :P) This isn't either as bad or as complicated as it looks - fbcon adds another 'middle man' in the fullscreen display scheme, but once the KGI driver is registered to fbcon, it is just an extra indirect function call. So that's really a non-issue. It's not really complicated either, it's basically about implementing an fbcon display driver (just like the ton of others that already are in, for m68K displays, vga text etc, just follow their model) and instead of rendering to something, translating the mode requests, palette requests etc into a call into a KGI driver. The wrapper and the KGI driver are linked together at compilation time just like the linux/i386 driver that we all use for KGI-kernel display now. I hope this explanation is clear, please feel free to ask for more information if needed. Andrew J. Apted, who helped with the fbcon kernel bits and wrote the fbcon libggi target - many thanks to him - was also planning to work on the wrapper, but can't due to hardware failure. Geert can't either, he's busy writing an ATI driver (for fbcon) that will also benefit to everyone when the wrapper works. I cannot _guarantee_ that I can at the moment, because I am really out of time. I would love to code that though since I co-originated that interoperability :), but I'll step out to the benefit of the project until I can guarantee to make something working quickly. So, that leads to the question : who wants to write it ? Of course the ideal candidate would know both fbcon and KGI like the back of his hand but there is no such person among us :) Steffen is, as I understand, working on XAA, and Jason McMullan has other priorities in life than computing at the moment which is completely understandable (unless you're back among us, Jason? If so... want to tackle it? *grin*). I would prefer someone from the ggi 'core' team to handle it, but anyone is welcome - yes you lurker, it's time to step out of the dark. About EvStack, and the KGI interface version that the wrapper should conform to : Let's face it, the KGI part of EvStack (or Dali for that matter) will never make it into the main kernel as is, now that fbcon is standard. This is not _necessarily_ a bad thing - of course, the KGI kernel manager is wasted work, but look at what we get instead : a fully functional console (no unmapped keys or whatever) exactly compatible to the original one, and GGI applications working on the standard kernel. With the wrapper, we allow for non-suid graphics too. All effort that has been put into the KGI driver is not lost - they become part of the kernel; or they most definitely will once the wrapper is written. There is nothing opposed to that now. I propose that the KGI wrapper complies to the Dali driver API; the drivers are already here and work. If we begin moving all of that to the EvStack API, it will be a nightmare. I propose we use the Dali API. The notable changes in the evstack one, notably about text management, are handled by fbcon itself anyway. Please everyone comment that and someone volunteer. If there is noone, of course I'll write the darned code, but I would really want someone else to do it :) 2) Hosts for GGI Todd T. Fries will not be able to handle the CVS anonymous traffic forever (plus snapshot generation). And even if he does, it's not fair. So I'm sending a big call to everyone, lurkers included: We need an host with large bandwidth in the USA and another in Europe, to host anonymous CVS mirrors. This is your chance to help us, it will be greatly appreciated. I'll keep the development server, and mirrors will update twice a day as Todd does now, so everything should be fine. If you don't know how to setup a CVS server or a mirror, I can use a temporary telnet access to set it up, but I would really like it better if you did it yourself though :-) Anyone up to that ? (Debian, univs, someone with too much money..?) OK, I'm done with my novel. :) -- Emmanuel From ggi-develop-request@eskimo.com Thu Jun 25 12:49:10 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA24422; Thu, 25 Jun 1998 12:49:06 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA11398; Thu, 25 Jun 1998 12:47:55 -0700 Resent-Date: Thu, 25 Jun 1998 12:47:55 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: libggi open issues To: ggi-develop@eskimo.com Date: Thu, 25 Jun 1998 21:44:24 +0200 (MET DST) In-Reply-To: <199806241603.SAA11193@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at Jun 24, 98 06:03:24 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"YxF96.0.sn2.fbgar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3058 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > One important question is: do we want to make this change now, before the > feature freeze, which could make the july1st-release unstable, or do > we want to make it on july 1st, which might make the july1st release > binary incompatible with the next releases to come? After. The July 1st release will be marked "stable but interface not final". CU,Andy P.S.: My university has major trouble with Mail - please bear with me, when my replies are slow ... I sent myself an Email yesterday which took >4 hours to be delivered _within_ the university. -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Thu Jun 25 12:57:22 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA24440; Thu, 25 Jun 1998 12:57:17 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA12505; Thu, 25 Jun 1998 12:51:49 -0700 Resent-Date: Thu, 25 Jun 1998 12:51:49 -0700 Date: Thu, 25 Jun 1998 21:49:07 +0200 (CEST) From: Emmanuel Marty X-Sender: core@core To: ggi-develop@eskimo.com Subject: Re: CVS mirrors and guest access. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"pfyUm1.0.F33.Jfgar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3059 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello Marcus, > I'm sorry if I was a bit harsh yesterday - I was tired and really needed > to get some sleep before todays work. So I just got annoyed when I > couldn't commit the changes I'd been hacking on for the last four hours. I understand perfectly.. Please forgive me for the rather unnice reply, I had a rather stressful day then as well; I'm working hard on something, and my girlfriend isn't really giving me a break either (when I am upset without apparent reason, you can bet your life that it is related to her :) I hope I haven't offended or worried you, else I'm terribly sorry. > I'm very grateful that we finally got a working CVS > repository again and didn't mean to blame you for anything. Thanks .. And I didn't take it that way, no worries (well I did on the moment but that was rather stupid of me, my apologies again). Now that Todd handles the anonymous CVS traffic, is it working better ? I have stopped watching Unisource packet losses so I wouldn't get depressed, so just let me know your general feeling.. :) -- Emmanuel From ggi-develop-request@eskimo.com Thu Jun 25 13:30:10 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA24476; Thu, 25 Jun 1998 13:30:07 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA28187; Thu, 25 Jun 1998 13:20:39 -0700 Resent-Date: Thu, 25 Jun 1998 13:20:39 -0700 Date: Thu, 25 Jun 1998 21:03:17 +0200 (CEST) From: Emmanuel Marty X-Sender: core@core To: ggi-develop@eskimo.com Subject: Re: CVS mirrors and guest access. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"UoY_F.0.pt6.L4har"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3060 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hello Marcus, > I'm sorry if I was a bit harsh yesterday - I was tired and really needed > to get some sleep before todays work. So I just got annoyed when I > couldn't commit the changes I'd been hacking on for the last four hours. I understand perfectly.. Please forgive me for the rather unnice reply, I had a rather stressful day then as well; I'm working hard on something, and my girlfriend isn't really giving me a break either (when I am upset without apparent reason, you can bet your life that it is related to her :) I hope I haven't offended or worried you, else I'm terribly sorry. > I'm very grateful that we finally got a working CVS > repository again and didn't mean to blame you for anything. Thanks .. And I didn't take it that way, no worries (well I did on the moment but that was rather stupid of me, my apologies again). Now that Todd handles the anonymous CVS traffic, is it working better ? I have stopped watching Unisource packet losses so I wouldn't get depressed, so just let me know your general feeling.. :) -- Emmanuel From ggi-develop-request@eskimo.com Thu Jun 25 13:50:39 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA24512; Thu, 25 Jun 1998 13:50:36 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA09879; Thu, 25 Jun 1998 13:48:29 -0700 Resent-Date: Thu, 25 Jun 1998 13:48:29 -0700 Date: Thu, 25 Jun 1998 22:47:02 +0200 (CEST) From: Geert Uytterhoeven To: Emmanuel Marty cc: ggi-develop@eskimo.com Subject: Re: fbcon in the standard kernel (2.1.107) ! In-Reply-To: <35925125.C414CD73@suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"8vLpd1.0.wP2.OUhar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3061 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com [ It's been a long time ago I read this list, but now I have a good reason ;-] On Thu, 25 Jun 1998, Emmanuel Marty wrote: > Andrew Apted writes: > > Emmanuel writes: > > > > > Andrew and I just got e-mail from Geert Uytterhoeven informing us that Linus > > > applied Geert's very good "abstract consoles" subsystem, and my humble fbcon > > > patches and improvements, to the standard kernel. Just download patch-2.1.107 > > > from kernel.org and grep for ggi-project :) *very proud* > > > > Wow ! (My message just said something about a patch being applied...) > > Yeah, we got the same, but I browsed through the patch for 2.1.107 and nearly > felloff my chair .. When Linus is fast, he's FAST :) Yeah. At the moment I sent that message I hadn't received the 2.1.107 patch yet. > > > And as for "tomorrow", once the KGI-fbcon wrapper is tackled (Andrew, > > > what's the status? Do you need help ? We need it running soon now :), > > > > Sorry, no further progress. My VGA monitor died on me... > > Oi.. We really ought to have it running soon - now that abstract consolesare in the > kernel, no excuse :) There's still some other work to do: Linus decided to put the frame buffer support (CONFIG_FB) in the `experimental' section. This means that all people who disable experimental stuff will get vgacon instead of fbcon/vgafb, causing complaints about the (lack of) speed of the new console. Vgacon uses memcpy, while vgafb uses panning (like the old driver). And there also seems to be some confusion about vgafb vs. vesafb. Text mode frame buffer devices confuse people. Linus mailed me he got reports that vgafb doesn't always work, even if you don't select a graphics(?) mode. Since vgafb and vgacon use the same code to drive the VGA hardware (technically), I find this hard to believe. I guess the reporter actually meant vesafb. Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium From ggi-develop-request@eskimo.com Thu Jun 25 14:33:35 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA24559; Thu, 25 Jun 1998 14:33:31 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA25673; Thu, 25 Jun 1998 14:30:03 -0700 Resent-Date: Thu, 25 Jun 1998 14:30:03 -0700 Date: Thu, 25 Jun 1998 23:27:31 +0200 (CEST) From: Emmanuel Marty X-Sender: core@core To: ggi-develop@eskimo.com Subject: Re: fbcon in the standard kernel (2.1.107) ! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"hHx7N1.0.vG6.P5iar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3062 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com /me kills netscape line wrapping and goes back to pine.. Geert Uytterhoeven wrote: > There's still some other work to do: Linus decided to put the frame buffer > support (CONFIG_FB) in the `experimental' section. This means that all people > who disable experimental stuff will get vgacon instead of fbcon/vgafb, > causing complaints about the (lack of) speed of the new console. Vgacon > uses memcpy, while vgafb uses panning (like the old driver). Yeah - so I noticed. I'm sure he'll fix it when he knows about it though.. devel kernels are unstable anyway, so people shouldn't whine :) Like, since 2.1.104, my scsi board isn't properly driven anymore, I'm silently bugreporting and waiting.. :) Any fbcon (I know it's not the proper way to call the abstract consoles, but give me a shorthand for it then ? abscon? :) developer who would want to tackle the KGI wrapper? I would love to do it, I just can't devote time to do serious work on it now - and I don't want to delay it for everyone. :) Besides such a project, and the scrollback thing, anything you need to see working on fbcon.. err.. abscon? :) I'd have time for smaller fixes here and there for sure. -- Emmanuel From ggi-develop-request@eskimo.com Thu Jun 25 18:55:12 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA24779; Thu, 25 Jun 1998 18:55:11 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA11502; Thu, 25 Jun 1998 18:58:48 -0700 (PDT) Resent-Date: Thu, 25 Jun 1998 18:58:48 -0700 (PDT) X-Authentication-Warning: spudhammer.phys.ttu.edu: zeus owned process doing -bs Date: Thu, 25 Jun 1998 20:48:34 -0500 (CDT) From: taylorcc X-Sender: zeus@spudhammer.phys.ttu.edu Reply-To: taylorcc@arn.net To: ggi-develop@eskimo.com Subject: Re: I have seen the stars... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"s7ObF2.0.cp2.M1mar"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3063 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 24 Jun 1998, Edward S. Marshall wrote: > The minimal package (which doesn't make use of cygwin.dll) would alleviate > both the licensing concern (since things linked against libggi would also > be linked against cygwin.dll, your application is tainted - as would be > libggi...this isn't a trivial point, since the license of libggi is still > a point of some debate) and any concerns over performance degradation > and resources involved with libggi running on a large compatibility > library like Cygnus' DLL. use mingwin32 then. From ggi-develop-request@eskimo.com Thu Jun 25 23:16:55 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA24891; Thu, 25 Jun 1998 23:16:53 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA10687; Thu, 25 Jun 1998 23:13:55 -0700 Resent-Date: Thu, 25 Jun 1998 23:13:55 -0700 From: Andrew Apted Message-ID: <19980626160639.64828@ajax.netspace.net.au> Date: Fri, 26 Jun 1998 16:06:39 +1000 To: ggi-develop@eskimo.com Subject: Re: fbcon in the standard kernel (2.1.107) ! Reply-To: ggi-develop@eskimo.com References: <19980625220251.14468@ajax.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Massimiliano Ghilardi on Thu, Jun 25, 1998 at 03:21:15PM +0200 Resent-Message-ID: <"oTxZU3.0.nc2.Ympar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3064 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Massimiliano Ghilardi writes: > On Thu, 25 Jun 1998, Andrew Apted wrote: > > > The "non-suid" is a problem. There are some kernel ioctls that need > > root permission (especially VT_ACTIVATE), but hopefully this'll be > > pretty straightforward to fix... > > Well, this is plain false actually. I am running on an old, stock 2.0.33 > and this is part of the strace of "chvt 2" ran from tty1: > > [SNIP] > > So no suid is needed. One thing I noticed is that a process can request > "switch from my VC to another" but if requests "switch to my VC" the kernel > refuses. What I want to do is open a *new* console in the fbdev target, then switch to it (like X does). The VT_OPENQRY and the open() succeed, but then the VT_ACTIVATE ioctl fails since I'm not root. Maybe there's something funny (to do with current->tty ? process groups ?) that I should be doing... Anyone know ? Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 26 00:58:22 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA25003; Fri, 26 Jun 1998 00:58:20 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id AAA23797; Fri, 26 Jun 1998 00:45:38 -0700 Resent-Date: Fri, 26 Jun 1998 00:45:38 -0700 From: Hartmut Niemann Message-Id: <199806260745.JAA00383@cip8.e-technik.uni-erlangen.de> Subject: Feature Freeze and release candidates To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Fri, 26 Jun 1998 09:45:34 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"rRdmV1.0.jp5.Y6rar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3065 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! Andy announced 'feature freeze' for yesterday, and (if I understand correctly) is going to postpone the libggi API things until July. So now we have a release candidate in /develcvs. Let's make it as good as we can. For the realease on July 1st, I have some suggestions: we'll get a release or stable (I like the first version :-) tarball on july 1st, when everything from devel is checked into the 'stable' repository and tested (I hope). I suggest that all diffs for bug fixes, that happen in the release tree, are generated not against the day before, but ALWAYS against the 1st-of- release. So to get a most uptodate 'stable' you download one tarball and the latest diff *only*! I don't think we need more than the 1st-of and the latest tarball of this, not megs of almost identical archives. For the next 1st-of, I would like to see a patch against the previous 1st-of, and a new tarball, and then diffing starts against this release. Especially for the month-to-month diffs I would like to see a note about the changes, like for the linux patches on linuxhq. An automatic diffstat run on each diff would be great, so that you can see at a glance where the big differences were. I know it's some paperwork, but I think we should do it. What do you think? Hartmut -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Fri Jun 26 01:31:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA25059; Fri, 26 Jun 1998 01:31:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA29112; Fri, 26 Jun 1998 01:26:22 -0700 Resent-Date: Fri, 26 Jun 1998 01:26:22 -0700 Date: Wed, 17 Jun 1998 22:30:39 +0200 (MEST) From: Matthias Grimrath To: ggi-develop@eskimo.com Subject: KGI driver debug tools Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"J9utU1.0.m67.jirar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3066 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! I have made some debugging tools which helped me a lot to find bugs in my driver. I'm pretty sure every driver writer here has coded similiar programs. As a maintainer, it would help me very much if I could answer to an incoming bug report "run the small debug tool and send the output to me". These tools are highly chipset specific, so they need not be very useful for other cards. So I propose to create a directory kgi/driver/debug. In this dir are subdirs named after vendors, like S3, IBM, general, Matrox, etc... In this vendor directories a driver maintainer may put his debuging tools. Comments? Matthias Grimrath From ggi-develop-request@eskimo.com Fri Jun 26 01:54:37 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA25085; Fri, 26 Jun 1998 01:54:34 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA29791; Fri, 26 Jun 1998 01:39:58 -0700 Resent-Date: Fri, 26 Jun 1998 01:39:58 -0700 Date: Thu, 18 Jun 1998 00:39:44 +0200 (MEST) From: Matthias Grimrath To: ggi-develop@eskimo.com Subject: GGI datatypes (was RE: Request for system information.) In-Reply-To: <199806151455.KAA17230@dew.wserv.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"sgNLO1.0.NH7.Tvrar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3067 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 15 Jun 1998, Jordan Mendelson wrote: > > > gcc version 2.7.2.1 > > > > > > Why don't you just use, when __gcc__ is defined, the following: > > > > > > typedef int myshort __attribute__ ((mode(HI)); > > > typedef int myint __attribute__ ((mode(SI)); > > > typedef int mylonglong __attribute__ ((mode(DI)); > > > > > > Should be easier :) > > > > Hmm, HI=HalfInt, SI=SingleInt and DI=DoubleInt ? > > Is this guaranteed to work on all platforms gcc is available on? > > Even it int != 32 bits ? > > I double checked and POSIX 1003.1g does seem to define the types u_int#_t > and int#_t (u_int32_t for example). These seem to be in both Glibc and Hjl > Libc on Linux. I assume that any POSIX compliant OS would have them as well. > POSIX 1003.1g if memory serves deals mainly with socket programming, but > since the types *ARE* defined... we might as well use them. > > They should be in or Now that POSIX defines datatypes of certain sizes, isn't it time to abandon all GGI specific types, like ggi_uint16? I mean, why not use what IS defined than actually define something new of our own? Matthias Grimrath From ggi-develop-request@eskimo.com Fri Jun 26 03:42:46 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA25155; Fri, 26 Jun 1998 03:42:44 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id DAA06696; Fri, 26 Jun 1998 03:29:36 -0700 (PDT) Resent-Date: Fri, 26 Jun 1998 03:29:36 -0700 (PDT) Sender: core@orb.suntech.fr Message-ID: <35937624.1EFF177C@suntech.fr> Date: Fri, 26 Jun 1998 10:21:24 +0000 From: Emmanuel Marty Reply-To: core@suntech.fr Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: GGI datatypes (was RE: Request for system information.) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uN502.0.Ue1.EWtar"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3068 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Matthias Grimrath wrote: > Now that POSIX defines datatypes of certain sizes, isn't it time to abandon > all GGI specific types, like ggi_uint16? I mean, why not use what IS > defined than actually define something new of our own? These datatypes (u_int32_t for example) are defined on my linux boxes, but thatdoesn't mean they are everywhere - yet. I'll change ggi/types.h, so that if the types are defined, it makes use of them, then if __gnuc__ is defined, it uses the handy gcc typedef 'mode' attribute in order to specify the size (after checking gcc documentation, they *are* guaranteed to be of the size you specify), and neither are defined, it'll use the current arch definitions. Any objection to that ? -- Emmanuel From ggi-develop-request@eskimo.com Fri Jun 26 07:57:54 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA25351; Fri, 26 Jun 1998 07:57:43 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA25898; Fri, 26 Jun 1998 07:33:54 -0700 Resent-Date: Fri, 26 Jun 1998 07:33:54 -0700 Date: Fri, 26 Jun 1998 10:33:54 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: KGI driver debug tools In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"TtfC12.0.WK6.H5xar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3069 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, 17 Jun 1998, Matthias Grimrath wrote: > So I propose to create a directory kgi/driver/debug. In this dir are > subdirs named after vendors, like S3, IBM, general, Matrox, etc... In this > vendor directories a driver maintainer may put his debuging tools. I have utilities like this as well, so this might be nice. Also, I'm accumulating quite the set of driver-related documentation files; I haven't actually looked for a doc/kgi/driver directory yet but we should have one if we don't; I have too much to be cluttering the driver code directory with. My spin on driver docs is that sgml sources go in doc/kgi/driver and anything important relating to compiling/inserting/coding the driver have a ASCII runoff made and placed in the driver directory for easy access. The text file(s) in the driver directory would be: 1) Description of available makefile targets and #define options. 2) Pointers on system configuration and inserting module. 3) The TODO list. And the /doc/ directory would contain all of this in sgml plus stuff like: 1) Thorough description of insmod options and system configuration issues, e.g. multi-adaptor cross compatibility and tested chipsets. 2) Technical notes on the driver code. 3) A sort of VGADOC addendum noting things the developer has discovered about the chipset; URLs to technical references, etc. 4) Benchmark results 5) Addresses to which to mail beer. ...and whatever else. -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 26 07:58:45 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA25356; Fri, 26 Jun 1998 07:58:43 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA28442; Fri, 26 Jun 1998 07:44:37 -0700 Resent-Date: Fri, 26 Jun 1998 07:44:37 -0700 Date: Fri, 26 Jun 1998 10:44:34 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: GGI datatypes (was RE: Request for system information.) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"DNPrf3.0.Iy6.KFxar"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3070 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 18 Jun 1998, Matthias Grimrath wrote: > Now that POSIX defines datatypes of certain sizes, isn't it time to abandon > all GGI specific types, like ggi_uint16? I mean, why not use what IS > defined than actually define something new of our own? Are you saying that all the operating systems we will want to compile libggi/kgi on have a common set of types that are all the same length on each and every operating system/architecture? We need these typedefs, IMO, and we shouldn't mess with typedefs that are already there. So we should have ggi_uint8 or ggi_u8, we should decide which it will be, soon, and the decision should be final, and maybe for once I won't have to create a temporary_hacks.h to define these myself because someone decided they looked ugly and changed them. -- Brian S. Julin From ggi-develop-request@eskimo.com Fri Jun 26 11:40:27 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA25584; Fri, 26 Jun 1998 11:40:23 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA03425; Fri, 26 Jun 1998 11:30:34 -0700 Resent-Date: Fri, 26 Jun 1998 11:30:34 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: libggi open issues To: ggi-develop@eskimo.com (mailing list GGI) Date: Fri, 26 Jun 1998 19:46:39 +0200 (MET DST) In-Reply-To: <6mtl1v$nl3$1@butter.visus.com> from "Jason McMullan" at Jun 25, 98 01:58:23 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"hfSxH3.0.Cr.7Z-ar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3071 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > I have been thinking over the VT-switchaway problem, and here is > > what came to my mind: > > 1. The only clean way to handle asynchronous events like these > > is to simply put them into the event queue as COMMAND events. > > I like the events, by why not make them `Information' events, > as they really aren't commands, and we have agreed that command > events should not be transmitted out of the kernel... *grin* This is why I thought, we could easily "recycle" them :-). CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 26 11:41:47 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA25589; Fri, 26 Jun 1998 11:41:44 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA03548; Fri, 26 Jun 1998 11:31:00 -0700 Resent-Date: Fri, 26 Jun 1998 11:31:00 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: MPEG-Hardware Decoder To: ggi-develop@eskimo.com Date: Fri, 26 Jun 1998 19:59:50 +0200 (MET DST) In-Reply-To: from "Andre Werthmann" at Jun 25, 98 11:01:34 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Pyl_T3.0.Dt.ZZ-ar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3072 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Is there a way to include support of an MPEG-Hardware-Decoder ? There is no theoretical limit that would exclude that ... > I own a ELSA-Motion (PCI) with the IIT-MPP Video-CPU. > This chip doesn't use any DMA-channel. > It uses an IRQ and an IO-port. > It also uses 4*64kB Non-prefetchable 32 bit Memory. So I assume you have the programming information ? In that case writing the necessary code should be trivial for you ... We will surely try to help you integrating it to KGI when it runs. CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 26 12:57:01 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA25649; Fri, 26 Jun 1998 12:56:59 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA02670; Fri, 26 Jun 1998 12:48:51 -0700 Resent-Date: Fri, 26 Jun 1998 12:48:51 -0700 Message-Id: <199806261947.VAA21345@sun1.muenchen-land.baynet.de> From: "Erich Schubert" To: ggi-develop@eskimo.com Date: Fri, 26 Jun 1998 21:45:30 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: libggi open issues Reply-to: erich.schubert@gmx.net Priority: normal In-reply-to: <199806241603.SAA11193@cip8.e-technik.uni-erlangen.de> References: <3590D085.C3F2EDD5@e.kth.se> from "Marcus Sundberg" at Jun 24, 98 12:10:13 pm X-mailer: Pegasus Mail for Win32 (v3.01a) Resent-Message-ID: <"9CwC62.0.Pf.Xi_ar"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3073 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > bits 7-0 contain the bits per pixel actually used, > this means: padding bits are not counted, a 15 bpp mode has 15 here. > I would like to suggest to count the number of *foreground colours* > possible, which makes most text modes ==4. Where do you put blinking? To take the number of foreground colours is ok. But you might want to say, the standard VGA Textmode is 1 bpp + 2 attributes. Well you have the basic 8 colors, and the attributes highlight and blink. Some cards might also have underline or something like this. Just think of this, your idea is more practicable, but someone might find a even better one. and i'm too unexperienced. c'Ya Erich From ggi-develop-request@eskimo.com Fri Jun 26 14:17:18 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA25746; Fri, 26 Jun 1998 14:17:14 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA01665; Fri, 26 Jun 1998 14:06:39 -0700 Resent-Date: Fri, 26 Jun 1998 14:06:39 -0700 Sender: mee@daimi.aau.dk Message-ID: <35940D52.D219C7BA@daimi.aau.dk> Date: Fri, 26 Jun 1998 23:06:26 +0200 From: Martin Eli Erhardsen X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Vararg macros in ggi/debug.h Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"dQteY.0.oP.Ur0br"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3074 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Could everyone please refrain from using vararg macros before having checked that the compiler supports them. They aren't ANSI, and I get syntax errors with the IRIX C compiler In Dali the vararg macros were only used when compiling with GCC, by checking for the __GNUC__ preprocessor symbol. It should be possible to use vararg functions instead. ~/degas/lib/libggi> gmake cc -n32 -Ofast -O3 -IPA -mips4 -woff 1521 -woff 1116 -woff 1185 -woff 1048 -Xcpluscomm -pedantic -I/users/mee/degas/lib/libggi/include -I/users/mee/degas/lib/libggi/../../include -I/users/mee/degas/lib/libggi/../../driver/include -DDEBUG -IPA -DGGICONFFILE=\"TaG1/etc/ggi/libggi.conf\" -c -o init.o init.c "/users/mee/degas/lib/libggi/../../include/ggi/debug.h", line 136: error(1018): expected a ")" #define __DEBUG_MSG(level, format, args...) \ ^ "/users/mee/degas/lib/libggi/../../include/ggi/debug.h", line 145: error(1018): expected a ")" #define ERROR(format, args...) \ ^ "/users/mee/degas/lib/libggi/../../include/ggi/debug.h", line 149: error(1018): expected a ")" #define NOTICE(format, args...) \ ^ "/users/mee/degas/lib/libggi/../../include/ggi/debug.h", line 157: error(1018): expected a ")" #define PASSERT(x, args...) do { } while (0) ^ "/users/mee/degas/lib/libggi/../../include/ggi/debug.h", line 160: error(1018): expected a ")" #define DEBUG0(args...) do { } while (0) ^ "/users/mee/degas/lib/libggi/../../include/ggi/debug.h", line 163: error(1018): expected a ")" #define DEBUG1(args...) do { } while (0) ^ "/users/mee/degas/lib/libggi/../../include/ggi/debug.h", line 166: error(1018): expected a ")" #define DEBUG2(args...) do { } while (0) ^ "/users/mee/degas/lib/libggi/../../include/ggi/debug.h", line 169: error(1018): expected a ")" #define DEBUG3(args...) do { } while (0) ^ "/users/mee/degas/lib/libggi/../../include/ggi/debug.h", line 172: error(1018): expected a ")" #define DEBUG4(args...) do { } while (0) ^ 9 errors detected in the compilation of "init.c". gmake: *** [init.o] Error 2 ~/degas/lib/libggi> From ggi-develop-request@eskimo.com Fri Jun 26 17:29:39 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA25951; Fri, 26 Jun 1998 17:29:37 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id RAA02683; Fri, 26 Jun 1998 17:25:57 -0700 Resent-Date: Fri, 26 Jun 1998 17:25:57 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: KGI driver debug tools To: ggi-develop@eskimo.com Date: Sat, 27 Jun 1998 02:24:21 +0200 (MET DST) In-Reply-To: from "Matthias Grimrath" at Jun 17, 98 10:30:39 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"uQZlN2.0.ff.Jm3br"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3076 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > So I propose to create a directory kgi/driver/debug. In this dir are > subdirs named after vendors, like S3, IBM, general, Matrox, etc... In this > vendor directories a driver maintainer may put his debuging tools. Fine with me, but please wait until after the freeze. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 26 17:32:21 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA25956; Fri, 26 Jun 1998 17:32:19 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id RAA02614; Fri, 26 Jun 1998 17:25:38 -0700 Resent-Date: Fri, 26 Jun 1998 17:25:38 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: GGI datatypes (was RE: Request for system information.) To: ggi-develop@eskimo.com (mailing list GGI) Date: Sat, 27 Jun 1998 02:23:22 +0200 (MET DST) In-Reply-To: <35937624.1EFF177C@suntech.fr> from "Emmanuel Marty" at Jun 26, 98 10:21:24 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"rGvvg2.0.ie.0m3br"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3075 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I'll change ggi/types.h, so that if the types are defined, it makes use of them, > then > if __gnuc__ is defined, it uses the handy gcc typedef 'mode' attribute in order > to specify > the size (after checking gcc documentation, they *are* guaranteed to be of the > size you > specify), and neither are defined, it'll use the current arch definitions. > > Any objection to that ? Fine with me. I consider that a bugfix for "freeze" purposes. CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Fri Jun 26 19:55:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA26042; Fri, 26 Jun 1998 19:55:53 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA15420; Fri, 26 Jun 1998 19:53:03 -0700 Resent-Date: Fri, 26 Jun 1998 19:53:03 -0700 Date: Fri, 26 Jun 1998 22:56:45 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: Emmanuel Marty cc: ggi-develop@eskimo.com Subject: Re: GGI datatypes (was RE: Request for system information.) In-Reply-To: <199806262316.TAA00696@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"_r2CC2.0.qm3.Ew5br"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3077 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 26 Jun 1998, Emmanuel Marty wrote: > Matthias Grimrath wrote: > > > Now that POSIX defines datatypes of certain sizes, isn't it time to abandon > > all GGI specific types, like ggi_uint16? I mean, why not use what IS > > defined than actually define something new of our own? > > These datatypes (u_int32_t for example) are defined on my linux boxes, but > thatdoesn't mean they are everywhere - yet. > > I'll change ggi/types.h, so that if the types are defined, it makes use of them, > then > if __gnuc__ is defined, it uses the handy gcc typedef 'mode' attribute in order > to specify > the size (after checking gcc documentation, they *are* guaranteed to be of the > size you > specify), and neither are defined, it'll use the current arch definitions. > > Any objection to that ? Maybe it might be better to start using them now in the GGI tree, and just have a header file with them on hand (basically the existing ggi/types.h using the POSIX names) that can be conditionally included if the system doesn't have them itself. Shouldn't be too hard to detect it in the configure script, a la autoconf or something ... ... which reminds me, I still need to pull the library detection code from autoconf's AC_CHECK_LIB and fix my detect_library hack in ggi/configure with it. The current detect_library isn't terribly reliable. or strictly correct. -=MenTaLguY=- From ggi-develop-request@eskimo.com Fri Jun 26 20:17:36 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA26059; Fri, 26 Jun 1998 20:17:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id UAA26179; Fri, 26 Jun 1998 20:15:12 -0700 Resent-Date: Fri, 26 Jun 1998 20:15:12 -0700 From: Andrew Apted Message-ID: <19980627131119.08790@ajax.netspace.net.au> Date: Sat, 27 Jun 1998 13:11:19 +1000 To: ggi-develop@eskimo.com Subject: Re: fbcon in the standard kernel (2.1.107) ! Reply-To: ggi-develop@eskimo.com References: <19980625220251.14468@ajax.netspace.net.au> <19980626160639.64828@ajax.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <19980626160639.64828@ajax.netspace.net.au>; from Andrew Apted on Fri, Jun 26, 1998 at 04:06:39PM +1000 Resent-Message-ID: <"VXZ0K2.0.pO6._E6br"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3078 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > So no suid is needed. One thing I noticed is that a process can > > request "switch from my VC to another" but if requests "switch to > > my VC" the kernel refuses. > > What I want to do is open a *new* console in the fbdev target, then > switch to it (like X does). The VT_OPENQRY and the open() succeed, but > then the VT_ACTIVATE ioctl fails since I'm not root. > > Maybe there's something funny (to do with current->tty ? process groups ?) > that I should be doing... Anyone know ? Turns out there is a funky trick to make it work. In order to make a /dev/ttyN file you open become the "controlling tty", you need to be a "session leader". To do this, you need to call "setsid()", but this only works if there is no process in the system with a process group == your PID (including yourself !). Setting the process group via "setpgid()" to your parent's PID seems to work. Jeez ! Anyway, I've got the libggi demo now running non-SUID. I'll send the bugfix patch a.s.a.p. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Fri Jun 26 20:37:38 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA26064; Fri, 26 Jun 1998 20:37:37 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id UAA00232; Fri, 26 Jun 1998 20:32:21 -0700 Resent-Date: Fri, 26 Jun 1998 20:32:21 -0700 Date: Fri, 26 Jun 1998 20:31:51 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: job offers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"oG7sY1.0.P3.3V6br"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3079 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Thu, 25 Jun 1998, Emmanuel Marty wrote: > Hi all, > > No, I'm not offering real jobs, but I'm glad you opened this > message anyway *grin* > > The subject isn't a joke though, the following two issues are rather > urgent, and need a volunteer to solve them. > > 1) The KGI wrapper for fbcon > > This will allow fbcon, which is now (I'll say it again just because > I still haven't touched the ground since I received Geert's mail > this morning :) part of the standard kernel, to use KGI drivers > for rendering. > > i.e. : > > USERSPACE | KERNELSPACE > | > libggi <-> fbcon target <- | -> fbcon <-> KGI driver > > (I know I have innate talents for ASCII art, shush :P) > > This isn't either as bad or as complicated as it looks - fbcon > adds another 'middle man' in the fullscreen display scheme, > but once the KGI driver is registered to fbcon, it is > just an extra indirect function call. So that's really > a non-issue. Sound simple enough. So basically fbcon will be just like a userspace program that requests modes, sets palettes, etc, right? KGI will concern itself with issues of monitor drivers and mode timings. Makes sense to me. I'd like to play with fbcon but my 2.1.107 won't compile yet |-<. From all the griping on linux-kernel, it may be another kernel release or two before it is stable. > So, that leads to the question : who wants to write it ? Of > course the ideal candidate would know both fbcon and KGI like > the back of his hand but there is no such person among us :) > Steffen is, as I understand, working on XAA, In what capacity? Steffen, care to share...? > and Jason McMullan > has other priorities in life than computing at the moment > which is completely understandable (unless you're back among > us, Jason? If so... want to tackle it? *grin*). > > I would prefer someone from the ggi 'core' team to handle it, > but anyone is welcome - yes you lurker, it's time to step > out of the dark. I can give it a shot if you want. It actually doesn't sound too difficult. > About EvStack, and the KGI interface version that the wrapper > should conform to : > > Let's face it, the KGI part of EvStack (or Dali for that matter) > will never make it into the main kernel as is, now that fbcon > is standard. Take away all messaging stuff (EvStack) and the drivers themselves, and what is left of KGI isn't too much. But if we are going to split the KGI video driver layer and its associated drivers away from any console stuff and EvStack, this should be formally decided upon and plans made to modify the repository appropriately (i.e. remove KGI altogether o it is relly going into the kernel proper). Also, IMHO this change would further justify a complete separation of EvStack and GGI into separate projects. > This is not _necessarily_ a bad thing - of course, the KGI > kernel manager is wasted work, but look at what we get instead : > a fully functional console (no unmapped keys or whatever) > exactly compatible to the original one, and GGI applications > working on the standard kernel. With the wrapper, we allow > for non-suid graphics too. What about acceleration, what last I looked was not supported generally by fbcon? AFAIK they have a blit ioctl but that's it. This issue has always been at the heart of the disagreements between GGI and Linus. The current state of accel support in the KGI drivers is largely confined to 2-D stuff that could easily be used by fbcon as it stands now, though. > All effort that has been put into the KGI driver is not lost - > they become part of the kernel; or they most definitely will > once the wrapper is written. There is nothing opposed to > that now. > > I propose that the KGI wrapper complies to the Dali driver API; > the drivers are already here and work. If we begin moving all of > that to the EvStack API, it will be a nightmare. I propose > we use the Dali API. The notable changes in the evstack one, > notably about text management, are handled by fbcon itself > anyway. > > Please everyone comment that and someone volunteer. If there > is noone, of course I'll write the darned code, but I would really > want someone else to do it :) How and where are the current Dali KGI drivers to be integrated into the kernel tree? In devices/video where the fbcon stuff is now? In a separate directory under that? Has Linus said anything about how he wants all this to be organized? For that matter, has Linus even approved this KGI<->fbcon wrapper scheme at all? Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 01:22:25 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA26372; Sat, 27 Jun 1998 01:22:23 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA20337; Sat, 27 Jun 1998 01:19:52 -0700 Resent-Date: Sat, 27 Jun 1998 01:19:52 -0700 Date: Sat, 27 Jun 1998 01:19:26 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: Future of GGI project Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"oytvj3.0.fz4.diAbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3080 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Lotta stuff has been happening lately: Recently on linux-kernel the Linux Uniform Input Device project, which shares a lot of ideas with EvStack, was created. The idea of abstract message-passing protocols which EvStack pioneered seems to have caught on bigtime. A mailing list has been created on vger for this project. EvStack has a lot to potentially offer this project, I feel. EvStack has been talked about a bit but no one spoke to them so they went off on their own, and I fear that they might in their ignorance come up with a scheme that is inferior to the greatness that is EvStack |->. Also in kernel 2.1.107, fbcon was brought in to the standard linux kernel. This means that the fbcon interface (8/15/16/24/32bpp linear framebuffers, palettes, textual console abstraction, fonts, rectangular blits and superbitmaps) is what we *have* to work with. There already exists an fbcon LibGGI target, and I am writing a wrapper layer for KGI to bridge it to fbcon as well. This will enable anyone to use fbcon with any of the current KGI drivers and everything in fbcon that can be accelerated will be. Also the KGI console and KGI input device subsections will be transferred to EvStack, leaving KGI as a 'pure' graphics driver interface. Emmanuel thinks, and I agree, that this might finally get KGI accepted into the standard kernel. We're not gonna get all the accelerations we wanted, but you gotta compromise sometime.... Lastly, there's LibGGI. It has many targets and supported platforms right now, and Win16/Win32 compatibility is not far off. A DirectX wrapper for LibGGI is being written. it is being extended into windowing toolkits, graphics file formats, 2d and 3d acceleration, OpenGL, network graphics, and all of it cross-platform and completely open. It could very well turn into the Java of graphics APIs. All of this turmoil needs to be resolved. The idea of splitting up the GGI project has been proposed in the past, by myself and others, but I feel I need to bring it up again in light of the current situation. I feel that the current chaos *cries* out for this solution. With the loss of input devices and consoles, KGI will be pretty disjoint from EvStack, and with the way that KGI and EvStack are becoming extensions of Linux (and FreeBSD, hopefully), the overlap between the three major parts o the GGI project are now almost completely disjoint from each other. Having all this crammed into one source and documentation tree with all the sources wittingly and unwittingly stepping all over each other's toes, having to have an integrated makefile system for all this, entagled header dependencies, conflicts between ANSI C (which LibGGI likes) and wacko Linux kernel gcc non-ANSI-isms, and just plain inefficiency. We have three *wonderful* ideas here, but they are holding each other back. We should have separate Web pages, FAQs, CVS trees, and mailing lists. Of course there would be some of us that would subscribe to more than one, and there would be crossposted discussions as needed like other newsgroups, but overall each project would lead a day-to-day existence separated from each other. Less mailing list traffic, less CVS bandwidth, less website traffic, less documentation, smaller and simpler source trees, more tightly-knit developer community, etc etc etc. Also, our message would not be as muddled as is it is right now and our good ideas would stand a better chance of being heard. www.evstack-project.org, www.kgi-project.org, www.libggi-project.org. Simple, no? I know this is a lot to swallow, but I have thought it over and I honestly think it would be best for all concerned. What do you all think? I will of course stay with GGI no matter what it is called or how it is organized, but I long for the simplicity and efficiency of smaller, more cleanly targeted projects. I even volunteer to maintain KGI's CVS systems, web pages, and FAQs as well as my own S3 drivers and the fbcon bridge. I have no server space though |-<. Anyway, let me know what you all think. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 01:55:26 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA26406; Sat, 27 Jun 1998 01:55:24 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA25092; Sat, 27 Jun 1998 01:51:11 -0700 Resent-Date: Sat, 27 Jun 1998 01:51:11 -0700 Date: Sat, 27 Jun 1998 01:50:44 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: fbcon-KGI bridge Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"G30Qd2.0.x76.-9Bbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3081 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I have begun looking into this, and will require ripping KGI apart to implement properly. The KGI input device and console subsystems have to be disentangled from the video driver subsystem. The input driver stuff will probebly end up in EvStack, but the console handler has been superceded by fbcon which went into the standard kernel in 2.1.107 and is now the standard with which KGI will have to work. I have in mind taking the stripped-down KGI code and drivers from Dali and laying it out in the existing Linux kernel tree thusly: driver/video/fbcon-kgi.c driver/video/kgi driver/video/kgi/kgi.c driver/video/kgi/drivers driver/video/kgi/drivers/i386 driver/video/kgi/drivers/i386/chipset driver/video/kgi/drivers/sbus driver/video/kgi/drivers/amiga driver/video/kgi/drivers/sbus The Linux configuration system would be extended by grafting the current KGI Makefile system in under it. If the user selects fbcon with KGI driver, they can enter the KGI make subsystem, do their business and return to the rest of the config system transparently. There are still some conflicts between KGI and fbcon though. First is that non-x86 architectures still use direct fbcon drivers and not KGI drivers. I hope to be able to convince people that the KGI subsystem is so much cleaner and more modular than the current fbcon layout that they should move their drivers into KGI, but I don't see that happening before KGI proves itself with the current x86 drivers, which I have no doubt it will do. The only thing that sucks about possibly getting into the main Linux source tree is that we'll have to give up CVS and start sending Linus patches like everyone else does |-<. Oh well. I would like it an awful lot if we could hit the decks running with KGI and 2.3 and get KGI into the kernel right away. I would like it if I could get together Geert, Alan, Linus and everyone with the GGI project who has worked, is working or will work on KGI-fbcon-kernel issues and finally get this damn issue dealt with. The presence of the console and input device code in KGI-Dali was a major factor in turning Linus off KGI last go-around. Maybe he will be in a better mood to listen if we present him with a simple, small video driver subsystem and makefile integration to go with it that he can drop right into his tree and it works seamlessly with the existing console. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 04:12:22 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA26495; Sat, 27 Jun 1998 04:12:20 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA01347; Sat, 27 Jun 1998 04:02:19 -0700 Resent-Date: Sat, 27 Jun 1998 04:02:19 -0700 Sender: torgeir@eskimo.com Message-ID: <3594D0A4.1AB5C136@vertech.no> Date: Sat, 27 Jun 1998 12:59:48 +0200 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.1.104 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"DAsdt.0.rK.v4Dbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3082 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon M. Taylor wrote: > > Maybe he will be in a better mood to listen > if we present him with a simple, small video driver subsystem and > makefile integration to go with it that he can drop right into his tree > and it works seamlessly with the existing console. I argue that we should depend on an external development environment in any case for several reasons: One optimally shouldn't have to make a kernel to compile drivers. For the first time we have a resonable interface for graphics which makes it possible to separate the drivers from the kernel distribution. Keeping driver development in a separate development environment will also ensure that they don't depend on linux-kernel in any way. Some basic drivers belongs in the kernel, such as vgafb and vesafb. But as long as it is possible to both insmod and rmmod a graphic driver, these are the only one that really belong in the kernel distribution. -- -Torgeir From ggi-develop-request@eskimo.com Sat Jun 27 04:19:47 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA26504; Sat, 27 Jun 1998 04:19:45 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA02444; Sat, 27 Jun 1998 04:16:52 -0700 Resent-Date: Sat, 27 Jun 1998 04:16:52 -0700 Sender: torgeir@eskimo.com Message-ID: <3594D413.17546C54@vertech.no> Date: Sat, 27 Jun 1998 13:14:27 +0200 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.1.104 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Future of GGI project References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-6bcI2.0.4c.ZIDbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3083 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon M. Taylor wrote: > > We're not gonna get all the accelerations we > wanted, but you gotta compromise sometime.... We'll eventually get all the acceleration we need... ;) > All of this turmoil needs to be resolved. The idea of splitting > up the GGI project has been proposed in the past, by myself and others, > but I feel I need to bring it up again in light of the current situation. I agree with the sentiment that it is healthy to rething everything one in a while. I also feel console issues are orthogonal to the issue of graphics drivers, even if a console system done The Right Way needs things that only ggi provides. I think separating the graphic drivers, the thing we usually call kgi, is healthy in many ways. But I don't think it is possible to completely separate the development of libggi and kgi, since a complete driver depends on both. Thomas presented an idea a while back with a 'new' libggi system, which dealt with the interoperation between the kgi part of a driver and the userland-library part of the driver more than with the api nature of libggi. I think it would be healthy to experiment more with a system which includes both kgi and a userland library to come up with a system on which it is possible to do driver development independent on what api libggi exports. This system would only deal with how acceleration commands flow between the library, kgi and the graphics card, and would be usefull when developing an accelerated Mesa library, normal libggi, libggi2D, libggi3D etc. (insert favourite library here..) It would also deal with 'driver loading'. Experimentation with such a system could be done in parallell with the development of the current libggi, since the goals they present are orthogonal. Once a better lib <-> kgi interaction system is developed, libggi would make use of it, transparent to apps developed using libggi. Thomas and others, what do you think? -- -Torgeir From ggi-develop-request@eskimo.com Sat Jun 27 06:08:59 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA26592; Sat, 27 Jun 1998 06:08:57 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA09506; Sat, 27 Jun 1998 06:06:54 -0700 Resent-Date: Sat, 27 Jun 1998 06:06:54 -0700 Sender: core@orb.suntech.fr Message-ID: <3594ED7F.F72D7B32@suntech.fr> Date: Sat, 27 Jun 1998 13:02:55 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"tkN9J2.0.PK2.kvEbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3086 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon M. Taylor wrote: > I have begun looking into this, and will require ripping KGI > apart to implement properly. The KGI input device and console subsystems > have to be disentangled from the video driver subsystem. The input > driver stuff will probebly end up in EvStack, but the console handler has > been superceded by fbcon which went into the standard kernel in 2.1.107 > and is now the standard with which KGI will have to work. Well, you needn't rip KGI apart to write the wrapper ; once it is working, we will have to really sit down and think about how we will remodel the source tree, that's true. Right now, all you need is to write a replacement 'kernel driver' part for the KGI module. What it will basically do is, provide the services to the driver that KGI did usually (pci lookup, etc.); at init, register the driver as a framebuffer device to fbmem (look at other fb drivers), then when fbcon sends command to that fbmem device, just translate mode requests etc and call the appropriate KGI commands. I have a stub wrapper for that, but never got around to improve it. I'm attaching it to this (sorry everyone.. :) > driver/video/fbcon-kgi.c [snip] Well, right now i think it would look more like : drivers/video/kgi/chipset/.. drivers/video/kgi/ramdac/.. drivers/video/kgi/clock/.. drivers/video/kgi/graphic/.. drivers/video/kgi/i386/fbcon.c Don't forget that our drivers aren't i386 specific, and if they are, they shouldn't be. Geert said that Mac users are eager to use their Matrox under linuxppc. If we want to be accepted, our drivers need to work on all platforms linux supports, wherever possible. This is not a small issue, but it has always been avoided :) > The Linux configuration system would be extended by grafting the > current KGI Makefile system in under it. If the user selects fbcon with > KGI driver, they can enter the KGI make subsystem, do their business and > return to the rest of the config system transparently. Right - that's how I had thought to make it at least for a first integration attempt. In the near future, it will somehow have to be integrated in the kernel config script tho - somehow, so that people can do make xconfig without being dropped to an xterm for KGI configuration, for example. > There are still some conflicts between KGI and fbcon though. > First is that non-x86 architectures still use direct fbcon drivers and not > KGI drivers. Yes, and we need to get KGI drivers to work everywhere. > I hope to be able to convince people that the KGI subsystem > is so much cleaner and more modular than the current fbcon layout that > they should move their drivers into KGI, but I don't see that happening > before KGI proves itself with the current x86 drivers, which I have no > doubt it will do. The only thing that sucks about possibly getting into > the main Linux source tree is that we'll have to give up CVS and start > sending Linus patches like everyone else does |-<. Oh well. Well first, KGI drivers and fbcon drivers will cohabitate. That's okay, because for the user, it doesn't make a difference : GGI talks to the fbcon target, and fbcon will use whateve driver was configured, either an fbcon one or a KGI one; it won't make a speed difference either, so everything is fine. And we won't dump CVS - simply, when drivers are stable and tested, on a regular basis, we'll send a diff to Geert or Alan; the main kernel will be lagged behind a few releases, but that's life. > I would like it an awful lot if we could hit the decks running > with KGI and 2.3 and get KGI into the kernel right away. Well, if the KGI wrapper is running soon, I'm confident that the KGI drivers can go into 2.1.x (so into 2.2.x) - while under a feature freeze, the console code was replaced even if hell broke loose, and it did, so adding new drivers that don't break a thing, should happen, I'm sure. > I would like it > if I could get together Geert, Alan, Linus and everyone with the GGI > project who has worked, is working or will work on KGI-fbcon-kernel > issues and finally get this damn issue dealt with. The presence of the > console and input device code in KGI-Dali was a major factor in turning > Linus off KGI last go-around. Maybe he will be in a better mood to listen > if we present him with a simple, small video driver subsystem and > makefile integration to go with it that he can drop right into his tree > and it works seamlessly with the existing console. Well, he did merge the fbcon patch. Linus _isn't_ stubborn ; it's true that duplicating console code in KGI didn't help to cheer him up about GGI. Now that we sort of fit the linux philosophy, there's no reason not to have the drivers themselves in the kernel, now that what manages them is in. -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 27 06:09:32 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA26597; Sat, 27 Jun 1998 06:09:30 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA09415; Sat, 27 Jun 1998 06:06:24 -0700 Resent-Date: Sat, 27 Jun 1998 06:06:24 -0700 Sender: core@orb.suntech.fr Message-ID: <3594EDBD.A8769820@suntech.fr> Date: Sat, 27 Jun 1998 13:03:58 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Future of GGI project References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8duWD2.0.wI2.FvEbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3084 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi Jon ! > We should have separate Web pages, FAQs, CVS trees, and mailing > lists. Of course there would be some of us that would subscribe to more > than one, and there would be crossposted discussions as needed like other > newsgroups, but overall each project would lead a day-to-day existence > separated from each other. Less mailing list traffic, less CVS bandwidth, > less website traffic, less documentation, smaller and simpler source > trees, more tightly-knit developer community, etc etc etc. Also, our > message would not be as muddled as is it is right now and our good ideas > would stand a better chance of being heard. www.evstack-project.org, > www.kgi-project.org, www.libggi-project.org. Simple, no? Well - I don't think we are enough GGI programmers, to split the efforts in three ; it's a wellknown fact that half of us are working on several things at the same time .. A bit of KGI, a bit of libggi.. And half of us are busy with things at one time, and come back to find that others are too and have to take things over on another project, etc. But we do progress this way. Just my opinion :) -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 27 06:12:15 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA26603; Sat, 27 Jun 1998 06:12:13 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA09444; Sat, 27 Jun 1998 06:06:31 -0700 Resent-Date: Sat, 27 Jun 1998 06:06:31 -0700 Sender: core@orb.suntech.fr Message-ID: <3594EDBA.A4CB0EC7@suntech.fr> Date: Sat, 27 Jun 1998 13:03:54 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: job offers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Nj-Ux3.0.RJ2.MvEbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3085 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon M. Taylor wrote: [I did] > > This isn't either as bad or as complicated as it looks - fbcon > > adds another 'middle man' in the fullscreen display scheme, > > but once the KGI driver is registered to fbcon, it is > > just an extra indirect function call. So that's really > > a non-issue. > > Sound simple enough. So basically fbcon will be just like a > userspace program that requests modes, sets palettes, etc, right? KGI > will concern itself with issues of monitor drivers and mode timings. > Makes sense to me. Well, an userspace GGI application will call libggi, which calls the fbcon target; the target does an iocttl() to the kernel part of fbcon (what got into 2.1.107) . Then fbcon needs to render, that's where your work starts : you write a renderer (frame buffer device) for fbcon, which doesn't actually render, but calls a KGI driver to do that. > I'd like to play with fbcon but my 2.1.107 won't compile yet > |-<. From all the griping on linux-kernel, it may be another kernel > release or two before it is stable. Yes, I'm even starting to get messages on IRC asking "uhh, why did you break the console" :) > > So, that leads to the question : who wants to write it ? Of > > course the ideal candidate would know both fbcon and KGI like > > the back of his hand but there is no such person among us :) > > > Steffen is, as I understand, working on XAA, He's working on getting XAA to work with KGI acceleration IIRC. > > I would prefer someone from the ggi 'core' team to handle it, > > but anyone is welcome - yes you lurker, it's time to step > > out of the dark. > > I can give it a shot if you want. It actually doesn't sound too > difficult. GREAT ! Thanks ! You're the perfect candidate for that. Allright, it's your baby now. All eyes will turn to that wrapper, as this is really what will allow all GGI applications to run on a native kernel, without suid rights. What we always fought for, we can finally have it. Please don't hesitate to mail me if you have questions about fbcon (Andrew and Geert will be willing to help too, I'm sure) and can't figure it out (I'm sure you won't have to, tho :) > > Let's face it, the KGI part of EvStack (or Dali for that matter) > > will never make it into the main kernel as is, now that fbcon > > is standard. > > Take away all messaging stuff (EvStack) and the drivers > themselves, and what is left of KGI isn't too much. But if we are going > to split the KGI video driver layer and its associated drivers away from > any console stuff and EvStack, this should be formally decided upon and > plans made to modify the repository appropriately (i.e. remove KGI > altogether o it is relly going into the kernel proper). Also, IMHO this > change would further justify a complete separation of EvStack and GGI into > separate projects. Yes - the KGI wrapper (we should really find another name, because it sounds like an hack) will take the video driver layer out of EvStack. And fbcon takes away the console part (i.e. the "GGI console"). Again I don't think this is bad news; I could have hard feelings as I put a lot of efforts into KGI, but really this is to the benefit of the end users. > > This is not _necessarily_ a bad thing - of course, the KGI > > kernel manager is wasted work, but look at what we get instead : > > a fully functional console (no unmapped keys or whatever) > > exactly compatible to the original one, and GGI applications > > working on the standard kernel. With the wrapper, we allow > > for non-suid graphics too. > > What about acceleration, what last I looked was not supported > generally by fbcon? AFAIK they have a blit ioctl but that's it. This > issue has always been at the heart of the disagreements between GGI and > Linus. The current state of accel support in the KGI drivers is largely > confined to 2-D stuff that could easily be used by fbcon as it stands now, > though. fbcon supports blitting (mainly so that font rendering into the console wouldn't crawl) and supports native tricks such as panning and ywrap on VGA and Amiga (I haven't looked at the code, but I know the Atari can do that too, with an interrupt every horizontal line or so). It doesn't support much more at the moment, but it is _easy_ to extend : I implemented hardware cursor support in about 15 minutes. My opinion is that we should get the nifty KGI 2D acceleration to work on fbcon rather than reinvent the wheel again .. > > Please everyone comment that and someone volunteer. If there > > is noone, of course I'll write the darned code, but I would really > > want someone else to do it :) > > How and where are the current Dali KGI drivers to be integrated > into the kernel tree? In devices/video where the fbcon stuff is now? In > a separate directory under that? Has Linus said anything about how he > wants all this to be organized? For that matter, has Linus even approved > this KGI<->fbcon wrapper scheme at all? I haven't talked to Linus in person, just to Alan Cox - in april or so, when I did those patches, he said something along the lines of : this is a wonderful solution to the GGI problem, it takes what is existing and standard and integrates your work ; now that there is no code duplication, the KGI drivers on top of fbcon can go into the standard kernel. Because now, it fits Linux philosophy : "a broken driver is better than no driver at all, as long as it doesn't break anything else". Once the new console has been ironed out for good, and I'm confident that 2.1.108 will be rock stable with that, the statement is true. -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 27 06:12:15 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA26604; Sat, 27 Jun 1998 06:12:13 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA02608; Sat, 27 Jun 1998 06:15:12 -0700 (PDT) Resent-Date: Sat, 27 Jun 1998 06:15:12 -0700 (PDT) Sender: core@orb.suntech.fr Message-ID: <3594EE12.438D44ED@suntech.fr> Date: Sat, 27 Jun 1998 13:05:22 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge References: <3594D0A4.1AB5C136@vertech.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"52oM-2.0.de.S1Fbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3087 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Torgeir Veimo wrote: > Some basic drivers belongs in the kernel, such as vgafb and vesafb. But > as long as it is possible to both insmod and rmmod a graphic driver, > these are the only one that really belong in the kernel distribution. Well, as I see it, step one of the KGI wrapper will be that fbcon renderson a KGI driver which is linked into the kernel and called at boot time. When this works, fbcon does have provision to register and unregister drivers dynamically, so we can have a ggidrv.o module with the fbcon wrapper instead of the KGI kernel driver, that will behave exactly as before. -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 27 07:28:54 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA26655; Sat, 27 Jun 1998 07:28:51 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id HAA09308; Sat, 27 Jun 1998 07:31:24 -0700 (PDT) Resent-Date: Sat, 27 Jun 1998 07:31:24 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Future of GGI project To: ggi-develop@eskimo.com Date: Sat, 27 Jun 1998 15:37:04 +0200 (MET DST) In-Reply-To: from "Jon M. Taylor" at Jun 27, 98 01:19:26 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"P4B1v2.0.JH2.w8Gbr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3090 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > Recently on linux-kernel the Linux Uniform Input Device project, > which shares a lot of ideas with EvStack, was created. Yes. I have joined their mailing list, and spread some news on EvStack to make sure we do not have to start all over again. > The idea of abstract message-passing protocols which EvStack pioneered > seems to have caught on bigtime. Yeah - it seems that there are some problems with all ideas coming from the GGI people getting accepted. As soon as someone else brings them up, they seem to be considered a good idea soon :-). (or rather :-/ ...) > EvStack has been talked about a bit but no one spoke to them so they went > off on their own, and I fear that they might in their ignorance come up > with a scheme that is inferior to the greatness that is EvStack |->. We will see. I pointed them to the humor page already, which should be convincing :-). > Also in kernel 2.1.107, fbcon was brought in to the standard linux > kernel. This means that the fbcon interface (8/15/16/24/32bpp linear > framebuffers, palettes, textual console abstraction, fonts, rectangular > blits and superbitmaps) is what we *have* to work with. Yeah - and I am glad it happened. At least something to start work from without having to ditch all and everything. > There already exists an fbcon LibGGI target, and I am writing a wrapper > layer for KGI to bridge it to fbcon as well. This will enable anyone to > use fbcon with any of the current KGI drivers and everything in fbcon > that can be accelerated will be. Yeah - though we will still need a "fbcon-bypass" layer that will route commands and other requests directly through to the KGI driver to take advantage of all KGi features ... > Also the KGI console and KGI input device subsections will be > transferred to EvStack, leaving KGI as a 'pure' graphics driver interface. Yes - This was always intended that way. > Emmanuel thinks, and I agree, that this might finally get KGI accepted > into the standard kernel. We're not gonna get all the accelerations we > wanted, but you gotta compromise sometime.... *grin* Adding a single ioctl to fbcon will do. > Lastly, there's LibGGI. It has many targets and supported > platforms right now, and Win16/Win32 compatibility is not far off. > A DirectX wrapper for LibGGI is being written. it is being extended > into windowing toolkits, graphics file formats, 2d and 3d acceleration, > OpenGL, network graphics, and all of it cross-platform and completely > open. It could very well turn into the Java of graphics APIs. *grin* Let's hope it doesn't. I don't want slow interpreted code :-). Regarding your comments on splitting KGI/LibGGI/EvStack: Yes - we should make it _LOOK_ this way. However we need to work closely together to keep things in sync. Maybe our webpage maintainer might want to think a bit about restructuring the page, so that it splits up to a KGI, a LibGGI and an EvStack part. As CVS is for people _working_ on the sources, I don't care, if it puts it all together (which is needed anyway for developers most of the time). However snapshots and tgz archives should be split, and that is what the current makefile entries try. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 27 07:31:04 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA26668; Sat, 27 Jun 1998 07:31:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA23694; Sat, 27 Jun 1998 07:27:24 -0700 Resent-Date: Sat, 27 Jun 1998 07:27:24 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: GGI datatypes (was RE: Request for system information.) To: ggi-develop@eskimo.com Date: Sat, 27 Jun 1998 15:42:59 +0200 (MET DST) In-Reply-To: from "MenTaLguY" at Jun 26, 98 10:56:45 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Kss_51.0.zn5.A5Gbr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3088 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > I'll change ggi/types.h, so that if the types are defined, it makes > > use of them, then if __gnuc__ is defined, it uses the handy gcc typedef > > 'mode' attribute in order to specify the size (after checking gcc > > documentation, they *are* guaranteed to be of the size you > > specify), and neither are defined, it'll use the current arch definitions. > > Any objection to that ? > > Maybe it might be better to start using them now in the GGI tree, and just > have a header file with them on hand (basically the existing ggi/types.h > using the POSIX names) that can be conditionally included if the system > doesn't have them itself. Shouldn't be too hard to detect it in the > configure script, a la autoconf or something ... Are you talking about the POSIX names ? I'd rather opt not to do that, because, if we use ggi_*, then it is all in our namespace domain. If on some system the POSIX names do not exist, users might be very tempted to create them for their programs anyway. And they will do so by using a typedef, just as we will do in our headers, and if they use both together, they will clash. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 27 07:31:27 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA26672; Sat, 27 Jun 1998 07:31:25 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA23709; Sat, 27 Jun 1998 07:27:25 -0700 Resent-Date: Sat, 27 Jun 1998 07:27:25 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Vararg macros in ggi/debug.h To: ggi-develop@eskimo.com Date: Sat, 27 Jun 1998 15:44:10 +0200 (MET DST) In-Reply-To: <35940D52.D219C7BA@daimi.aau.dk> from "Martin Eli Erhardsen" at Jun 26, 98 11:06:26 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"R-DbU3.0.Io5.C5Gbr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3089 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > Could everyone please refrain from using vararg macros before having > checked that the compiler supports them. > They aren't ANSI, and I get syntax errors with the IRIX C compiler > > In Dali the vararg macros were only used when compiling with GCC, > by checking for the __GNUC__ preprocessor symbol. > It should be possible to use vararg functions instead. YES ! This is a bug. Please fix ! CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 27 08:32:24 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA26706; Sat, 27 Jun 1998 08:32:22 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA16326; Sat, 27 Jun 1998 08:33:44 -0700 (PDT) Resent-Date: Sat, 27 Jun 1998 08:33:44 -0700 (PDT) Sender: core@orb.suntech.fr Message-ID: <35950E8E.7C0BFA54@suntech.fr> Date: Sat, 27 Jun 1998 15:23:58 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: ggi/types.h overhaul Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"pHk14.0.--3.M3Hbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3091 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all, I have added POSIX1003.1g and GNU C types to ggi/types.h as planned. If POSIX types (int32_t, u_int32_t, etc., that primarily were defined for network code) are defined, they are used; if they aren't, and the compiler is GCC version 2.7 or above, gcc __attribute__ extensions, that allow to specify the integer width to use for the typedef, are used; then if all fails, it reverts to using the arch-specific typedefs that were used so far. Hopefully new platforms will provide POSIX types and will use gcc too, and we will never have to add arch-specific types there again. That should pretty much close the issue with libggi porting. Note: when using posix or gnu c types, ggi_sintl and ggi_uintl ("maximum precision integer") are defined to 64-bit ints, without having to use the putrescent long long typedef - just asking for a 64-bit int; it works on 32-bit platforms as well (and has the same effect as long long then I guess), but it's portable. I did other small changes to ggi/types.h such as checking we are really compiling on Linux under the #ifdef __KERNEL__ ; just for paranoia :) While I was at it, I modified ggi/events.h where a non-signed integer enum caused a warning with the extended error checking of egcs. libggi compiles with no warning here using egcs 1.0.3 on my linux glibc2 box at home; if you see any on any platform, please post to the list - none should show up. I recompiled all demos, doom, warp and tested carefully playing Doom and watching iXalate demos (boy, I'm so professional *grin*) and it all works. Changes have been commited to the devel repository as it is a "bugfix" (or so said Andy :) Andy, will you fold that in when moving the frozen tree into stable, or should I ? -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 27 09:45:13 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA26779; Sat, 27 Jun 1998 09:45:11 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA14541; Sat, 27 Jun 1998 09:34:09 -0700 Resent-Date: Sat, 27 Jun 1998 09:34:09 -0700 Sender: core@orb.suntech.fr Message-ID: <35951E6E.9C91BEFA@suntech.fr> Date: Sat, 27 Jun 1998 16:31:42 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com CC: irish@eskimo.com Subject: Fwd: You have been removed from the list References: <199806271549.IAA17854@mx2.eskimo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"5yMmF.0.0Z3.0yHbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3092 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Your mail address core@suntech.fr has been removed > from the ggi-develop@eskimo.com mailinglist. > It generated an excessive amount of bounced mails. [snip] > >This report relates to a message you sent with the following header fields: > > > > Message-id: <35950E8E.7C0BFA54@suntech.fr> > > Date: Sat, 27 Jun 1998 15:23:58 +0000 > > From: Emmanuel Marty > > To: ggi-develop@eskimo.com > > Subject: ggi/types.h overhaul > > > >Your message cannot be delivered to the following recipients: > > > > Recipient address: zeus@tomserver.phys.ttu.edu > > Reason: Remote SMTP server has rejected address > > Diagnostic code: smtp; 550 ... User unknown > > Remote system: dns; tomserver.phys.ttu.edu (TCP|129.118.1.21|1850|129.118.41.33|25) (tomserver.phys.ttu.edu ESMTP Sendmail 8.8.7/8.8.7; Sat, 27 Jun 1998 10:35:49 -0500) (tomserver.phys.ttu.edu Hello ttacs2.acs.ttu.edu [129.118.1.21], pleased to meet you) > Am I going to be bounced off the list every time I post the message and one of the subscribed addresses fails? It happened twice today.. Taylorcc, this is your address or something, maybe you should unsubscribe it..? -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 27 13:00:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26894; Sat, 27 Jun 1998 13:00:37 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA14826; Sat, 27 Jun 1998 12:54:40 -0700 (PDT) Resent-Date: Sat, 27 Jun 1998 12:54:40 -0700 (PDT) Date: Sat, 27 Jun 1998 12:46:51 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: <3594D0A4.1AB5C136@vertech.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ORhmS1.0.Xd3.-tKbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3094 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998, Torgeir Veimo wrote: > Jon M. Taylor wrote: > > > > Maybe he will be in a better mood to listen > > if we present him with a simple, small video driver subsystem and > > makefile integration to go with it that he can drop right into his tree > > and it works seamlessly with the existing console. > > I argue that we should depend on an external development environment in > any case for several reasons: You misunderstand. We will still develop via separate CVS tree, and occasionally make up patches rom this and send them to Linus for inclusion in the kernel proper. > One optimally shouldn't have to make a kernel to compile drivers. This is a separate issue, and I agree with you. BUT, Linus does not. Ideally, *all* device drivers would be maintained and distributed separately fromn the main kernel source tree, as would the different architectures. However, every time someone bring this up in linux-kernel, Linus says that this would make it a nightmare to keep drivers in sync with the kernel. > For the first time we have a resonable interface for graphics which > makes it possible to separate the drivers from the kernel distribution. > > Keeping driver development in a separate development environment will > also ensure that they don't depend on linux-kernel in any way. > > Some basic drivers belongs in the kernel, such as vgafb and vesafb. But > as long as it is possible to both insmod and rmmod a graphic driver, > these are the only one that really belong in the kernel distribution. Again, I agree with you and I wish that it could be this way and hopefully someday it will be (or we'll all be downloading 40MB kernel source trees with 95%+ stuff we don't need). However that is not the way it is now and we have to play by Linus' rules. No big deal, we just have to snapshot our tree every so often and send him patches from that. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 13:27:34 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26943; Sat, 27 Jun 1998 13:27:31 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA27081; Sat, 27 Jun 1998 12:58:40 -0700 Resent-Date: Sat, 27 Jun 1998 12:58:40 -0700 Date: Sat, 27 Jun 1998 12:58:08 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: Future of GGI project In-Reply-To: <3594D413.17546C54@vertech.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"q5Yb31.0._c6.jxKbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3095 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998, Torgeir Veimo wrote: > Jon M. Taylor wrote: > > > > We're not gonna get all the accelerations we > > wanted, but you gotta compromise sometime.... > > We'll eventually get all the acceleration we need... ;) Hopefully. fbcon really needs a 'gateway' to allow access to arbitrary accels if the user knows what they are doing > > All of this turmoil needs to be resolved. The idea of splitting > > up the GGI project has been proposed in the past, by myself and others, > > but I feel I need to bring it up again in light of the current situation. > > I agree with the sentiment that it is healthy to rething everything one > in a while. I also feel console issues are orthogonal to the issue of > graphics drivers, even if a console system done The Right Way needs > things that only ggi provides. Yeah. Device drivers should be 'pure'. > I think separating the graphic drivers, the thing we usually call kgi, > is healthy in many ways. But I don't think it is possible to completely > separate the development of libggi and kgi, since a complete driver > depends on both. Of course they cannot be *completely* separated, but there are many other kernel and user subsystems in Linux that work with each other but are developed separately. And don't forget that KGI support is but one target of many in LibGGI these days. It will be good for LibGGI to be its own separate entity. > Thomas presented an idea a while back with a 'new' libggi system, which > dealt with the interoperation between the kgi part of a driver and the > userland-library part of the driver more than with the api nature of > libggi. Isn't the userland part of the driver part of LibGGI? If so it is IMHO *not* part of KGI and should be treated as such. LibGGI is no longer the userland portion of KGI. What if someone wants to use KGI drivers directly or their own X server, for example? > I think it would be healthy to experiment more with a system which > includes both kgi and a userland library to come up with a system on > which it is possible to do driver development independent on what api > libggi exports. This system would only deal with how acceleration > commands flow between the library, kgi and the graphics card, and would > be usefull when developing an accelerated Mesa library, normal libggi, > libggi2D, libggi3D etc. (insert favourite library here..) It would also > deal with 'driver loading'. To get optimal efficiency when talking directly to KGI, you may well need to recode the flow of control for each application (X, Mesa, LibGGI2D, etc). I don't see the common ground you are referring to above. If you disconnect the userspace drivers from interfacing to a particular API, you lose some ability to optimize for that API. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 13:34:57 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26952; Sat, 27 Jun 1998 13:34:52 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA17522; Sat, 27 Jun 1998 13:20:13 -0700 (PDT) Resent-Date: Sat, 27 Jun 1998 13:20:13 -0700 (PDT) Date: Sat, 27 Jun 1998 13:12:21 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: <3594ED7F.F72D7B32@suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"FHzRZ2.0.fH4.xFLbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3096 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998, Emmanuel Marty wrote: > Jon M. Taylor wrote: > > > I have begun looking into this, and will require ripping KGI > > apart to implement properly. The KGI input device and console subsystems > > have to be disentangled from the video driver subsystem. The input > > driver stuff will probebly end up in EvStack, but the console handler has > > been superceded by fbcon which went into the standard kernel in 2.1.107 > > and is now the standard with which KGI will have to work. > > Well, you needn't rip KGI apart to write the wrapper ; once it is working, > we will have to really sit down and think about how we will remodel the > source tree, that's true. Yes, I can write a wrapper that interfaces nicely with fbcon and KGI, but to *do anything* with it, KGI and fbcon need to both be compiled into the kernel simultaneously and that causes all sorts of conflicts with the console code. That was why I has problems compiling 2.1.107 earlier - I applied the 2.1.107 patch to 2.1.106+KGI+EvStack. Once I stated over with a clean 2.1.107 it compiled fine. > Right now, all you need is to write a replacement 'kernel driver' part for > the KGI module. What it will basically do is, provide the services to > the driver that KGI did usually (pci lookup, etc.); at init, register the > driver > as a framebuffer device to fbmem (look at other fb drivers), then when > fbcon sends command to that fbmem device, just translate mode > requests etc and call the appropriate KGI commands. This works fine for the driver modules, but to insert them I still have to have the KGI framework (kgi.c, etc) compiled into the kernel at boot time. > I have a stub > wrapper for that, but never got around to improve it. I'm attaching > it to this (sorry everyone.. :) > > > driver/video/fbcon-kgi.c > > [snip] > > Well, right now i think it would look more like : > > drivers/video/kgi/chipset/.. > drivers/video/kgi/ramdac/.. > drivers/video/kgi/clock/.. > drivers/video/kgi/graphic/.. > drivers/video/kgi/i386/fbcon.c Yes that is what I meant basically. > Don't forget that our drivers aren't i386 specific, and if they are, > they shouldn't be. Geert said that Mac users are eager to > use their Matrox under linuxppc. If we want to be accepted, our > drivers need to work on all platforms linux supports, wherever > possible. This is not a small issue, but it has always been > avoided :) It is a thorny issue. I would like to see the whole thing working on i386 with the drivers we have right now before we go any farther. > > The Linux configuration system would be extended by grafting the > > current KGI Makefile system in under it. If the user selects fbcon with > > KGI driver, they can enter the KGI make subsystem, do their business and > > return to the rest of the config system transparently. > > Right - that's how I had thought to make it at least for a first integration > attempt. In the near future, it will somehow have to be integrated in the > kernel config script tho - somehow, so that people can do make xconfig > without being dropped to an xterm for KGI configuration, for example. That will require some serious enhancement to the stock Linux config scripts, which needs to happen anyway at some point. > > There are still some conflicts between KGI and fbcon though. > > First is that non-x86 architectures still use direct fbcon drivers and not > > KGI drivers. > > Yes, and we need to get KGI drivers to work everywhere. > > > I hope to be able to convince people that the KGI subsystem > > is so much cleaner and more modular than the current fbcon layout that > > they should move their drivers into KGI, but I don't see that happening > > before KGI proves itself with the current x86 drivers, which I have no > > doubt it will do. The only thing that sucks about possibly getting into > > the main Linux source tree is that we'll have to give up CVS and start > > sending Linus patches like everyone else does |-<. Oh well. > > Well first, KGI drivers and fbcon drivers will cohabitate. That's okay, > because for the user, it doesn't make a difference : GGI talks to > the fbcon target, and fbcon will use whateve driver was configured, > either an fbcon one or a KGI one; it won't make a speed difference > either, so everything is fine. > > And we won't dump CVS - simply, when drivers are stable and tested, > on a regular basis, we'll send a diff to Geert or Alan; the main kernel > will be lagged behind a few releases, but that's life. What happens when Joe Linux User sees a problem in one of the drivers and sends a patch to Linus instead of us? Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 13:37:50 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26957; Sat, 27 Jun 1998 13:37:48 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA24501; Sat, 27 Jun 1998 12:48:52 -0700 Resent-Date: Sat, 27 Jun 1998 12:48:52 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: ggiglut update To: ggi-develop@eskimo.com (mailing list GGI) Date: Sat, 27 Jun 1998 21:39:19 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"9JpWr3.0.i-5.ZoKbr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3093 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all, hi Uwe ! I did some tests to see, why some programs had problems with events, especially the GLUT demos from Uwe's latest Mesa patch. The problem was that I had an outdated events.h installed, so that was my fault. A few other things struck me, so I fixed them - here is the patch. --- ggiglut.c.old Sat Jun 27 20:37:38 1998 +++ ggiglut.c Sat Jun 27 21:23:46 1998 @@ -284,12 +284,13 @@ sym=ev->key.sym; - switch(KTYP(U(sym))) + switch(KTYP(sym)) { + case 0: /* This is rather KT_LATIN ... */ case KT_LATIN: case KT_LETTER: case KT_META: - if (__glut_keyboard) __glut_keyboard(KVAL(U(sym)),0,0); + if (__glut_keyboard) __glut_keyboard(KVAL(sym),0,0); break; default: switch(sym) @@ -338,6 +339,22 @@ } +static void mouseabs(ggi_event *ev) +{ + int oldx=mousex; + int oldy=mousey; + + mousex=ev->pmove.x; + mousey=ev->pmove.y; + + if (mousex<0) mousex=0; + if (mousey<0) mousey=0; + if (mousex>=__glut_width) mousex=__glut_width-1; + if (mousey>=__glut_height) mousey=__glut_height-1; + + if (mousex!=oldx || mousey!=oldy) mouse_moved=GL_TRUE; +} + static void showmenu(void); static int clickmenu(void); static void updatemouse(void); @@ -437,6 +454,9 @@ case evKeyPress: case evKeyRepeat: keyboard(&ev); + break; + case evPtrAbsolute: + mouseabs(&ev); break; case evPtrRelative: mouse(&ev); Hope it doesn't get corrupted on its way ... well - it's small enough for applying by hand in that case ... CU, ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 27 13:48:35 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA26967; Sat, 27 Jun 1998 13:48:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA00357; Sat, 27 Jun 1998 13:30:04 -0700 Resent-Date: Sat, 27 Jun 1998 13:30:04 -0700 Date: Sat, 27 Jun 1998 13:29:29 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: Future of GGI project In-Reply-To: <3594EDBD.A8769820@suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"VXXts.0.K5.8PLbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3097 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998, Emmanuel Marty wrote: > Hi Jon ! > > > > We should have separate Web pages, FAQs, CVS trees, and mailing > > lists. Of course there would be some of us that would subscribe to more > > than one, and there would be crossposted discussions as needed like other > > newsgroups, but overall each project would lead a day-to-day existence > > separated from each other. Less mailing list traffic, less CVS bandwidth, > > less website traffic, less documentation, smaller and simpler source > > trees, more tightly-knit developer community, etc etc etc. Also, our > > message would not be as muddled as is it is right now and our good ideas > > would stand a better chance of being heard. www.evstack-project.org, > > www.kgi-project.org, www.libggi-project.org. Simple, no? > > Well - I don't think we are enough GGI programmers, to split the efforts > in three ; > > it's a wellknown fact that half of us are working on several things > at the same time .. A bit of KGI, a bit of libggi.. Yes, I do this as well. But I would still like it better if I could focus completely on one issue at a time. And so would a lot of GGI outsiders, I'll bet. > And half of us are busy > with things at one time, and come back to find that others are too and > have to take things over on another project, etc. But we do progress > this way. Sure we progress, but we remain an insular, isolated community of developers. We have too much Cathedral and not enough Bazaar for a project that is now almost 3 years old. Quite frankly, we have a real problem attracting outside development assistance because we keep to ourselves so much. We are all good coders (and some of us (not me) are brilliant designers), or the project wouldn't be where it is today. But we *need* to break out of our niche and get out ideas accepted by the open source community at large, and to do that effectively we need to streamline our organization, clear up our message(s) and refocus ourselves. > Just my opinion :) Just mine as well. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 14:19:12 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA26988; Sat, 27 Jun 1998 14:19:10 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA21388; Sat, 27 Jun 1998 14:16:29 -0700 (PDT) Resent-Date: Sat, 27 Jun 1998 14:16:29 -0700 (PDT) Sender: injector@clubneon.dyn.ml.org Message-ID: <35955F2E.5330DE8F@stu.ac.cc.md.us> Date: Sat, 27 Jun 1998 17:07:58 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Drivers Web Page Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"1OSwj3.0.4E5.h4Mbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3100 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I recall a post to the list about the 3Dlabs driver source being allowed to be released now. Could someone have a look at http://www.ggi-project.org/drivers.html and let me know if that data can go (I think it is really out of date and know it doesn't properly link from the mirrors)? And then could someone else let me know if there are any other binary only drivers that should be listed there? -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Sat Jun 27 14:24:26 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA26997; Sat, 27 Jun 1998 14:24:25 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA10649; Sat, 27 Jun 1998 14:20:31 -0700 Resent-Date: Sat, 27 Jun 1998 14:20:31 -0700 Date: Sat, 27 Jun 1998 14:19:59 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: <3594EE12.438D44ED@suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"wr_Pk1.0.Hc2.U8Mbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3101 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998, Emmanuel Marty wrote: > Torgeir Veimo wrote: > > > Some basic drivers belongs in the kernel, such as vgafb and vesafb. But > > as long as it is possible to both insmod and rmmod a graphic driver, > > these are the only one that really belong in the kernel distribution. > > Well, as I see it, step one of the KGI wrapper will be that fbcon renderson a > KGI driver which is linked into the kernel and called at boot time. I had though to use the current KGI mini boot driver to start off with, then move to the VGA driver compiled-in and get text and graphical consoles working. Then the VGA driver as a module. > When this works, fbcon does have provision to register and unregister > drivers dynamically, so we can have a ggidrv.o module with the fbcon wrapper > instead of the KGI kernel driver, that will behave exactly as before. I assume that there will be a compiled-in base driver that can be overridden by loaded modules (like how KGI does it now) but cannot be unregistered itself, right? It can't all be modules because you have to be able to display something at init time before modules can be loaded.... Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 14:25:09 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA27002; Sat, 27 Jun 1998 14:25:07 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id OAA20942; Sat, 27 Jun 1998 14:09:40 -0700 (PDT) Resent-Date: Sat, 27 Jun 1998 14:09:40 -0700 (PDT) Sender: core@orb.suntech.fr Message-ID: <35955D44.AE1DC37A@suntech.fr> Date: Sat, 27 Jun 1998 20:59:48 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"VWEOc3.0.375.G-Lbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3098 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon M. Taylor wrote: > Yes, I can write a wrapper that interfaces nicely with fbcon and > KGI, but to *do anything* with it, KGI and fbcon need to both be compiled > into the kernel simultaneously and that causes all sorts of conflicts > with the console code. That was why I has problems compiling 2.1.107 > earlier - I applied the 2.1.107 patch to 2.1.106+KGI+EvStack. Once I > stated over with a clean 2.1.107 it compiled fine. Um, no. As I see it the wrapper should provide KGI services to the driver - you should _not_ need KGI itself; actually drivers don't make a lot of use of KGI itself besides pci lookup ; what makes use of it is the linux/i386.c code, and this is what the driver replaces. > This works fine for the driver modules, but to insert them I still > have to have the KGI framework (kgi.c, etc) compiled into the kernel at > boot time. See above, I think that the wrapper should provide the KGI functionality that drivers need (not much actually). I had a wrapper that did compile in a clean kernel with KGI drivers that did that (even if it didn't work because I never got to debug it). > Yes that is what I meant basically. Ok - just making sure. > > Don't forget that our drivers aren't i386 specific, and if they are, > > they shouldn't be. Geert said that Mac users are eager to > > use their Matrox under linuxppc. If we want to be accepted, our > > drivers need to work on all platforms linux supports, wherever > > possible. This is not a small issue, but it has always been > > avoided :) > > It is a thorny issue. I would like to see the whole thing working > on i386 with the drivers we have right now before we go any farther. Yes - of course. I just meant, don't put the drivers etc under i386/ :) > > Right - that's how I had thought to make it at least for a first integration > > attempt. In the near future, it will somehow have to be integrated in the > > kernel config script tho - somehow, so that people can do make xconfig > > without being dropped to an xterm for KGI configuration, for example. > > That will require some serious enhancement to the stock Linux > config scripts, which needs to happen anyway at some point. Yeah, I think that would be for the benefit of everyone. I don't think anyone will mind improvement of the whole config subsystem, e.g. the sound subsystem writers. > > And we won't dump CVS - simply, when drivers are stable and tested, > > on a regular basis, we'll send a diff to Geert or Alan; the main kernel > > will be lagged behind a few releases, but that's life. > > What happens when Joe Linux User sees a problem in one of the > drivers and sends a patch to Linus instead of us? Well, most kernel developers use the linux 'bleeding edge' CVS tree at vger.rutgers.edu and it works fine .. Hopefully if Joe User is smart enough to produce a patch, he'll be enough to read our email addresses in the source header and send there, it's publicly known that Linus disregards patches not sent via the official system anyway :) But I see your point - we'll need to find something else than dumping CVS IMHO tho - see how much the coming back of the server got everyone back to work.. -- Emmanuel From ggi-develop-request@eskimo.com Sat Jun 27 14:26:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA27009; Sat, 27 Jun 1998 14:26:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA08930; Sat, 27 Jun 1998 14:08:00 -0700 Resent-Date: Sat, 27 Jun 1998 14:08:00 -0700 Date: Sat, 27 Jun 1998 14:07:27 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: job offers In-Reply-To: <3594EDBA.A4CB0EC7@suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"DlIlV3.0.FB2.kyLbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3099 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998, Emmanuel Marty wrote: > Jon M. Taylor wrote: > > > > So, that leads to the question : who wants to write it ? Of > > > course the ideal candidate would know both fbcon and KGI like > > > the back of his hand but there is no such person among us :) > > > > > Steffen is, as I understand, working on XAA, > > He's working on getting XAA to work with KGI acceleration IIRC. OK, so there will need to be some way of feeding accel requests to KGI independently of fbcon. Interesting. If the XF86_fbdev server was extended to handle XAA calls through such an interface, as well as LibGGI'd KGI target, that would essentially solve all our problems! Linus gets his standard, minimally-accelerated console drivers, we get our holy grail of accelerated non-suid X using kernel drivers, and LibGGI gets access to all the accels it will ever need. > > > I would prefer someone from the ggi 'core' team to handle it, > > > but anyone is welcome - yes you lurker, it's time to step > > > out of the dark. > > > > I can give it a shot if you want. It actually doesn't sound too > > difficult. > > GREAT ! Thanks ! You're the perfect candidate for that. Heh |->. > Allright, it's your baby now. All eyes will turn to that wrapper, as > this is really what > will allow all GGI applications to run on a native kernel, without suid > rights. What we always fought for, we can finally have it. And not before time, too. It will be nice to see this situation cleared up once and for all. > Please don't hesitate to mail me if you have questions about fbcon > (Andrew and Geert will be willing to help too, I'm sure) and can't figure > it out (I'm sure you won't have to, tho :) Hopefully. Like I said in another post, my main sticking point right now is how to get KGI itself to coexist in the same kernel with fbcon. If I could do that without having to go in and rip out all the KGI console stuff (which looks to be a royal PITA), I would be a very happy man. > > > Let's face it, the KGI part of EvStack (or Dali for that matter) > > > will never make it into the main kernel as is, now that fbcon > > > is standard. > > > > Take away all messaging stuff (EvStack) and the drivers > > themselves, and what is left of KGI isn't too much. But if we are going > > to split the KGI video driver layer and its associated drivers away from > > any console stuff and EvStack, this should be formally decided upon and > > plans made to modify the repository appropriately (i.e. remove KGI > > altogether o it is relly going into the kernel proper). Also, IMHO this > > change would further justify a complete separation of EvStack and GGI into > > separate projects. > > Yes - the KGI wrapper (we should really find another name, because it > sounds like an hack) will take the video driver layer out of EvStack. And > fbcon takes away the console part (i.e. the "GGI console"). > > Again I don't think this is bad news; I could have hard feelings as I put > a lot of efforts into KGI, but really this is to the benefit of the end users. You have to take the long view. Last year when I was doing senior project at school, we came to near the end of the year and had this mountain of perl code, not all of which could be made to work properly by the delivery date. Some of my stuf that I had worked very hard on had to be cut out. I didn't like it but it had to be done. I think the end result will be well worth the sacrifice. > > > This is not _necessarily_ a bad thing - of course, the KGI > > > kernel manager is wasted work, but look at what we get instead : > > > a fully functional console (no unmapped keys or whatever) > > > exactly compatible to the original one, and GGI applications > > > working on the standard kernel. With the wrapper, we allow > > > for non-suid graphics too. > > > > What about acceleration, what last I looked was not supported > > generally by fbcon? AFAIK they have a blit ioctl but that's it. This > > issue has always been at the heart of the disagreements between GGI and > > Linus. The current state of accel support in the KGI drivers is largely > > confined to 2-D stuff that could easily be used by fbcon as it stands now, > > though. > > fbcon supports blitting (mainly so that font rendering into the console > wouldn't crawl) and supports native tricks such as panning and ywrap > on VGA and Amiga (I haven't looked at the code, but I know the Atari > can do that too, with an interrupt every horizontal line or so). Blitting, panning and a hardware cursor are all you really need to accelerate a GUI properly. > It doesn't support much more at the moment, but it is _easy_ to extend : > I implemented hardware cursor support in about 15 minutes. > > My opinion is that we should get the nifty KGI 2D acceleration to work > on fbcon rather than reinvent the wheel again .. That implies either a gateway to KGI through fbcon or a way to bypass fbcon altogether. As an analogy, think of the difference between a raw disk slice and a filesystem - they both refer to the same physical collection of bytes, but one implements a high-level abstraction on top of the other. However, both methods of access are needed - Oracle likes to directly control raw device access itself for speed reasons, but most apps don't need that level of control and just use the VFS. So it is with video cards as well. Most apps just need X or fbcon, but some need to drill down to the device level for direct access (XAA, LibGGI). So I would not extend fbcon overmuch. It already has what it needs to render textual consoles and accelerate a GUI - if someone needs more than that, they should bypass fbcon altogether and talk directly to KGI. We just need to figure out how to do this. > > > Please everyone comment that and someone volunteer. If there > > > is noone, of course I'll write the darned code, but I would really > > > want someone else to do it :) > > > > How and where are the current Dali KGI drivers to be integrated > > into the kernel tree? In devices/video where the fbcon stuff is now? In > > a separate directory under that? Has Linus said anything about how he > > wants all this to be organized? For that matter, has Linus even approved > > this KGI<->fbcon wrapper scheme at all? > > I haven't talked to Linus in person, just to Alan Cox - in april or so, when I > did those patches, he said something along the lines of : this is a > wonderful solution to the GGI problem, it takes what is existing and standard > and integrates your work ; now that there is no code duplication, the > KGI drivers on top of fbcon can go into the standard kernel. More like "fbcon on top of KGI" |->. > Because now, it fits Linux philosophy : "a broken driver is better than > no driver at all, as long as it doesn't break anything else". Once the new > console has been ironed out for good, and I'm confident that 2.1.108 > will be rock stable with that, the statement is true. So we are just shooting for KGI strictly supporting fbcon and nothing else for 2.1.x, right? We will save issues of direct KGI access, XAA, OpenGL, and suchlike or 2.3.x, yes? Please say yes |->. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 14:44:56 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA27023; Sat, 27 Jun 1998 14:44:53 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA16818; Sat, 27 Jun 1998 14:40:07 -0700 Resent-Date: Sat, 27 Jun 1998 14:40:07 -0700 Date: Sat, 27 Jun 1998 14:39:34 -0700 (PDT) From: "Jon M. Taylor" To: becka@rz.uni-duesseldorf.de cc: ggi-develop@eskimo.com Subject: Re: Future of GGI project In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Cjfae2.0.a64.sQMbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3102 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Hi ! > > > The idea of abstract message-passing protocols which EvStack pioneered > > seems to have caught on bigtime. > > Yeah - it seems that there are some problems with all ideas coming from the > GGI people getting accepted. As soon as someone else brings them up, they > seem to be considered a good idea soon :-). (or rather :-/ ...) That sucks, and is another manifestation of what I referred to below about our message being muddled and the diferent parts of GGI holding each other back. > > Also in kernel 2.1.107, fbcon was brought in to the standard linux > > kernel. This means that the fbcon interface (8/15/16/24/32bpp linear > > framebuffers, palettes, textual console abstraction, fonts, rectangular > > blits and superbitmaps) is what we *have* to work with. > > Yeah - and I am glad it happened. At least something to start work from > without having to ditch all and everything. I still think that EvStack's abstract consoles are a much cleaner and more flexible design than the traditional UNIX console which fbcon is just an extension of, but that is another battle to be fought elsewhere. > > There already exists an fbcon LibGGI target, and I am writing a wrapper > > layer for KGI to bridge it to fbcon as well. This will enable anyone to > > use fbcon with any of the current KGI drivers and everything in fbcon > > that can be accelerated will be. > > Yeah - though we will still need a "fbcon-bypass" layer that will route > commands and other requests directly through to the KGI driver to take > advantage of all KGi features ... Yes, this will be needed. > > Emmanuel thinks, and I agree, that this might finally get KGI accepted > > into the standard kernel. We're not gonna get all the accelerations we > > wanted, but you gotta compromise sometime.... > > *grin* Adding a single ioctl to fbcon will do. So all KGI ioctls would be wrapped in that one ioctl? Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 17:47:05 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA27130; Sat, 27 Jun 1998 17:46:56 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA32001; Sat, 27 Jun 1998 16:41:19 -0700 Resent-Date: Sat, 27 Jun 1998 16:41:19 -0700 Message-Id: <199806272341.QAA31970@mx1.eskimo.com> From: "Kendall Bennett" Organization: SciTech Software, Inc. To: ggi-develop@eskimo.com Date: Sat, 27 Jun 1998 15:58:29 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: fbcon-KGI bridge Priority: normal References: <3594D0A4.1AB5C136@vertech.no> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.01a) Resent-Message-ID: <"RuXfw.0.op7.UCObr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3104 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon M. Taylor wrote: > > One optimally shouldn't have to make a kernel to compile drivers. > > This is a separate issue, and I agree with you. BUT, Linus does > not. Ideally, *all* device drivers would be maintained and distributed > separately fromn the main kernel source tree, as would the different > architectures. However, every time someone bring this up in linux-kernel, > Linus says that this would make it a nightmare to keep drivers in sync > with the kernel. This is very true the way the Linux kernel is currently structured; device drivers know *too* much about the internals of the kernel, in that Linux specific code is interspersed with device specific code. This is why I keep telling people (I have not tried to convince Linus of this yet ;-) that all device drivers should be structures around a *pure* hardware abstraction layer (Pure HAL). This is how we have developed our SciTech Nucleus, Graphics Architecture device driver specification, and we are going to eventually extend this same mechanism to other device drivers such as disk, sound, network etc. By defining a clean, consistent specification for the device driver code such that *all* device specific code is completely separate from any OS specific code, you can properly build device drivers in such a way that they are independant of the internals of the Linux kernel. Of course apart from our graphics device drivers, this is all conjecture on our part, but we have proven the concept on the Windows 95 platform by building a Universal Windows 95 display driver. We get between 80-100% of the performance of IHV drivers, and so far all we have hooked out is solid rectangle fills and bitBlt's! This same device driver architecture will make its debut on the Linux platform hopefully by mid summer, at which point I will try to convince Linus of the merits of our device driver abstraction mechanism. Regards, +--------------------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +--------------------------------------------------------------------------+ | Kendall Bennett | Email: KendallB@scitechsoft.com | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +--------------------------------------------------------------------------+ From ggi-develop-request@eskimo.com Sat Jun 27 17:48:18 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA27135; Sat, 27 Jun 1998 17:48:16 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA32021; Sat, 27 Jun 1998 16:41:23 -0700 Resent-Date: Sat, 27 Jun 1998 16:41:23 -0700 Message-Id: <199806272341.QAA31980@mx1.eskimo.com> From: "Kendall Bennett" Organization: SciTech Software, Inc. To: ggi-develop@eskimo.com Date: Sat, 27 Jun 1998 15:14:22 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: 3Dlabs drivers Priority: normal In-reply-to: References: <199806231658.SAA01278@legrelle.physik.tu-chemnitz.de> from "Steffen Seeger" at Jun 23, 98 06:58:08 pm X-mailer: Pegasus Mail for Win32 (v3.01a) Resent-Message-ID: <"akE7R.0.Dq7.YCObr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3105 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > this is just to inform you that I will be allowed to release 3Dlabs > > driver sources after approval by 3Dlabs. We have to check out the > > details, but basically I got permission to publish them. > > Great - so I'm safe to buy myself a ELSA Winner 2000 Office AGP 8MB ? > > Or is there any catch to watch out for (like AGP doesn't work or something > like that ...) ? AGP is just an extension of PCI; AGP devices sit on PCI bus 1, while PCI devices sit on PCI bus 0 (for the most part; I have not seen anything otherwise so far). Our 3DLabs code works identically on the PCI and AGP parts, and the only real difference is that with AGP devices when you issue a bus master blit, you can use the AGP hardware to do the scatter gather for you, otherwise on PCI you need to ensure you DMA buffer is locked, physically contiguous memory. So yep, I would say the card should work fine... Also note that 3DLabs is one of the 3D reference designs that we are implementing our 3D drivers for in SciTech Display Doctor (ATI 3DRage Pro is the other, and we hope that 3Dfx Banshee will be the third). We plan to have full Linux support implemented by the end of the summer; our summer intern from France will be here next week to start working fulltime on the code! Of course our drivers wont be free, but you will be able to then support any graphics card under Linux/GGI from everything all the way back to the Tseng Labs ET3000 up to the latest 3Dfx Bansheee and Permedia 3! Regards, +--------------------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +--------------------------------------------------------------------------+ | Kendall Bennett | Email: KendallB@scitechsoft.com | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +--------------------------------------------------------------------------+ From ggi-develop-request@eskimo.com Sat Jun 27 17:48:24 1998 Return-Path: Received: from mx1.eskimo.com (root@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA27139; Sat, 27 Jun 1998 17:48:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA24381; Sat, 27 Jun 1998 15:45:09 -0700 Resent-Date: Sat, 27 Jun 1998 15:45:09 -0700 Date: Sat, 27 Jun 1998 15:44:38 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: <35955D44.AE1DC37A@suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"hfCFn2.0.ry5.qNNbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3103 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998, Emmanuel Marty wrote: > Jon M. Taylor wrote: > > > Yes, I can write a wrapper that interfaces nicely with fbcon and > > KGI, but to *do anything* with it, KGI and fbcon need to both be compiled > > into the kernel simultaneously and that causes all sorts of conflicts > > with the console code. That was why I has problems compiling 2.1.107 > > earlier - I applied the 2.1.107 patch to 2.1.106+KGI+EvStack. Once I > > stated over with a clean 2.1.107 it compiled fine. > > Um, no. As I see it the wrapper should provide KGI services to the > driver - you should _not_ need KGI itself; actually drivers don't make a lot > of use of KGI itself besides pci lookup ; what makes use of it is the > linux/i386.c code, and this is what the driver replaces. OK, now I understand. Yes, this should be a *lot* simpler. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sat Jun 27 18:51:16 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA27272; Sat, 27 Jun 1998 18:51:13 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA21135; Sat, 27 Jun 1998 18:47:36 -0700 (PDT) Resent-Date: Sat, 27 Jun 1998 18:47:36 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: ggi/types.h overhaul To: ggi-develop@eskimo.com Date: Sat, 27 Jun 1998 21:53:46 +0200 (MET DST) In-Reply-To: <35950E8E.7C0BFA54@suntech.fr> from "Emmanuel Marty" at Jun 27, 98 03:23:58 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"j0LO02.0.6A5.r2Qbr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3106 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Changes have been commited to the devel repository as it is a "bugfix" (or > so said Andy :) Andy, will you fold that in when moving the frozen tree > into stable, or should I ? If will simply do diff -u --recursive --new-files devel stable >bla; cd stable ; patch -p1 <../bla and then commit. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 27 19:18:14 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA27281; Sat, 27 Jun 1998 19:18:12 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA25162; Sat, 27 Jun 1998 19:17:31 -0700 (PDT) Resent-Date: Sat, 27 Jun 1998 19:17:31 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: 3Dlabs drivers To: ggi-develop@eskimo.com Date: Sun, 28 Jun 1998 03:54:17 +0200 (MET DST) In-Reply-To: <199806272341.QAA31980@mx1.eskimo.com> from "Kendall Bennett" at Jun 27, 98 03:14:22 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"9-UQF2.0.296.vUQbr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3107 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > AGP is just an extension of PCI ... Yep. Thought so. Just wanted to reassure, that there aren't any quirks with using it ... > Of course our drivers wont be free, but you will be able to then > support any graphics card under Linux/GGI from everything all the way > back to the Tseng Labs ET3000 up to the latest 3Dfx Bansheee and > Permedia 3! Yeah. We'll definitely try to make a display target that will run with your drivers. Or will you directly make KGI drivers or something that otherwise interfaces directly to LibGGI ? CU,ANdy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sat Jun 27 21:18:29 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA27331; Sat, 27 Jun 1998 21:18:26 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id VAA23232; Sat, 27 Jun 1998 21:15:51 -0700 Resent-Date: Sat, 27 Jun 1998 21:15:51 -0700 Date: Sun, 28 Jun 1998 00:15:50 -0400 (EDT) From: Brian Julin To: ggi-develop@eskimo.com Subject: Re: GGI datatypes (was RE: Request for system information.) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"jaiXa.0.kg5.tDSbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3108 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Fri, 26 Jun 1998, MenTaLguY wrote: > Maybe it might be better to start using them now in the GGI tree, and just > have a header file with them on hand (basically the existing ggi/types.h > using the POSIX names) that can be conditionally included if the system > doesn't have them itself. Shouldn't be too hard to detect it in the > configure script, a la autoconf or something ... Though the chances are very very slim, someone could thinko and create a system (or a single release of an OS, more likely as they would get yelled at) that uses the POSIX names but doesn't create the right size data types. There are some real bozos out there :). Unless the ggi_* types look unprofessional or presumptuous or something we should keep them IMO. Besides, though uglier than regular C data types they are a heck of a lot more pretty than the POSIX ones. -- Brian S. Julin From ggi-develop-request@eskimo.com Sun Jun 28 01:06:51 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA27544; Sun, 28 Jun 1998 01:06:49 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id AAA22787; Sun, 28 Jun 1998 00:48:21 -0700 Resent-Date: Sun, 28 Jun 1998 00:48:21 -0700 Date: Sun, 28 Jun 1998 00:47:46 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: fbcon-KGI bridge progress Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"3_y_M2.0.xZ5.4LVbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3109 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I spent most of today laying out the groundwork and I finally have a compiling & linking system. The frame buffer devices configuration has one new option, 'KGI driver support', which tells KGI to 'make vga' and bypass the config scripts which are not yet connected to the main linux config system. kernel/i386.c is Andrew's fbcon-KGI wrapper with more tweaking by me. The whole thing compiles and links properly with the kernel, but crashes sometime after boot and there's no display yet. I can't test it as a module because I get the infamous black-on-black characters problem when I enable fbcon |-<. The directory structure is in place: linux/include/kgi linux/include/kgi/IBM linux/drivers/video/kgi linux/drivers/video/chipset linux/drivers/video/accel etc. kgi/input and kgi/modules have been removed, kgi/graphic is now kgi/accel and everything has been updated to account for this. The makefiles and .configs and whatnot are converted to work with the new system as well. I have removed all drivers except VGA or right now to keep the diffs down to a reasonable size during development. I have a patch against 2.1.107 on my website, http://gaia.ecs.csus.edu/~taylorj/kgi-fbcon.patch.gz which I would encourage everyone who can to download and look at. Feedback is appreciated. To-do: - Fix bugs - Link the config system of KGI to Linux's - Remove all the unneeded header files - pull i386 out of kernel/linux and into /kgi and rename and remove kernel/ - Make modules correctly - Port the rest of the KGI drivers Sleep now..... Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sun Jun 28 06:35:35 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA27897; Sun, 28 Jun 1998 06:35:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA28018; Sun, 28 Jun 1998 05:33:19 -0700 Resent-Date: Sun, 28 Jun 1998 05:33:19 -0700 Date: Sun, 28 Jun 1998 14:13:43 +0200 (MEST) From: Matthias Grimrath To: ggi-develop@eskimo.com Subject: Re: job offers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"lYZau3.0.gr6.EWZbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3110 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! On Thu, 25 Jun 1998, Emmanuel Marty wrote: > > USERSPACE | KERNELSPACE > | > libggi <-> fbcon target <- | -> fbcon <-> KGI driver > > (I know I have innate talents for ASCII art, shush :P) > > This isn't either as bad or as complicated as it looks - fbcon > adds another 'middle man' in the fullscreen display scheme, > but once the KGI driver is registered to fbcon, it is > just an extra indirect function call. So that's really > a non-issue. No. Not because it is a technical problem, but rather a political. Why should we adhere to kernel standards that are a) fairly new and only found on devel versions and b) throw our code away (thinking of the scroller code in the evstack part) which is at least as good. We are not conformant with standard kernel anyway and I have always hoped that GGI will come up with superior solutions. > It's not really complicated either, it's basically > about implementing an fbcon display driver (just like > the ton of others that already are in, for m68K displays, > vga text etc, just follow their model) and instead of > rendering to something, translating the mode requests, > palette requests etc into a call into a KGI driver. That sound resonable to me. We keep /dev/graphic and provide a compatibility fbcon module that translates fbcon calls to KGI one. > The wrapper and the KGI driver are linked together at > compilation time just like the linux/i386 driver that we > all use for KGI-kernel display now. Only a translation module, there's no need to link it with the KGI drivers or even mess with them to support fbcon. KGI is KGI and fbcon fbcon. > About EvStack, and the KGI interface version that the wrapper > should conform to : > > Let's face it, the KGI part of EvStack (or Dali for that matter) > will never make it into the main kernel as is, now that fbcon > is standard. Again no. You are proposing to throw code away which was once believed to be the solution of all problems :=) Seriously, AFAIK evstack is now integrated into degas, and I personally like it very much. Setting console, heads, keyboard translation table etc just by echoing to /proc files is very compelling. For that matter, IMHO you simply _cannot_ separate evstack and KGI. AFAIK there's no way in standard kernel to attach/detach keyboards and other input devices on the fly to consoles. If we want to provide libGII one day, this lib will also require evstack. > This is not _necessarily_ a bad thing - of course, the KGI > kernel manager is wasted work, but look at what we get instead : > a fully functional console (no unmapped keys or whatever) > exactly compatible to the original one, and GGI applications > working on the standard kernel. With the wrapper, we allow > for non-suid graphics too. Just because fbcon is in devel kernel now and works doesn't mean we have to trash our code. At least not now. We are still in early devel stage (which is IMHO a shame) and we should be free to code our way. Yes, our consoles have unmapped keys, but that's rather an implementation problem and shows that our progress is slow. Let the user decide - if GGI is good, GGI will be adopted and fbcon forgetten. Standard kernel != good. Not necessarily. (For example, I never liked /dev/vcsa??) > I propose that the KGI wrapper complies to the Dali driver API; > the drivers are already here and work. If we begin moving all of > that to the EvStack API, it will be a nightmare. I propose > we use the Dali API. The notable changes in the evstack one, > notably about text management, are handled by fbcon itself > anyway. AAARRGGG. Sorry... Do you say that the repository was closed for 3 month, development was reduced to a minimum, just to step backwards now to the 0.0.9 API? IIRC, there were good reasons to justify a major change in the driver API. Adapting the drivers is quite some work, but doable. And once again, I don't care about fbcon. > Please everyone comment that My comments are harnish, and it was my intent actually. Over the last month I've had the impression that some of you are too "soft" - libGGI should run on the oldest and most braindamaged hardware; KGI must adapt to standard kernel, because GGI should be in it by 2.3.X; GGI never stands a chance against standard linux kernel; too much compromises... Bull. IMO GGI can survive as a patch to standard kernel. If people start using GGI for their apps, distributors will ship their CDs with the GGI patch. We needn't look at the kernel folks too much. They are not god or something; I think we all had our visions when we joined the GGI devel team, and IMO we should work on making our dreams come true first. And sometimes we must say "NO" even if that is different from other peoples ideas / implementations. Sometimes we have to make compromises, sometimes we are better off going into contest. If we are good we have a good chance to win. Hard, emotionial words. But that's how I feel. Matthias Grimrath From ggi-develop-request@eskimo.com Sun Jun 28 07:18:23 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA27934; Sun, 28 Jun 1998 07:18:21 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA24095; Sun, 28 Jun 1998 06:54:17 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 06:54:17 -0700 (PDT) X-Authentication-Warning: cassiopeia.home: geert owned process doing -bs Date: Sun, 28 Jun 1998 00:08:09 +0200 (MET DST) From: Geert Uytterhoeven Sender: geert@geert.cs.kuleuven.ac.be To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"wStKi1.0.Mu5.7iabr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3111 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998, Jon M. Taylor wrote: > On Sat, 27 Jun 1998, Emmanuel Marty wrote: > > Right now, all you need is to write a replacement 'kernel driver' part for > > the KGI module. What it will basically do is, provide the services to > > the driver that KGI did usually (pci lookup, etc.); at init, register the > > driver > > as a framebuffer device to fbmem (look at other fb drivers), then when > > fbcon sends command to that fbmem device, just translate mode > > requests etc and call the appropriate KGI commands. > > This works fine for the driver modules, but to insert them I still > have to have the KGI framework (kgi.c, etc) compiled into the kernel at > boot time. Can't kgi be a loadable kernel module, too? > > And we won't dump CVS - simply, when drivers are stable and tested, > > on a regular basis, we'll send a diff to Geert or Alan; the main kernel > > will be lagged behind a few releases, but that's life. Yep. Or send it yourself to linux-patches. The tree at vger.rutgers.edu is under CVS too. But if you want something merged with Linus, you have to send a patch (or wait until DaveM does that for you :-) > What happens when Joe Linux User sees a problem in one of the > drivers and sends a patch to Linus instead of us? Isn't this similarly to the commercial OSS sound drivers? AFAIK (I don't have sound on Intel machines) they just provide you with loadable kernel modules. (KGI drivers would be even better, because you have the source :-) So I suppose people complain to the wrong people about OSS sound drivers, too? Assuming people who actually write patches are smarter than Joe User who just insmods binaries made by others, I think it won't be that bad. Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium From ggi-develop-request@eskimo.com Sun Jun 28 08:24:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA27956; Sun, 28 Jun 1998 08:24:15 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id IAA00650; Sun, 28 Jun 1998 08:19:45 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 08:19:45 -0700 (PDT) Date: Sun, 28 Jun 1998 17:10:59 +0200 (MEST) From: Jan Kneschke To: ggi-develop@eskimo.com Subject: tutorial for ggi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"PNijw1.0._9.Fybbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3112 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com 1. since i don't have the new drivers-guide i can't rewrite the new s3-vision driver (hint, hint) 2. the kiel-week is nearly finish, just a big firework will come up today evening. (kiel-week: biggest sailing event in the world/biggest party in our region => many headaches) 3. i passed the first part of my exams and so i have plenty of time and just want to hack something. as someone said, we have to attract outside developers for ggi. i just want to start a tutorial the discribes the steps for writing a ggi-program. on the one hand i will do this for diving into libggi, on the other libggi will become easier to understand for all the newbies that will come along sometime. the first step is easy: ggiInit(); ggiOpen(); setGraphMode(); ggiPuts("HELLO WORLD"); (wait) setTextMode(); ggiClose(); ggiExit(); i think the next step will be getBox/putBox example. what about "hello world" moving over the display transformed over an sinus ? after that some clipping? BTW: is there a definition in libggi for inner and outer clipping ?? virge can do it. but what after this basic steps ?? can you give me some advices ?? i don't know if someone had already a look at the Qt-tutorial which is quite easy to understand. it shows you just the first steps to use the toolkit, enough to stay on your feet. thats all Jan --- Project: GGI - S3-Vision-driver -- http://www.ggi-project.org/ -)= Jan (Weigon) Kneschke -- Kiel -- Northern Germany =(- From ggi-develop-request@eskimo.com Sun Jun 28 09:04:44 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA27991; Sun, 28 Jun 1998 09:04:38 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA21014; Sun, 28 Jun 1998 08:54:58 -0700 Resent-Date: Sun, 28 Jun 1998 08:54:58 -0700 Date: Sun, 28 Jun 1998 11:54:41 -0400 (EDT) From: Steve Cheng Sender: steve@maxt5m42.ipoline.com To: ggi-develop@eskimo.com Subject: Re: tutorial for ggi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"k5kGX.0.E85.HTcbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3113 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Jan Kneschke wrote: > as someone said, we have to attract outside developers for ggi. i just want > to start a tutorial the discribes the steps for writing a ggi-program. on > the one hand i will do this for diving into libggi, on the other libggi will > become easier to understand for all the newbies that will come along sometime. Ok. There is a very simple getting-started tutorial in the libggi SGML docs. May be you might want to start there... -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Sun Jun 28 09:22:31 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA28002; Sun, 28 Jun 1998 09:22:29 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA26729; Sun, 28 Jun 1998 09:20:31 -0700 Resent-Date: Sun, 28 Jun 1998 09:20:31 -0700 Message-Id: <199806281620.SAA26684@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: tutorial for ggi In-reply-to: Your message of "Sun, 28 Jun 1998 17:10:59 +0200." Date: Sun, 28 Jun 1998 18:20:31 +0200 From: Marcus Sundberg Resent-Message-ID: <"yuoTy1.0.RX6.Ercbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3114 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com the first step is easy: ggiInit(); ggiOpen(); setGraphMode(); + ggiSetInfoFlags(GGIFLAG_ASYNC); ggiPuts("HELLO WORLD"); + ggiFlush(); (wait) - setTextMode(); ggiClose(); ggiExit(); //Marcus From ggi-develop-request@eskimo.com Sun Jun 28 09:39:44 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA28012; Sun, 28 Jun 1998 09:39:42 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA28778; Sun, 28 Jun 1998 09:27:34 -0700 Resent-Date: Sun, 28 Jun 1998 09:27:34 -0700 Message-Id: <199806281627.SAA07462@zafir.e.kth.se> To: ggi-develop@eskimo.com cc: e94_msu@elixir.e.kth.se Subject: Re: CVS mirrors and guest access. In-reply-to: Your message of "Thu, 25 Jun 1998 21:49:07 +0200." Date: Sun, 28 Jun 1998 18:27:35 +0200 From: Marcus Sundberg Resent-Message-ID: <"IqsIt1.0.V17.rxcbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3115 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Hello Marcus, Hi! > I understand perfectly.. Please forgive me for the rather unnice > reply, I had a rather stressful day then as well; I'm working hard > on something, and my girlfriend isn't really giving me a break > either (when I am upset without apparent reason, you can bet your > life that it is related to her :) I hope I haven't offended or worried > you, else I'm terribly sorry. Nah, don't worry - I'm not that easy to offend. ;) > > I'm very grateful that we finally got a working CVS > > repository again and didn't mean to blame you for anything. > > Thanks .. And I didn't take it that way, no worries (well I did > on the moment but that was rather stupid of me, my apologies > again). > > Now that Todd handles the anonymous CVS traffic, is it working > better ? I have stopped watching Unisource packet losses so > I wouldn't get depressed, so just let me know your general > feeling.. :) I haven't done any real testing but it feels somewhat faster now. At least before ~11PM there're no problems. //Marcus From ggi-develop-request@eskimo.com Sun Jun 28 09:40:25 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA28017; Sun, 28 Jun 1998 09:40:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA31980; Sun, 28 Jun 1998 09:37:33 -0700 Resent-Date: Sun, 28 Jun 1998 09:37:33 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Future of GGI project To: ggi-develop@eskimo.com Date: Sun, 28 Jun 1998 04:13:52 +0200 (MET DST) In-Reply-To: from "Jon M. Taylor" at Jun 27, 98 02:39:34 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"t0UHO2.0.ap7.D5dbr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3116 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > *grin* Adding a single ioctl to fbcon will do. > > So all KGI ioctls would be wrapped in that one ioctl? Yeah - It's just a matter of placing the commandcode which is currently the ioctl value to the start of the struct that is transmitted. Should be simple as hell. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 28 09:51:19 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA28028; Sun, 28 Jun 1998 09:51:18 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA08427; Sun, 28 Jun 1998 09:42:15 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 09:42:15 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Future of GGI project To: ggi-develop@eskimo.com Date: Sun, 28 Jun 1998 12:24:55 +0200 (MET DST) In-Reply-To: from "Jon M. Taylor" at Jun 27, 98 12:58:08 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"48EnE2.0.Y32.b9dbr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3117 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Isn't the userland part of the driver part of LibGGI? If so it is > IMHO *not* part of KGI and should be treated as such. LibGGI is no longer > the userland portion of KGI. What if someone wants to use KGI drivers > directly or their own X server, for example? It is something in between. The userland parts of the drivers should be considered part of KGI for distribution purposes, because you will then get everything needed to make a particular card work in a single package. However from the programming perspective the individual userland drivers can be considered being part of the respective API. > > I think it would be healthy to experiment more with a system which > > includes both kgi and a userland library to come up with a system on > > which it is possible to do driver development independent on what api > > libggi exports. I don't think this will provide for well optimized acceleration. You sometimes have to optimize code-flow very different for different cards. > > This system would only deal with how acceleration commands flow between > > the library, kgi and the graphics card, and would Such a system is in place and can be found in the "ioctl" driver lib, which should be renamed to "kgi-command" instead of "generic-ioctl". However for highly optimized drivers that doesn't cut it. You also need to know how you can e.g. group commands efficiently, when the break-even for calling the accel vs. using mmaped buffer is reached, ... > To get optimal efficiency when talking directly to KGI, you may > well need to recode the flow of control for each application (X, Mesa, > LibGGI2D, etc). I don't see the common ground you are referring to > above. If you disconnect the userspace drivers from interfacing to a > particular API, you lose some ability to optimize for that API. Yep. This is the whole purpose of the Extension scheme. To be able to make perfectly optimized subdrivers for all subsystems. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 28 10:25:49 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA28068; Sun, 28 Jun 1998 10:25:46 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA04012; Sun, 28 Jun 1998 10:15:07 -0700 Resent-Date: Sun, 28 Jun 1998 10:15:07 -0700 Date: Sun, 28 Jun 1998 10:07:17 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: Future of GGI project In-Reply-To: <3594D413.17546C54@vertech.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"PMEAn1.0.V-.Redbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3118 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998, Torgeir Veimo wrote: > Jon M. Taylor wrote: > > > > We're not gonna get all the accelerations we > > wanted, but you gotta compromise sometime.... > > We'll eventually get all the acceleration we need... ;) Yeah, just patch the kernel. That's what you're doing now, isn't it? :-) Please excuse my ignorance, but what is fbcon and vgafb? Can someone plese (privately?) e-mail me some information on this? I'd like to know what they are before I start making any responses on this list. Thanks. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Sun Jun 28 10:55:44 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA28110; Sun, 28 Jun 1998 10:55:41 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA14550; Sun, 28 Jun 1998 10:56:30 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 10:56:30 -0700 (PDT) Date: Sun, 28 Jun 1998 10:41:20 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: Future of GGI project In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"GgLc32.0.EZ3.CFebr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3120 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Sure we progress, but we remain an insular, isolated community of > developers. We have too much Cathedral and not enough Bazaar for a > project that is now almost 3 years old. Quite frankly, we have a real Part of your problem is that, with the possible exception of LibGGI, you're dealing with an EXTREMELY visible part of an operating system: that of visual display. If *anything* in KGI fails, there's a very good chance that you cannot use the system AT ALL to recover (precisely the reason I never use GGI in the kernel anymore). If people see their OS crash everytime on boot-up, they're NOT going to like GGI very much, and they WILL tell their friends. Same thing if GGI-Linux boots, but isn't able to use a single graphics mode. The last release of 0.0.9 which I installed (some months back, admittedly; before the CVS freeze) had significant problems with my kernel. It *ALWAYS* reported that *ALL* graphics devices were always busy. This is precisely the same bug I had reported when I tested 0.0.8, and two prior snapshots of 0.0.9. I'm willing to bet, with money, that it'd do the same thing on my current system. And yes, this includes the stock VGA driver. (There was one time when Linux itself wouldn't boot due to a kernel panic.) Eventually, I just stopped reporting the bugs, because a) I didn't have time to work on the KGI myself, b) nobody ever responded to my bug reports. So while you GGI/KGI developers are happily working away on YOUR working systems, there are probably a huge number of kernels where GGI simply and plainly does not work. Period. :) And no, I'm not blaming you in any way. I've dealt with tons of programming problems where program A would work on machine B, but not on machine C, despite having equal configurations in every software respect. > problem attracting outside development assistance because we keep to > ourselves so much. We are all good coders (and some of us (not me) are > brilliant designers), or the project wouldn't be where it is today. But True, but things take time. Perhaps three years isn't "the time" for GGI. Do not be so hasty. I'd rather switch to GGI three years from NOW if it worked, rather than have GGI now, and not able to use it, and it being unheard of in three years time because of all the problems it's having now. > we *need* to break out of our niche and get out ideas accepted by the open > source community at large, and to do that effectively we need to > streamline our organization, clear up our message(s) and refocus > ourselves. Try submitting your stuff to Freshmeat or Slashdot. I've yet to see any GGI-related announcements there. http://slashdot.org/. Freshmeat has a link on Slashdot's web page. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Sun Jun 28 10:56:39 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA28124; Sun, 28 Jun 1998 10:56:37 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA10929; Sun, 28 Jun 1998 10:53:13 -0700 Resent-Date: Sun, 28 Jun 1998 10:53:13 -0700 Sender: mee@daimi.aau.dk Message-ID: <35968304.B8BC8B83@daimi.aau.dk> Date: Sun, 28 Jun 1998 19:53:08 +0200 From: Martin Eli Erhardsen X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX64 6.4 IP30) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: IRIX port and ggiEventPut Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_lJEo.0.Xg2.8Cebr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3119 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I have gotted libggi to compile on IRIX 6.3, and I have run checkmode and speed successfully under X. Here are some speed numbers from a O2 over a network. Line 1: 1335113.484646 7.060000 0.430000 Line 10: 632911.392405 1.500000 0.080000 Line 100: 143061.516452 6.570000 0.420000 Box 1: 1464128.843338 6.450000 0.380000 Box 10: 228832.951945 4.130000 0.240000 Box 100: 23041.474654 4.070000 0.270000 The problem is that I don't know what to do about ggiEventPut It appears that ggiEventPut function is only put into the libggi on SGI machines. This causes a error, because the header neded to compile it is ifdefed out. There don't appear to be any prototypes for ggiEventPut, but it is mentioned in the documentation. Should ggiEventPut be removed from libggi ? From ggi-develop-request@eskimo.com Sun Jun 28 10:59:24 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA28129; Sun, 28 Jun 1998 10:59:21 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA12907; Sun, 28 Jun 1998 10:59:30 -0700 Resent-Date: Sun, 28 Jun 1998 10:59:30 -0700 Sender: core@orb.suntech.fr Message-ID: <359683FB.2E1955DC@suntech.fr> Date: Sun, 28 Jun 1998 17:57:15 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: IRIX port and ggiEventPut References: <35968304.B8BC8B83@daimi.aau.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Va-rI.0.V93._Hebr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3121 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I have gotted libggi to compile on IRIX 6.3, and I have > run checkmode and speed successfully under X. libggi has been running on IRIX 5.x/6.x since november, when I spent a whole night removing all GNUisms that people had happily put all over :) IIRC this also server as a base port to all other non-gcc platforms. However, my O2 is currently not in very good shape, so I haven't been able to hunt those for a month now - thanks for fixing things .. > It appears that ggiEventPut function is only put into the > libggi on SGI machines. This causes a error, because the header > neded to compile it is ifdefed out. When I did the port, ggiEventPut() was used ; it has been removed in the meantime, but the corresponding non-inline function in events.c hasn't been removed, apparently. > Should ggiEventPut be removed from libggi ? Well, if nothing makes uses of it anymore and it is #if'ed out, goahead, yes. -- Emmanuel From ggi-develop-request@eskimo.com Sun Jun 28 11:15:43 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA28205; Sun, 28 Jun 1998 11:15:41 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA14950; Sun, 28 Jun 1998 11:03:57 -0700 Resent-Date: Sun, 28 Jun 1998 11:03:57 -0700 Date: Sun, 28 Jun 1998 10:56:05 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: tutorial for ggi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Qm3re1.0.Of3.CMebr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3122 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > the first step is easy: > > ggiInit(); > ggiOpen(); > setGraphMode(); > ggiPuts("HELLO WORLD"); > > (wait) > > setTextMode(); > ggiClose(); > ggiExit(); This is pretty specific, I think. Too specific for beginners. The problem is that I don't use, nor will I ever use, KGI in my Linux system. I have had nothing but bad luck with it. :( I think it'd be best to start with, say, an X target -- get them used to something they know first. Then, later on, work with non-X targets, such as KGI. But then, that's just me... :) > after that some clipping? BTW: is there a definition in libggi for inner and > outer clipping ?? virge can do it. Should provide a software implmeentation as well for hardware which cannot handle it. > but what after this basic steps ?? can you give me some advices ?? Color palette manipulation, off-screen rendering, and to test the console/input drivers, make a hypothetical mouse pointer editor. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Sun Jun 28 11:29:15 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA28210; Sun, 28 Jun 1998 11:29:12 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA19905; Sun, 28 Jun 1998 11:13:30 -0700 Resent-Date: Sun, 28 Jun 1998 11:13:30 -0700 Sender: mee@daimi.aau.dk Message-ID: <359687C9.56C0153A@daimi.aau.dk> Date: Sun, 28 Jun 1998 20:13:29 +0200 From: Martin Eli Erhardsen X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX64 6.4 IP30) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: IRIX port and ggiEventPut References: <35968304.B8BC8B83@daimi.aau.dk> <359683FB.2E1955DC@suntech.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-E1VW3.0.ps4.8Vebr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3123 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Emmanuel Marty wrote: > > > I have gotted libggi to compile on IRIX 6.3, and I have > > run checkmode and speed successfully under X. > > libggi has been running on IRIX 5.x/6.x since november, when I spent a whole > night removing all GNUisms that people had happily put all over :) IIRC this > also server as a base port to all other non-gcc platforms. However, my O2 is > currently not in very good shape, so I haven't been able to hunt those for a > month now - thanks for fixing things .. > > > It appears that ggiEventPut function is only put into the > > libggi on SGI machines. This causes a error, because the header > > neded to compile it is ifdefed out. > > When I did the port, ggiEventPut() was used ; it has been removed in > the meantime, but the corresponding non-inline function in events.c > hasn't been removed, apparently. > > > Should ggiEventPut be removed from libggi ? > > Well, if nothing makes uses of it anymore and it is #if'ed out, goahead, yes. > I have just disabled it with a #if 0 , in case someone should need it later. From ggi-develop-request@eskimo.com Sun Jun 28 11:41:44 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA28219; Sun, 28 Jun 1998 11:41:42 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA29176; Sun, 28 Jun 1998 11:38:33 -0700 Resent-Date: Sun, 28 Jun 1998 11:38:33 -0700 Message-Id: <199806281838.UAA06753@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: Future of GGI project In-reply-to: Your message of "Sun, 28 Jun 1998 10:41:20 PDT." Date: Sun, 28 Jun 1998 20:38:32 +0200 From: Marcus Sundberg Resent-Message-ID: <"ONvZ91.0.g77.esebr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3124 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > the first step is easy: > > > > ggiInit(); > > ggiOpen(); > > setGraphMode(); > > ggiPuts("HELLO WORLD"); > > > > (wait) > > > > setTextMode(); > > ggiClose(); > > ggiExit(); > > This is pretty specific, I think. Too specific for beginners. The > problem is that I don't use, nor will I ever use, KGI in my Linux system. > I have had nothing but bad luck with it. :( > > I think it'd be best to start with, say, an X target -- get them used to > something they know first. Then, later on, work with non-X targets, such > as KGI. GGI (application) programmers don't work with targets, they work with libggi and needn't know anything about targets. What makes you think that the above code is specific to the KGI-target? //Marcus From ggi-develop-request@eskimo.com Sun Jun 28 11:42:17 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA28224; Sun, 28 Jun 1998 11:42:11 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA29261; Sun, 28 Jun 1998 11:39:18 -0700 Resent-Date: Sun, 28 Jun 1998 11:39:18 -0700 Date: Sun, 28 Jun 1998 14:38:59 -0400 (EDT) From: Steve Cheng Sender: steve@maxt7m37.ipoline.com To: ggi-develop@eskimo.com Subject: Re: IRIX port and ggiEventPut In-Reply-To: <35968304.B8BC8B83@daimi.aau.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"49RxF2.0.497.Ltebr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3125 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Martin Eli Erhardsen wrote: > The problem is that I don't know what to do about ggiEventPut > > It appears that ggiEventPut function is only put into the > libggi on SGI machines. This causes a error, because the header > neded to compile it is ifdefed out. Yes, ggiEvent* are functions from Dali that are no longer supported by Degas/EvSTack. > There don't appear to be any prototypes for ggiEventPut, > but it is mentioned in the documentation. It should be removed from the documentation. > Should ggiEventPut be removed from libggi ? It should have been. (at least under Linux...) -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Sun Jun 28 12:41:22 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA28282; Sun, 28 Jun 1998 12:41:20 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA10375; Sun, 28 Jun 1998 12:33:43 -0700 Resent-Date: Sun, 28 Jun 1998 12:33:43 -0700 Date: Sun, 28 Jun 1998 21:33:41 +0200 (CEST) From: Geert Uytterhoeven To: GGI mailing list Subject: Re: fbcon-KGI bridge progress In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"e6hHb2.0._X2.Ngfbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3126 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Jon M. Taylor wrote: > I spent most of today laying out the groundwork and I finally have > a compiling & linking system. The frame buffer devices configuration has > one new option, 'KGI driver support', which tells KGI to 'make vga' and > bypass the config scripts which are not yet connected to the main linux > config system. kernel/i386.c is Andrew's fbcon-KGI wrapper with more ^^^^^^ Aarghl! I want to get my Vision968 working in my CHRP box! > tweaking by me. The whole thing compiles and links properly with the > kernel, but crashes sometime after boot and there's no display yet. I > can't test it as a module because I get the infamous black-on-black > characters problem when I enable fbcon |-<. Replace ioremap() in vgafb.c by bus_to_virt(). Or use the vger tree :-) > - pull i386 out of kernel/linux and into /kgi and rename and remove kernel/ Aah... Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium From ggi-develop-request@eskimo.com Sun Jun 28 12:52:41 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA28293; Sun, 28 Jun 1998 12:52:39 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA11622; Sun, 28 Jun 1998 12:45:13 -0700 Resent-Date: Sun, 28 Jun 1998 12:45:13 -0700 Sender: injector@clubneon.dyn.ml.org Message-ID: <35969CEE.28EA55B2@stu.ac.cc.md.us> Date: Sun, 28 Jun 1998 15:43:42 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: tutorial for ggi References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ymdMP3.0.Ur2.8rfbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3127 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jan Kneschke wrote: > > but what after this basic steps ?? can you give me some advices ?? How about the "proper" way to get keypresses (since demo.c doesn't use it)? Something simple like moving box on the screen with the arrow key that leaves trails behind (see the svgalib demos). -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". From ggi-develop-request@eskimo.com Sun Jun 28 13:22:14 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA28317; Sun, 28 Jun 1998 13:22:11 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA27940; Sun, 28 Jun 1998 13:17:35 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 13:17:35 -0700 (PDT) To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: Future of GGI project Date: 28 Jun 1998 20:14:41 GMT Organization: OnTV Pittsburgh, L.P. Lines: 31 Sender: Jason McMullan Distribution: local Message-ID: <6n687h$3l6$1@butter.visus.com> References: <6n2bd5$knf$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.34 (i586)) Resent-Message-ID: <"vr8Qk2.0.Nq6.TJgbr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3128 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon M. Taylor wrote with confidence: > Lotta stuff has been happening lately: > [snip snip snip] > All of this turmoil needs to be resolved. The idea of splitting > up the GGI project has been proposed in the past, by myself and others, > but I feel I need to bring it up again in light of the current situation. > I feel that the current chaos *cries* out for this solution. With the > loss of input devices and consoles, KGI will be pretty disjoint from > EvStack, and with the way that KGI and EvStack are becoming extensions of > Linux (and FreeBSD, hopefully), the overlap between the three major parts > o the GGI project are now almost completely disjoint from each other. I agree. I'm pretty heavy into the EvStack console subsystem (needed for the ADB support on the PowerPC macs anyway) and a little into some of the KGI underpinnings. Steffen is re-working the KGI layer and I no longer have any clue at to what Andreas is up to in libGGI - he's too fast! ;^) [Now I just need to subscribe to that linux-input list....] -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Sun Jun 28 13:27:38 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA28336; Sun, 28 Jun 1998 13:27:36 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA19412; Sun, 28 Jun 1998 13:20:15 -0700 Resent-Date: Sun, 28 Jun 1998 13:20:15 -0700 To: ggi-develop@eskimo.com Path: not-for-mail From: Jason McMullan Newsgroups: lists.linux.ggi Subject: Re: job offers Date: 28 Jun 1998 20:24:45 GMT Organization: OnTV Pittsburgh, L.P. Lines: 40 Sender: Jason McMullan Distribution: local Message-ID: <6n68qd$3l6$2@butter.visus.com> References: <6n1q3t$epd$1@butter.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: pepsi.visus.com User-Agent: tin/pre-1.4-980117 (UNIX) (Linux/2.0.34 (i586)) Resent-Message-ID: <"7qflp2.0.Cl4._Lgbr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3129 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon M. Taylor wrote with confidence: > Take away all messaging stuff (EvStack) and the drivers > themselves, and what is left of KGI isn't too much. But if we are going > to split the KGI video driver layer and its associated drivers away from > any console stuff and EvStack, this should be formally decided upon and > plans made to modify the repository appropriately (i.e. remove KGI > altogether o it is relly going into the kernel proper). Also, IMHO this > change would further justify a complete separation of EvStack and GGI into > separate projects. EvStack is ready for a split. All KGI access goes through the `kgiscroll' module. I'll be writing a fbscroll module for my PowerPC Mac work (which I plan to start as soon as the ExWife moves all her stuff out). Anyhow, separating KGI from EvStack should be easy. Making sure you can rmmod(1) inserted KGI modules under fbcon, on the other hand.... ;^) Eventually I'll submit the EvStack/fbcon stuff as a console replacement for the kernel (probably around December - well into 2.3.x devel). Then, you can select to use EvStack/KGI or EvStack/fbcon or fbcon/KGI or just fbcon or... - and let the best system win! > What about acceleration, what last I looked was not supported > generally by fbcon? AFAIK they have a blit ioctl but that's it. This > issue has always been at the heart of the disagreements between GGI and > Linus. The current state of accel support in the KGI drivers is largely > confined to 2-D stuff that could easily be used by fbcon as it stands now, > though. According to Geert, fbcon acceleration is just a mmap on accel registers - it required setuid-root (blech - which is why we started GGI in the first place!) -- Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc On the wonderful world of Microsoft Products: Why put fault tolerance in the OS, when it's already built into the User? -- Steve Shaw comp.os.linux.advocacy From ggi-develop-request@eskimo.com Sun Jun 28 13:47:24 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA28354; Sun, 28 Jun 1998 13:47:22 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id NAA01391; Sun, 28 Jun 1998 13:42:53 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 13:42:53 -0700 (PDT) Date: Sun, 28 Jun 1998 13:27:39 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: Future of GGI project In-Reply-To: <199806281838.UAA06753@zafir.e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"FVoe12.0.aL.Bhgbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3130 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Marcus Sundberg wrote: > What makes you think that the above code is specific to the > KGI-target? Setting the visual to graphics mode, doing your thing, then setting it back to text mode before releasing it. That's pretty PC hardware specific, I think. And yes, GGI developers DO need to know about targets. Otherwise, how would you be able to open a printer visual? Or an off-screen bitmap? :-) ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Sun Jun 28 14:13:45 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA28379; Sun, 28 Jun 1998 14:13:43 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA25773; Sun, 28 Jun 1998 14:01:34 -0700 Resent-Date: Sun, 28 Jun 1998 14:01:34 -0700 Date: Sun, 28 Jun 1998 23:01:32 +0200 (CEST) From: Geert Uytterhoeven To: ggi-develop@eskimo.com Subject: Re: job offers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"eSmxU.0.bI6.jygbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3131 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Matthias Grimrath wrote: > On Thu, 25 Jun 1998, Emmanuel Marty wrote: > > > > USERSPACE | KERNELSPACE > > | > > libggi <-> fbcon target <- | -> fbcon <-> KGI driver > > > > (I know I have innate talents for ASCII art, shush :P) > > > > This isn't either as bad or as complicated as it looks - fbcon > > adds another 'middle man' in the fullscreen display scheme, > > but once the KGI driver is registered to fbcon, it is > > just an extra indirect function call. So that's really > > a non-issue. > > No. Not because it is a technical problem, but rather a political. Why > should we adhere to kernel standards that are a) fairly new and only found ^^^^^^^^^^ ... in Linus' kernel. People always tend to forget how old frame buffer devices are... They date back to the end of 1994. Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium From ggi-develop-request@eskimo.com Sun Jun 28 14:26:20 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA28393; Sun, 28 Jun 1998 14:26:19 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA26779; Sun, 28 Jun 1998 14:11:52 -0700 Resent-Date: Sun, 28 Jun 1998 14:11:52 -0700 Message-ID: <19980628230930.A11530@loria.fr> Date: Sun, 28 Jun 1998 23:09:30 +0200 From: Olivier Galibert To: ggi-develop@eskimo.com Subject: Re: job offers Mail-Followup-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Geert Uytterhoeven on Sun, Jun 28, 1998 at 11:01:32PM +0200 Resent-Message-ID: <"n8lAO2.0.EY6.M6hbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3132 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, Jun 28, 1998 at 11:01:32PM +0200, Geert Uytterhoeven wrote: > ... in Linus' kernel. People always tend to forget how old frame buffer devices > are... They date back to the end of 1994. ... and are on the way out, actually. OG. From ggi-develop-request@eskimo.com Sun Jun 28 14:39:10 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA28406; Sun, 28 Jun 1998 14:39:07 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id OAA31889; Sun, 28 Jun 1998 14:29:56 -0700 Resent-Date: Sun, 28 Jun 1998 14:29:56 -0700 X-Authentication-Warning: tightan.freenet.org: tbcx owned process doing -bs Date: Sun, 28 Jun 1998 23:39:02 +0000 (GMT) From: Erlend Hoel X-Sender: tbcx@tightan.freenet.org To: GGI mailing list Subject: Re: fbcon-KGI bridge progress In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"aa3K62.0.8o7.KNhbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3133 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Jon M. Taylor wrote: > I can't test it as a module because I get the infamous black-on-black > characters problem when I enable fbcon |-<. FWIW (probably less than 0.02) I tried compiling a stock 2.1.107 kernel with fbcon enabled, and got a black on black myself. This was with a standard as-is kernel downloaded from nic.funet.fi - so what I'm getting at is that this might not have anything to do with your hacks, this might well be how fbcon operates in its present state. Oh - I have a SPEA card (S3 Vision964, ics9161a clockchip). Regards, Erlend _____ ___ TightByte on IRC, NOVA[CON] in Quake. |_ _| _ _ | _ \ _email: tbcx@dds.nl (or tbcx@online.no, | |(_) __ | |_ | |_|(_)/_ _| |____ehoel@sdata.no, ehoel@trollnet.no) | || |/__\| ' \| /|(_)\ \ / | / -_) WWW: huizen.dds.nl/~tbcx |_||_|\_ |_||_|_| |___/\ V /|_|\___) Get real? Sure: Erlend Hoel, _/ / _/ / Rundtjernveien 5, 0672 OSLO, NORWAY |__/ |__/ Tel: +47 22 26 00 75 Cellular: (none yet) From ggi-develop-request@eskimo.com Sun Jun 28 15:59:47 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA28494; Sun, 28 Jun 1998 15:59:44 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA19326; Sun, 28 Jun 1998 15:55:30 -0700 Resent-Date: Sun, 28 Jun 1998 15:55:30 -0700 Date: Sun, 28 Jun 1998 15:55:24 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: job offers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"BUDiv.0.qj4.Wdibr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3135 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Matthias Grimrath wrote: > Hi! > > On Thu, 25 Jun 1998, Emmanuel Marty wrote: > > > > > USERSPACE | KERNELSPACE > > | > > libggi <-> fbcon target <- | -> fbcon <-> KGI driver > > > > (I know I have innate talents for ASCII art, shush :P) > > > > This isn't either as bad or as complicated as it looks - fbcon > > adds another 'middle man' in the fullscreen display scheme, > > but once the KGI driver is registered to fbcon, it is > > just an extra indirect function call. So that's really > > a non-issue. > > No. Not because it is a technical problem, but rather a political. It certainly is a political problem, and this is a political solution. Politics is the art of compromise, and up until now the GGI project has not been willing to compromise *at all*. > Why > should we adhere to kernel standards that are a) fairly new and only found > on devel versions The fbcon code has been around in the m68k code since 1994 or so. It is not at all new. > and b) throw our code away (thinking of the scroller code > in the evstack part) which is at least as good. Technically, yes. However it is less standard WRT expected linux console behavior and that counts for a LOT right now. > We are not conformant with > standard kernel anyway and I have always hoped that GGI will come up with > superior solutions. This fight is EvStack's now, not KGI's. KGI has the chance to get into the kernel proper now, providing us with respectability and a beachhead for the the future. It will give LibGGI a lot of much-needed exposure (people are STILL working on SVGALib, for RMS' sake!) and maybe make people look more kindly on EvStack when it's time to shine comes. > > It's not really complicated either, it's basically > > about implementing an fbcon display driver (just like > > the ton of others that already are in, for m68K displays, > > vga text etc, just follow their model) and instead of > > rendering to something, translating the mode requests, > > palette requests etc into a call into a KGI driver. > > That sound resonable to me. We keep /dev/graphic and provide a > compatibility fbcon module that translates fbcon calls to KGI one. I like Andy's "wrapper ioctl" idea better - add one more ioctl to fbcon which is used to tunnel through to the KGI layer directly. Having two devices controlling the same hardware at the same time is asking for synchronization problems. > > The wrapper and the KGI driver are linked together at > > compilation time just like the linux/i386 driver that we > > all use for KGI-kernel display now. > > Only a translation module, there's no need to link it with the KGI drivers > or even mess with them to support fbcon. KGI is KGI and fbcon fbcon. But this way you don't actually have to have KGI proer (kgi.c, graphic.c, etc) compiled into the kernel proper to use KGI dirvers under fbcon. All you need is the bridge layer which translates the function calls. > > About EvStack, and the KGI interface version that the wrapper > > should conform to : > > > > Let's face it, the KGI part of EvStack (or Dali for that matter) > > will never make it into the main kernel as is, now that fbcon > > is standard. > > Again no. You are proposing to throw code away which was once believed to > be the solution of all problems :=) Not throw it away, but throw it *out* - of KGI and into EvStack, where it really belongs anyway. > Seriously, AFAIK evstack is now > integrated into degas, and I personally like it very much. Setting console, > heads, keyboard translation table etc just by echoing to /proc files is very > compelling. Yes, but IMHO "the GGI console" as it exists in Degas currently is a bad idea becuase it mixes together KGI and EvStack. But this is just a name game really - rename a couple of files, change some function names and presto, all that stuff dealing with input devices and consoles is now part of EvStack. > For that matter, IMHO you simply _cannot_ separate evstack and KGI. Yes. You have to go the opposite way and *merge* KGI into EvStack. > AFAIK > there's no way in standard kernel to attach/detach keyboards and other input > devices on the fly to consoles. If we want to provide libGII one day, this > lib will also require evstack. EvStack is a wonderful idea, but it is really about consoles and input devices, not graphics. KGI is a great idea too, but it is really about a nice video driver model and not about consoles. Either should be useable without the other (KGI+fbcon or EvStack+old kernel drivers), even though we all hope to have KGI+EvStack eventually. > > This is not _necessarily_ a bad thing - of course, the KGI > > kernel manager is wasted work, but look at what we get instead : > > a fully functional console (no unmapped keys or whatever) > > exactly compatible to the original one, and GGI applications > > working on the standard kernel. With the wrapper, we allow > > for non-suid graphics too. > > Just because fbcon is in devel kernel now and works doesn't mean we have to > trash our code. At least not now. We are still in early devel stage (which > is IMHO a shame) and we should be free to code our way. Yes, our consoles > have unmapped keys, but that's rather an implementation problem and shows > that our progress is slow. Again, the code is not getting trashed but moved to EvStack (unless a better implementation already exists in EvStack of course). > Let the user decide - if GGI is good, GGI will be adopted and fbcon > forgetten. Standard kernel != good. Not necessarily. (For example, I > never liked /dev/vcsa?? "GGI" is the developer community. What goes or does not go into the kernel is EvStack/KGI/KGI drivers, etc. We _cannot_ have the "all or nothing" attitude, because then we will likely get nothing |-<. Whereas if we get the KGI driver system into the kernel, we will have lots of people who may never have heard of GGI before become exposed to our work and the rest of our work will have a leg up at that point. > > I propose that the KGI wrapper complies to the Dali driver API; > > the drivers are already here and work. If we begin moving all of > > that to the EvStack API, it will be a nightmare. I propose > > we use the Dali API. The notable changes in the evstack one, > > notably about text management, are handled by fbcon itself > > anyway. > > AAARRGGG. Sorry... Do you say that the repository was closed for 3 month, Two months, actually. > development was reduced to a minimum, just to step backwards now to the > 0.0.9 API? Yes. Why on earth not? The changes in Degas API make no difference to the video drivers. > IIRC, there were good reasons to justify a major change in the > driver API. Adapting the drivers is quite some work, but doable. And once > again, I don't care about fbcon. Let me tell you what *will* happen if we were to insist that things stay as they are and that KGI consoles should replace fbcon. What will happen is that people will begin porting X, SVGALib and KGI drivers directly to fbcon. They will then have even LESS incentive to switch from fbcon, and in addition they will have to work within the chaos that is the existing driver/video "structure". We ***HAVE*** to care about and work with fbcon. > > Please everyone comment that > > My comments are harnish, and it was my intent actually. Over the last > month I've had the impression that some of you are too "soft" - libGGI > should run on the oldest and most braindamaged hardware; KGI must adapt to > standard kernel, because GGI should be in it by 2.3.X; GGI never stands a > chance against standard linux kernel; too much compromises... It seems like you want *NO* compromises, which is just as bad if not worse than too many compromises. > Bull. IMO GGI can survive as a patch to standard kernel. Survive, yes. Thrive? > If people start > using GGI for their apps, distributors will ship their CDs with the GGI > patch. Yeah, game makers are going to require that their customers patch and recompile their kernel to be able to play their game. Sure. I don't think so. Instead they will go for XAA and OpenGL and we will be left out in the cold, with a worse image because we had a chance to get into the kernel and we turned it down. I have not worked with GGI for three years to see that happen. > We needn't look at the kernel folks too much. We need to look at them more than we do now, frankly. That doesn't, of course, mean that we need to *emulate* them. However, being as isolated from the mainstream of Linux kernel development as we are now is not good for us. At the very least it costs us developers and bug fixers due to the enormously greater number of eyes that are exposed to the mainstream Linux kernel vs. our developer base. I'll remind you of one little side-benefit of having KGI drivers in the main kernel: people who see KGI in the main kernel and want to work on it are going to need to use our CVS tree, web pages and mailing lists, through which they will undoubtedly get more exposure to EvStack and LibGGI. Can't complain about that.... > They are not god or > something; No but they pretty much call the shots. It took me a while to accept this. The pressure we put on them backfired. Only now that we have *convinced* them of how we can integrate KGI smoothly and logically (in their eyes anyway) are they willing to listen. We have Alan Cox supporting us, and Linus probably will give it a shot if Alan is OK with it. > I think we all had our visions when we joined the GGI devel team, > and IMO we should work on making our dreams come true first. Precisely. And my primary dream when I joined GGI way back in fall '95 was non-suid accelerated Linux kernel graphic devices and drivers. My primary dream has a chance now of being fulfilled, and frankly there is no way in hell that anyone can talk me out of this. I should hope that they wouldn't want to try, but.... > And sometimes > we must say "NO" even if that is different from other peoples ideas / > implementations. All the driver code and the makefile system are GPLed. Anyone can do anything they like with them except remove people's names. You cannot say "NO" - that is the beauty of GPL. If what we are doing bothers you, feel free to snapshot KGI/Degas right now and maintain the current system yourself. But your drivers won't be interoperable. The only ones that have been ported are VGA and my Trio64V+ driver which doesn't work right yet. Needless to say I am not gonna put any more time into it, and what changes I had to make were a royal PITA. If you want to go through all that for every Dali driver you have my condolences. > Sometimes we have to make compromises, sometimes we are better off going > into contest. If we are good we have a good chance to win. Which I say that we do not. > Hard, emotionial words. But that's how I feel. I am sorry you feel that way. I do not share your feelings. I am still going to port KGI sans input devices and consoles to Linux/fbcon. I will be porting all the Dali KGI drivers sometime soon, so your Mystique driver will be working in the Linux kernel should you want to work on it. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sun Jun 28 16:04:16 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA28502; Sun, 28 Jun 1998 16:04:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA18594; Sun, 28 Jun 1998 15:51:30 -0700 Resent-Date: Sun, 28 Jun 1998 15:51:30 -0700 From: Uwe_Maurer@t-online.de Date: Mon, 29 Jun 1998 00:50:32 +0200 (MEST) To: ggi-develop@eskimo.com Subject: Re: ggiglut update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: 08142597465-0001@t-online.de Resent-Message-ID: <"-Ci4p2.0.LY4.nZibr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3134 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sat, 27 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > > Hi all, hi Uwe ! > > I did some tests to see, why some programs had problems with events, > especially the GLUT demos from Uwe's latest Mesa patch. > > The problem was that I had an outdated events.h installed, so that was > my fault. A few other things struck me, so I fixed them - here is the patch. > Thank you Andy. My events.h was outdated, too. Uwe From ggi-develop-request@eskimo.com Sun Jun 28 16:48:50 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA28552; Sun, 28 Jun 1998 16:48:46 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id QAA19320; Sun, 28 Jun 1998 16:33:26 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 16:33:26 -0700 (PDT) Date: Sun, 28 Jun 1998 16:25:51 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"IFWo42.0.lj4.1Bjbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3136 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Geert Uytterhoeven wrote: > On Sat, 27 Jun 1998, Jon M. Taylor wrote: > > On Sat, 27 Jun 1998, Emmanuel Marty wrote: > > > Right now, all you need is to write a replacement 'kernel driver' part for > > > the KGI module. What it will basically do is, provide the services to > > > the driver that KGI did usually (pci lookup, etc.); at init, register the > > > driver > > > as a framebuffer device to fbmem (look at other fb drivers), then when > > > fbcon sends command to that fbmem device, just translate mode > > > requests etc and call the appropriate KGI commands. > > > > This works fine for the driver modules, but to insert them I still > > have to have the KGI framework (kgi.c, etc) compiled into the kernel at > > boot time. > > Can't kgi be a loadable kernel module, too? I had it wrong, the KGI, as opposed to the KGI *driver framework*, will _not_ need to be ported. The whole thing will just be a fancy backend to a standard fbcon driver. Modules should work fine. However, there is just one feature we would really like added to the fbcon interface: a "gateway" ioctl to allow direct access to the underlying KGI accel subsystem. This is only one more ioctl, so no bloat, and anything in userspace that wants to talk to KGI directly can shoot messages through the ioctl to the drivers. Removes the need to mmap the accel registers in fbcon, although I guess you guys can keep that around as an option if you or other people still want it. But the gateway ioctl ideas is small, simple, infinitely flexible and *safe*. LibGGI's KGI target can use this gateway ioctl to wrap its existing ioctls in, or we can merge the KGI target with the fbcon target. Is their any way we could persuade Alan to join this discussion? I'd feel a lot better about some of the design decisions in this new system if they were looked over by Alan before they get too far of the ground. If Linus could join us that would be fantastic. > > > And we won't dump CVS - simply, when drivers are stable and tested, > > > on a regular basis, we'll send a diff to Geert or Alan; the main kernel > > > will be lagged behind a few releases, but that's life. > > Yep. Or send it yourself to linux-patches. > > The tree at vger.rutgers.edu is under CVS too. But if you want something merged > with Linus, you have to send a patch (or wait until DaveM does that for you :-) What we really need is one gigantic distributed CVS tree with interlocking and overlapping revision control and accounting that every Linux kernel developer everywhere uses. There would be permissions levels attached to the accounts, with dabblers/bugfixers at the bottom, regular developers above them (like me), subsystem managers above them (like Jason for EvStack), and above them you'd have several major area managers like Alan Cox, Ted Ts'o, David Miller - people Linus has know a while and trusts the judgement of. Above them would be Linus. Changes would be developed at or near the bottom with organization and guidance from above. Changes would have to be approved by the next level up to be accepted, and when they percolate all the way up and Linus accepts them they would be in the standard kernel distribution. > > What happens when Joe Linux User sees a problem in one of the > > drivers and sends a patch to Linus instead of us? > > Isn't this similarly to the commercial OSS sound drivers? AFAIK (I don't have > sound on Intel machines) they just provide you with loadable kernel modules. > (KGI drivers would be even better, because you have the source :-) > So I suppose people complain to the wrong people about OSS sound drivers, too? Yes, but they can't get at the source to try to fix those problems, and thus they can't be sending patches to Linus incorrectly. > Assuming people who actually write patches are smarter than Joe User who just > insmods binaries made by others, I think it won't be that bad. At least the proper information needs to go into the file headers, then. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sun Jun 28 17:19:18 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA28567; Sun, 28 Jun 1998 17:19:16 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA25321; Sun, 28 Jun 1998 17:22:29 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 17:22:29 -0700 (PDT) Date: Sun, 28 Jun 1998 17:15:03 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge progress In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"5WBeY3.0.TB6.3vjbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3138 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Geert Uytterhoeven wrote: > On Sun, 28 Jun 1998, Jon M. Taylor wrote: > > I spent most of today laying out the groundwork and I finally have > > a compiling & linking system. The frame buffer devices configuration has > > one new option, 'KGI driver support', which tells KGI to 'make vga' and > > bypass the config scripts which are not yet connected to the main linux > > config system. kernel/i386.c is Andrew's fbcon-KGI wrapper with more > ^^^^^^ > Aarghl! I want to get my Vision968 working in my CHRP box! As you noted below, this is an artifact and will go away. I dunno if there would be any other hangups with running the Vision968 driver on a CHRP box - all the PCI stuff should work the same, I assume. > > tweaking by me. The whole thing compiles and links properly with the > > kernel, but crashes sometime after boot and there's no display yet. I > > can't test it as a module because I get the infamous black-on-black > > characters problem when I enable fbcon |-<. > > Replace ioremap() in vgafb.c by bus_to_virt(). Or use the vger tree :-) Hopefully vgafb will be unneeded soon due to a working KGI VGA driver. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sun Jun 28 17:22:36 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA28574; Sun, 28 Jun 1998 17:22:34 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA24534; Sun, 28 Jun 1998 17:18:24 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 17:18:24 -0700 (PDT) Date: Sun, 28 Jun 1998 17:10:58 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: Future of GGI project In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"p4Gu23.0.D_5.Erjbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3137 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, KC5TJA wrote: > So while you GGI/KGI developers are happily working away on YOUR working > systems, there are probably a huge number of kernels where GGI simply and > plainly does not work. Period. :) > > And no, I'm not blaming you in any way. I've dealt with tons of > programming problems where program A would work on machine B, but not on > machine C, despite having equal configurations in every software respect. KGI was mostly used as a device driver development and testing framework for quite a while. > > problem attracting outside development assistance because we keep to > > ourselves so much. We are all good coders (and some of us (not me) are > > brilliant designers), or the project wouldn't be where it is today. But > > True, but things take time. Perhaps three years isn't "the time" for GGI. > Do not be so hasty. I'd rather switch to GGI three years from NOW if it > worked, rather than have GGI now, and not able to use it, and it being > unheard of in three years time because of all the problems it's having > now. The parts with problems are going away. You should be able to switch to GGI (LibGGI + KGI drivers through fbcon) in the not too distant future. > > we *need* to break out of our niche and get out ideas accepted by the open > > source community at large, and to do that effectively we need to > > streamline our organization, clear up our message(s) and refocus > > ourselves. > > Try submitting your stuff to Freshmeat or Slashdot. I've yet to see any > GGI-related announcements there. http://slashdot.org/. Freshmeat has a > link on Slashdot's web page. I am aware of Slashdot, I keep it open continuously when I am at work and hit refresh every ten minutes or so |->. As far as announcing releases, when I get this KGI-fbcon bridge going and LibGGI's working well with it, you bet you ass I'll announce it on Slashdot, Freshmeat, linux-kernel, comp.os.linux.announce, and everywhere else I can think of! Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sun Jun 28 17:30:40 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA28585; Sun, 28 Jun 1998 17:30:39 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA27006; Sun, 28 Jun 1998 17:33:18 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 17:33:18 -0700 (PDT) Date: Sun, 28 Jun 1998 17:25:50 -0700 (PDT) From: "Jon M. Taylor" To: Jason McMullan cc: ggi-develop@eskimo.com Subject: Re: job offers In-Reply-To: <6n68qd$3l6$2@butter.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ZK8cW2.0.qb6.B3kbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3139 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com First, I noticed that this post is crossposted through a gatewayed usenet newgroup, lists.linux.ggi. PLEASE do not do this. All we need is to start getting spam or mail loops on this list. On 28 Jun 1998, Jason McMullan wrote: > Jon M. Taylor wrote with confidence: > > Take away all messaging stuff (EvStack) and the drivers > > themselves, and what is left of KGI isn't too much. But if we are going > > to split the KGI video driver layer and its associated drivers away from > > any console stuff and EvStack, this should be formally decided upon and > > plans made to modify the repository appropriately (i.e. remove KGI > > altogether o it is relly going into the kernel proper). Also, IMHO this > > change would further justify a complete separation of EvStack and GGI into > > separate projects. > > EvStack is ready for a split. All KGI access goes through the `kgiscroll' > module. I'll be writing a fbscroll module for my PowerPC Mac work (which > I plan to start as soon as the ExWife moves all her stuff out). Anyhow, > separating KGI from EvStack should be easy. Making sure you can rmmod(1) > inserted KGI modules under fbcon, on the other hand.... ;^) The "KGI modules" will really just be fbcon modules, and module insertion and removal is already working there. > > What about acceleration, what last I looked was not supported > > generally by fbcon? AFAIK they have a blit ioctl but that's it. This > > issue has always been at the heart of the disagreements between GGI and > > Linus. The current state of accel support in the KGI drivers is largely > > confined to 2-D stuff that could easily be used by fbcon as it stands now, > > though. > > According to Geert, fbcon acceleration is just a mmap on accel registers - > it required setuid-root (blech - which is why we started GGI in the first place!) I am hoping to convince the powers that be to go for Andy's gateway ioctl idea instead. It will allow access to all KGI driver functionality but not require suid root. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Sun Jun 28 18:34:01 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA28626; Sun, 28 Jun 1998 18:33:58 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id SAA03688; Sun, 28 Jun 1998 18:23:25 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 18:23:25 -0700 (PDT) Sender: injector@clubneon.dyn.ml.org Message-ID: <3596EA84.360BE984@stu.ac.cc.md.us> Date: Sun, 28 Jun 1998 21:14:44 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: No exec permissions on anoncvs mirror. Content-Type: multipart/mixed; boundary="------------929F960C00D5252DBE143867" Resent-Message-ID: <"kkz_1.0.Sv.Aokbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3140 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This is a multi-part message in MIME format. --------------929F960C00D5252DBE143867 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm not writing to complain. Just to submit my little fix for anyone being bugged by this. Do with this as you will. There is probally a better way to do it, but hey it works. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". --------------929F960C00D5252DBE143867 Content-Type: application/x-sh; name="setperm.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="setperm.sh" #!/bin/sh # This script recursively searches for other scripts that need # the execution bit set and sets it. Uses the magic number '#!' # at the begining of the first line to decide if the file should # get the execution bit. # This script probally will need to be run as `sh ./setperm.sh` # cause if your scripts don't have the execution bit this one # won't either. :) for i in `find -type f` do if `head -n1 $i | grep -q \b\#\!` then chmod -v +x $i fi done --------------929F960C00D5252DBE143867-- From ggi-develop-request@eskimo.com Sun Jun 28 19:12:29 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA28643; Sun, 28 Jun 1998 19:12:27 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA11945; Sun, 28 Jun 1998 19:13:04 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 19:13:04 -0700 (PDT) Sender: injector@clubneon.dyn.ml.org Message-ID: <3596F62C.E5EC3EDE@stu.ac.cc.md.us> Date: Sun, 28 Jun 1998 22:04:29 -0400 From: Chris Meadors Organization: Club Neon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i486) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: No exec permissions on anoncvs mirror. References: <3596EA84.360BE984@stu.ac.cc.md.us> Content-Type: multipart/mixed; boundary="------------5C54B1267862E39D871A4C3F" Resent-Message-ID: <"McuS83.0.Xw2.jWlbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3141 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This is a multi-part message in MIME format. --------------5C54B1267862E39D871A4C3F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I need to try that again. Needed to type 'ZZ' on another terminal to be able to send the one that works. Boy is my face red. :P Again, Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo". The second penguin said, "I might be". --------------5C54B1267862E39D871A4C3F Content-Type: application/x-sh; name="setperm.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="setperm.sh" #!/bin/sh # This script recursively searches for other scripts that need # the execution bit set and sets it. Uses the magic number '#!' # anywhere in the first line to decide if the file should get # the execution bit. # This script probally will need to be run as `sh ./setperm.sh` # cause if your scripts don't have the execution bit this one # won't either. :) for i in `find -type f` do if `head -n1 $i | grep -q '#!'` then chmod -v +x $i fi done --------------5C54B1267862E39D871A4C3F-- From ggi-develop-request@eskimo.com Sun Jun 28 19:13:15 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA28648; Sun, 28 Jun 1998 19:13:14 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA12297; Sun, 28 Jun 1998 19:16:07 -0700 (PDT) Resent-Date: Sun, 28 Jun 1998 19:16:07 -0700 (PDT) From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: tutorial for ggi To: ggi-develop@eskimo.com Date: Sun, 28 Jun 1998 20:45:28 +0200 (MET DST) In-Reply-To: from "Jan Kneschke" at Jun 28, 98 05:10:59 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"CUdNc2.0.-_2.aZlbr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3143 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > the first step is easy: > > ggiInit(); > ggiOpen(); > setGraphMode(); > ggiPuts("HELLO WORLD"); > > (wait) > > setTextMode(); This is not needed. ggiClose is supposed to restore the state of the target. You cannot know the mode it had before, anyway. > i think the next step will be getBox/putBox example. what about "hello > world" moving over the display transformed over an sinus ? Hmm - BTW - there already is a section on that in the LibGGI docs, so you might want to enhance this one. And check demo.c which is our primary commented example. > after that some clipping? BTW: is there a definition in libggi for inner and > outer clipping ?? virge can do it. You mean "clip inside rect" and "clip outside rect" ? No. But I suppose LibGGI2D might want to handle that. Though outside- clipping isn't a too common operation anyway ... > but what after this basic steps ?? can you give me some advices ?? Read the existing examples. demo.c should be well commented. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 28 19:18:20 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA28653; Sun, 28 Jun 1998 19:18:19 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA27179; Sun, 28 Jun 1998 19:11:08 -0700 Resent-Date: Sun, 28 Jun 1998 19:11:08 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: fbcon-KGI bridge progress To: ggi-develop@eskimo.com Date: Sun, 28 Jun 1998 18:45:13 +0200 (MET DST) In-Reply-To: from "Jon M. Taylor" at Jun 28, 98 00:47:46 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"e_rEZ.0.Ue6.xUlbr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3142 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > kernel/i386.c is Andrew's fbcon-KGI wrapper with more tweaking by me. We might want to call that fbcon_i386.c to allow to build for both worlds easily. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Sun Jun 28 22:36:06 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA28777; Sun, 28 Jun 1998 22:36:03 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA02773; Sun, 28 Jun 1998 22:29:58 -0700 Resent-Date: Sun, 28 Jun 1998 22:29:58 -0700 Message-ID: <19980629002821.50254@fries.net> Date: Mon, 29 Jun 1998 00:28:21 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: CVS stuff References: <199806170845.KAA20789@cip8.e-technik.uni-erlangen.de> <199806220824.KAA24962@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199806220824.KAA24962@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Mon, Jun 22, 1998 at 10:24:37AM +0200 Resent-Message-ID: <"RW4cg3.0.7h.LPobr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3144 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, Jun 22, 1998 at 10:24:37AM +0200, Hartmut Niemann wrote: > It looks like the ps, tex, dvi and html directories are still present > somewhere in the repository. It's not mission critical, but if someone > who knows (Todd?) can have a look how to remove them entirely? If you're wanting to preserve the history of the archive and not damage the ability to pull the 'old stuff' out at a future point in time I suggest never removing them. If, however, you never wanted them in in the future, I guess you can remove the files and subdirs, .. but if people will simply update their sources with: cvs update -PAd .. perhaps with a -z9 for compression for slow links... -P prune empty subdirs from the update -d create any new subdirs not already in the local checked out source tree -A update exactly to the repository, aka remove any sticky tags created by doing something such as 'cvs update -r 1.1 filename' removing files/subdirs from the repository if they never were intended to be there .. is somewhat ok .. the REAL nightmare is when someone manipulates the repository manually to move / remove files that were supposed to be there in the past .. which destroys the historical usefulness of the repository. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Sun Jun 28 22:45:28 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA28794; Sun, 28 Jun 1998 22:45:27 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA04259; Sun, 28 Jun 1998 22:39:38 -0700 Resent-Date: Sun, 28 Jun 1998 22:39:38 -0700 Date: Sun, 28 Jun 1998 22:31:44 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: Future of GGI project In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"JfTFA.0.R21.PYobr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3146 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Jon M. Taylor wrote: > KGI was mostly used as a device driver development and testing > framework for quite a while. True, and I have no doubts that it does work. GGI's text modes, after all, do seem to work well when I make a KGI-enabled kernel. What does not seem to work is that I routinely get "Cannot open /dev/graphics -- device in use" errors all over the place. > The parts with problems are going away. You should be able to > switch to GGI (LibGGI + KGI drivers through fbcon) in the not too distant > future. Believe me -- I can't tell you how much I'm looking forward to that day... :) > I am aware of Slashdot, I keep it open continuously when I am at > work and hit refresh every ten minutes or so |->. As far as announcing I'm not quite that bad... :-) > releases, when I get this KGI-fbcon bridge going and LibGGI's working well > with it, you bet you ass I'll announce it on Slashdot, Freshmeat, > linux-kernel, comp.os.linux.announce, and everywhere else I can think of! This sounds good... ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Sun Jun 28 22:46:13 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA28801; Sun, 28 Jun 1998 22:46:11 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA03924; Sun, 28 Jun 1998 22:36:12 -0700 Resent-Date: Sun, 28 Jun 1998 22:36:12 -0700 Message-ID: <19980629003441.26947@fries.net> Date: Mon, 29 Jun 1998 00:34:41 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: Re: CVS mirrors and guest access. References: <199806222217.AAA06255@zafir.e.kth.se> <199806222241.AAA08752@orb.suntech.fr> <19980622193735.17638@fries.net> <35917469.E0EBB205@canit.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <35917469.E0EBB205@canit.se>; from Kenneth Johansson on Wed, Jun 24, 1998 at 11:49:30PM +0200 Resent-Message-ID: <"cfokl.0.Az.BVobr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3145 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Wed, Jun 24, 1998 at 11:49:30PM +0200, Kenneth Johansson wrote: > hmm how is this mirroring done? I'am updating from you now but I got the > postscrip files and they was deleted on the main repository quite a while ago. > If the cvs mirror is so much behinde it is going to make some confusion. I mirror once every 6 hours (and sometimes more often, if I notice in my email that the mirror has failed for whatever reason). -- Todd Fries .. toddf@acm.org P.S. Here's my mirror file for everyone's pleasure: package=ggi-stableanoncvs site=degas.ggi-project.org remote_password=fopy0p remote_user=friesftp local_dir=/home/cvs/cvs remote_dir=/cvs exclude_patt=(CVSROOT/ChangeLog.*|CVSROOT/passwd.*|CVSROOT/readers.*|CVSROOT/writers.*|CVSROOT/history.*|\.#.*) timeout=1200 #do_deletes=true package=ggi-develanoncvs site=degas.ggi-project.org remote_password=fopy0p remote_user=friesftp local_dir=/home/cvs/cvsdevel remote_dir=/cvsdevel exclude_patt=(CVSROOT/ChangeLog.*|CVSROOT/passwd.*|CVSROOT/readers.*|CVSROOT/writers.*|CVSROOT/history.*|\.#.*) timeout=1200 #do_deletes=true package=ggi site=ftp.ggi-project.org remote_dir=/pub/ggi retry_call=yes local_dir=/home/ftp/mirrors/ftp.ggi-project.org/ggi do_deletes=1 max_delete_files=99% P.P.S. Here's the crontab entry, this runs at US/Central timezone: 0 0,6,12,18 * * * /usr/local/bin/mirror ~todd/etc/mirrors From ggi-develop-request@eskimo.com Sun Jun 28 23:15:46 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA28847; Sun, 28 Jun 1998 23:15:42 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA10048; Sun, 28 Jun 1998 23:10:59 -0700 Resent-Date: Sun, 28 Jun 1998 23:10:59 -0700 Message-ID: <19980629010927.36608@fries.net> Date: Mon, 29 Jun 1998 01:09:27 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: ping (anoncvs) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e Resent-Message-ID: <"W4zMB.0.uS2.p_obr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3147 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I've seen that since I have made my anoncvs server available I have been accessed by 54 hosts a total of 197 times .. and I'm curious how the experiences have been? As a further note, if any problems crop up which indicate something's amiss, like maybe the repository is messed up (shouldn't happen, but you never know) send me mail direct as I won't always have time to stay 100% uptodate with this mailing list :-) Thanks, -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Sun Jun 28 23:26:59 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA28852; Sun, 28 Jun 1998 23:26:57 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA10728; Sun, 28 Jun 1998 23:16:20 -0700 Resent-Date: Sun, 28 Jun 1998 23:16:20 -0700 Date: Sun, 28 Jun 1998 23:08:27 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: GGI Compilation Bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"d8-2p1.0.Rd2.q4pbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3148 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I CVS'd the latest "stable" GGI tree, and switched to the libggi directory. I then did a make config, and I found that the "configure" script didn't have execute permissions, which it apparently needed. Is this something that CVS stripped? Then I did a make after I repaired that small anomylie(sp? It's late... :) ). And to my suprise, I find that is missing. OOPS! Can someone send me that file so that I may build libggi? Thanks a bunch. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Mon Jun 29 00:38:47 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA28947; Mon, 29 Jun 1998 00:38:44 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id AAA18056; Mon, 29 Jun 1998 00:26:41 -0700 Resent-Date: Mon, 29 Jun 1998 00:26:41 -0700 Sender: torgeir@eskimo.com Message-ID: <35975CC4.4BD81502@vertech.no> Date: Mon, 29 Jun 1998 09:22:12 +0000 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: Linux GGI Subject: [Fwd: uniform input device packets?] Content-Type: multipart/mixed; boundary="------------95A013206393ABD7610ADFB1" Resent-Message-ID: <"QaeHA.0.zP4.m6qbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3149 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com This is a multi-part message in MIME format. --------------95A013206393ABD7610ADFB1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Torgeir Veimo, Vertech AS, email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 --------------95A013206393ABD7610ADFB1 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Delivered-To: vertech-torgeir.veimo@vertech.no Received: (qmail 14963 invoked from network); 29 Jun 1998 09:24:44 -0000 Received: from sabre-wulf.nvg.ntnu.no (129.241.210.67) by 195.204.179.10 with SMTP; 29 Jun 1998 09:24:44 -0000 Received: from vger.rutgers.edu ([128.6.190.2] EHLO vger.rutgers.edu ident: root [port 63318]) by sabre-wulf.nvg.ntnu.no with ESMTP id <49182-25466>; Mon, 29 Jun 1998 09:14:39 +0200 Received: by vger.rutgers.edu id <970790-3822>; Mon, 29 Jun 1998 02:35:28 -0400 Received: from jumpy.systemy.it ([194.79.194.206]:6827 "EHLO jumpy.systemy.it" ident: "root") by vger.rutgers.edu with ESMTP id <970843-3822>; Mon, 29 Jun 1998 02:33:44 -0400 Received: from morgana.systemy.it (morgana [192.168.16.1]) by jumpy.systemy.it (8.8.7/8.8.7) with ESMTP id JAA20735 for ; Mon, 29 Jun 1998 09:10:21 +0200 Received: (from rubini@localhost) by morgana.systemy.it (8.8.4/8.8.4) id JAA32145; Mon, 29 Jun 1998 09:10:17 +0200 Message-ID: <19980629091016.31954@morgana.systemy.it> Date: Mon, 29 Jun 1998 09:10:16 +0200 From: Alessandro Rubini To: linux-kernel@vger.rutgers.edu Subject: Re: uniform input device packets? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Hello All. I just followed the discussion about input packets that happened in the last few days. Most of the discussion mimicks problems that I already dealt with, although it never got to the kernel proper. Those of you inerested in the question could check the kmouse module (on tsx-11.mit.edu and ftp.systemy.it/pub/develop). Kmouse is designed to be a gpm replacement which creates three virtual devices, local to each virtual console. They return the same data in different formats, so apps can choose what to use. The formats are: - msc packets, for programs which want to decode mouse events by themselves (like X and dosemu). - gpm packets, to provide a smooth transition for gpm clients (like "mc", "mev" (used to feed emacs) and others). - kmouse packets, a new format that tries to deal with multi-dimension events in an extensible and easily-decoded way. Sorry for advertising, but I hope this can save some hacker's time... /alessandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu --------------95A013206393ABD7610ADFB1-- From ggi-develop-request@eskimo.com Mon Jun 29 01:07:18 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA29008; Mon, 29 Jun 1998 01:07:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA24215; Mon, 29 Jun 1998 01:00:07 -0700 Resent-Date: Mon, 29 Jun 1998 01:00:07 -0700 From: Hartmut Niemann Message-Id: <199806290759.JAA10533@cip8.e-technik.uni-erlangen.de> Subject: Re: tutorial for ggi To: ggi-develop@eskimo.com Date: Mon, 29 Jun 1998 09:59:59 +0200 (MESZ) In-Reply-To: from "Jan Kneschke" at Jun 28, 98 05:10:59 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"xC86d2.0.Dw5.7cqbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3150 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > 1. since i don't have the new drivers-guide i can't rewrite the new s3-vision > driver (hint, hint) > 2. the kiel-week is nearly finish, just a big firework will come up today > evening. (kiel-week: biggest sailing event in the world/biggest party in > our region => many headaches) > 3. i passed the first part of my exams Congratulations! > > and so i have plenty of time and just want to hack something. > > as someone said, we have to attract outside developers for ggi. i just want > to start a tutorial the discribes the steps for writing a ggi-program. on > the one hand i will do this for diving into libggi, on the other libggi will > become easier to understand for all the newbies that will come along sometime. > Peter Amstutz started one, AFAIR, and was basically waiting for the API do be finally defined (which will be done before the first of August freeze, I hope.) At least this is what he said. Hartmut -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 29 01:18:06 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA29017; Mon, 29 Jun 1998 01:18:04 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA19951; Mon, 29 Jun 1998 01:06:37 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 01:06:37 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3597495C.B383DAC6@e.kth.se> Date: Mon, 29 Jun 1998 09:59:24 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Future of GGI project References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ZZ4PT3.0.dt4.Biqbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3151 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com KC5TJA wrote: > > On Sun, 28 Jun 1998, Marcus Sundberg wrote: > > > What makes you think that the above code is specific to the > > KGI-target? > > Setting the visual to graphics mode, doing your thing, then setting it > back to text mode before releasing it. That's pretty PC hardware > specific, I think. Oh, yes, I kind of ignored the ggiSetTextMode() as I knew it shouldn't be there. ;) When programming with libggi ggiSetTextMode() ggiClose() will be the same as just ggiClose() as the HW is always reset to it's previous state upon exit. > And yes, GGI developers DO need to know about targets. Otherwise, how > would you be able to open a printer visual? Or an off-screen bitmap? > > :-) You're right about that ofcourse. But none of the applications I've ported to libggi knows about targets, so you actually don't _need_ to know about them to write libggi apps. //Marcus From ggi-develop-request@eskimo.com Mon Jun 29 01:53:36 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA29031; Mon, 29 Jun 1998 01:53:34 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id BAA26535; Mon, 29 Jun 1998 01:20:32 -0700 Resent-Date: Mon, 29 Jun 1998 01:20:32 -0700 Sender: core@orb.suntech.fr Message-ID: <35974E48.9C38CB79@suntech.fr> Date: Mon, 29 Jun 1998 08:20:24 +0000 From: Emmanuel Marty Reply-To: core@suntech.fr Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Fwd: Win98 source code References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"SDTNG3.0.QU6.Fvqbr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3152 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Linux has a serious competitor now ... > Windows '98 source code. > /* > TOP SECRET Microsoft(c) > Code Project: Chicago(tm) > Projected release-date: Summer 1994 */ > > #include "win31.h" > #include "win95.h" > #include "evenmore.h" > #include "oldstuff.h" > #include "billrulz.h" > #define INSTALL = HARD > > char make_prog_look_big[1600000]; > > void main() > { > while(!CRASHED) > { > display_copyright_message(); > display_bill_rules_message(); > do_nothing_loop(); > > if (first_time_installation) > { > make_50_megabyte_swapfile(); > do_nothing_loop(); > totally_screw_up_HPFS_file_system(); > search_and_destroy_the_rest_of_OS/2(); > hang_system(); > } > > write_something(anything); > display_copyright_message(); > do_nothing_loop(); > do_some_stuff(); > if (still_not_crashed) > { > display_copyright_message(); > do_nothing_loop(); > basically_run_windows_3.1(); > do_nothing_loop(); > do_nothing_loop(); > } > } > if (detect_cache()) > disable_cache(); > if (fast_cpu()) > { > set_wait_states(lots); > set_mouse(speed, very_slow); > set_mouse(action, jumpy); > set_mouse(reaction, sometimes); > } > > /* printf("Welcome to Windows 3.11"); */ > /* printf("Welcome to Windows 95"); */ > printf("Welcome to Windows 98"); > if (system_ok()) > crash(to_dos_prompt); > else > system_memory = open("a:\swp0001.swp", O_CREATE); > while(something) > { > sleep(5); > get_user_input(); > sleep(5); > act_on_user_input(); > sleep(5); > } > > create_general_protection_fault(); > } From ggi-develop-request@eskimo.com Mon Jun 29 02:35:18 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA29052; Mon, 29 Jun 1998 02:35:15 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id CAA00322; Mon, 29 Jun 1998 02:14:05 -0700 Resent-Date: Mon, 29 Jun 1998 02:14:05 -0700 From: Steffen Seeger Message-Id: <199806290913.LAA28145@legrelle.physik.tu-chemnitz.de> Subject: Re: [Fwd: uniform input device packets?] In-Reply-To: <35975CC4.4BD81502@vertech.no> from Torgeir Veimo at "Jun 29, 98 09:22:12 am" To: ggi-develop@eskimo.com Date: Mon, 29 Jun 1998 11:13:36 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ESiYN2.0.v4.Thrbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3153 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > -- > Torgeir Veimo, Vertech AS, > > email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 -- Start of included mail From: Alessandro Rubini > Return-path: > Delivered-To: vertech-torgeir.veimo@vertech.no > Date: Mon, 29 Jun 1998 09:10:16 +0200 > To: linux-kernel@vger.rutgers.edu > Subject: Re: uniform input device packets? > X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu > Sender: owner-linux-kernel@vger.rutgers.edu > Precedence: bulk > X-Loop: majordomo@vger.rutgers.edu > > Hello All. I just followed the discussion about input packets that > happened in the last few days. > > Most of the discussion mimicks problems that I already dealt with, > although it never got to the kernel proper. > > Those of you inerested in the question could check the kmouse module > (on tsx-11.mit.edu and ftp.systemy.it/pub/develop). > > Kmouse is designed to be a gpm replacement which creates three virtual > devices, local to each virtual console. They return the same data in > different formats, so apps can choose what to use. The formats are: > > - msc packets, for programs which want to decode mouse events by themselves > (like X and dosemu). > - gpm packets, to provide a smooth transition for gpm clients (like "mc", > "mev" (used to feed emacs) and others). > - kmouse packets, a new format that tries to deal with multi-dimension > events in an extensible and easily-decoded way. > > Sorry for advertising, but I hope this can save some hacker's time... > > /alessandro > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu -- End of included mail. Did you give them a pointer to KGI and the XInput, Xkbd extensions? Might save some time to re-invent the wheel... (It still might have to be re-implemented, but that's different. Steffen ----------------- e-mail: seeger@physik.tu-chemnitz.de ----------------- From ggi-develop-request@eskimo.com Mon Jun 29 03:18:28 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA29073; Mon, 29 Jun 1998 03:18:25 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id CAA03855; Mon, 29 Jun 1998 02:52:42 -0700 Resent-Date: Mon, 29 Jun 1998 02:52:42 -0700 Date: Mon, 29 Jun 1998 02:52:30 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: fbcon-KGI progress Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"WbXZb1.0.2y.fFsbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3154 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Thanks to Geert's fixes, I now have Dali's Trio64V+ driver inserting as an fbdev module, and 'con2fbmap 0 1' gives me nice 640x400x32 graphical consoles. Scrollback works. Display is rotated on VC switches. I tried LibGGI/Degas's fbdev target but the setsid() call dies. And I cannot find a precomplied XF86_fbdev anywhere.... I cannot seem to be able to compile the driver into the kernel, though - if VGA console is enabled none of the other compiled-in drivers show up in /proc/fb, and if VGA is not selected the system boots up with no display. I think I will wait for the console initialization questions to be resolved in linux-kernel before I try this again. Damn, I want to see that peguin logo on bootup |->. Sorry no snapshot tonight, its very late and the system only works with the Trio64V+ right now anyway. More tomorrow.... Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Mon Jun 29 04:31:48 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA29113; Mon, 29 Jun 1998 04:31:46 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA12904; Mon, 29 Jun 1998 04:11:56 -0700 Resent-Date: Mon, 29 Jun 1998 04:11:56 -0700 Date: Mon, 29 Jun 1998 13:11:44 +0200 (CEST) From: Geert Uytterhoeven To: GGI mailing list Subject: Re: fbcon-KGI bridge progress In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cxmTW.0.V93.xPtbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3156 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Erlend Hoel wrote: > On Sun, 28 Jun 1998, Jon M. Taylor wrote: > > I can't test it as a module because I get the infamous black-on-black > > characters problem when I enable fbcon |-<. > > FWIW (probably less than 0.02) I tried compiling a stock 2.1.107 kernel > with fbcon enabled, and got a black on black myself. Please aply the patches at http://www.cs.kuleuven.ac.be/~geert/bin/geert-2.1.107.diff.gz > This was with a standard as-is kernel downloaded from nic.funet.fi - so > what I'm getting at is that this might not have anything to do with your > hacks, this might well be how fbcon operates in its present state. The black-on-black problem was caused by a difference between Linus' tree and the vger tree. Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium From ggi-develop-request@eskimo.com Mon Jun 29 04:33:57 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA29118; Mon, 29 Jun 1998 04:33:55 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA13272; Mon, 29 Jun 1998 04:15:06 -0700 Resent-Date: Mon, 29 Jun 1998 04:15:06 -0700 Date: Mon, 29 Jun 1998 13:14:59 +0200 (CEST) From: Geert Uytterhoeven To: GGI mailing list Subject: Re: fbcon-KGI progress In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"HnqbP3.0.8F3.uStbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3157 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 29 Jun 1998, Jon M. Taylor wrote: > Thanks to Geert's fixes, I now have Dali's Trio64V+ driver > inserting as an fbdev module, and 'con2fbmap 0 1' gives me nice 640x400x32 > graphical consoles. Scrollback works. Display is rotated on VC switches. > I tried LibGGI/Degas's fbdev target but the setsid() call dies. And I > cannot find a precomplied XF86_fbdev anywhere.... > > I cannot seem to be able to compile the driver into the kernel, > though - if VGA console is enabled none of the other compiled-in drivers > show up in /proc/fb, and if VGA is not selected the system boots up with Did you add the init function of your Trio64V+ `frame buffer device' (:-) to drivers/char/fbmem.c? Other thing I can think of: the late initialization of the PCI subsystem. > no display. I think I will wait for the console initialization questions > to be resolved in linux-kernel before I try this again. Damn, I want to > see that peguin logo on bootup |->. Then hardcode the address for your graphics board, so it doesn't rely on the PCI subsystem :-) Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium From ggi-develop-request@eskimo.com Mon Jun 29 04:36:12 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA29126; Mon, 29 Jun 1998 04:36:11 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id EAA12431; Mon, 29 Jun 1998 04:08:47 -0700 Resent-Date: Mon, 29 Jun 1998 04:08:47 -0700 Date: Mon, 29 Jun 1998 13:08:43 +0200 (CEST) From: Geert Uytterhoeven To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"wI9gE.0.723.-Mtbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3155 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998, Jon M. Taylor wrote: > However, there is just one feature we would really like added to > the fbcon interface: a "gateway" ioctl to allow direct access to the > underlying KGI accel subsystem. This is only one more ioctl, so no bloat, > and anything in userspace that wants to talk to KGI directly can shoot > messages through the ioctl to the drivers. Removes the need to mmap the That's trivial. Frame buffer devices can have their own private ioctls. Ioctls not recognized by drivers/char/fbmem.c are simply passed to the corresponding frame buffer device. Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium From ggi-develop-request@eskimo.com Mon Jun 29 06:39:00 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA29185; Mon, 29 Jun 1998 06:38:58 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA03353; Mon, 29 Jun 1998 06:32:59 -0700 Resent-Date: Mon, 29 Jun 1998 06:32:59 -0700 From: Hartmut Niemann Message-Id: <199806291332.PAA27859@cip8.e-technik.uni-erlangen.de> Subject: propose a GT_AUTO To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Mon, 29 Jun 1998 15:32:42 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"3Nr8X2.0.Aq.AUvbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3158 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! I would like to introduce the constant GT_AUTO *now* into the GGI tree. The rationale is this: Currently the graphtype is an enum, and the GT_Xxx values are ints, as the coordinates are. Currently GGI_AUTO, which is basically the I-leave-it-to-you coordinate for screen width and height, is used as the I-leave-it-to-you graphtype also. This is bad for the idea we have discussed, to enhance the graphtype meaning to hold complete pixel-setup functionality. For this we most probably will need to change the graphtype to either a pointer to a struct, or a char pointer, or an int with a large and hardware-independent bit number, used as a bit field. If we introdce GT_AUTO (currently to be equal to GGI_AUTO==-1) now, we can smoothly transition to whatever graphtype we please, as the current graphtypes are #defined anyway. What do you think? So i'd like somebody to add a #define GT_AUTO GGI_AUTO below the GGI_AUTO definition before the July1st release. It is harmless, and it might make the documentation cleaner, and the transition to a new graphtype (which will surely come next month) painless. Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 29 07:33:57 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA29220; Mon, 29 Jun 1998 07:33:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA16517; Mon, 29 Jun 1998 07:31:16 -0700 Resent-Date: Mon, 29 Jun 1998 07:31:16 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806291431.QAA00731@sunserver1.rz.uni-duesseldorf.de> Subject: Re: propose a GT_AUTO In-Reply-To: <199806291332.PAA27859@cip8.e-technik.uni-erlangen.de> from Hartmut Niemann at "Jun 29, 98 03:32:42 pm" To: ggi-develop@eskimo.com Date: Mon, 29 Jun 1998 16:31:03 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"1-kmW3.0.y14.pKwbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3160 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > So i'd like somebody to add a > #define GT_AUTO GGI_AUTO > below the GGI_AUTO definition before the July1st release. It is harmless, > and it might make the documentation cleaner, and the transition to a new > graphtype (which will surely come next month) painless. Acknowledged as a "Bugfix" :-). Commit please and change docs accordingly. CU, Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 29 07:34:41 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA29225; Mon, 29 Jun 1998 07:34:39 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA16251; Mon, 29 Jun 1998 07:29:44 -0700 Resent-Date: Mon, 29 Jun 1998 07:29:44 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806291429.QAA00477@sunserver1.rz.uni-duesseldorf.de> Subject: Re: GGI Compilation Bug In-Reply-To: from KC5TJA at "Jun 28, 98 11:08:27 pm" To: ggi-develop@eskimo.com Date: Mon, 29 Jun 1998 16:29:24 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"whe9y1.0.mz3.OJwbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3159 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I CVS'd the latest "stable" GGI tree, and switched to the libggi > directory. > > I then did a make config, and I found that the "configure" script didn't > have execute permissions, which it apparently needed. Is this something > that CVS stripped? Yeah - there seems to have been some problem. don't know if it is resolved by now. The main devel repository is o.k. AFAICT. > Then I did a make after I repaired that small anomylie(sp? It's late... > :) ). And to my suprise, I find that is missing. OOPS! > > Can someone send me that file so that I may build libggi? Please switch to the devel tree which is being frozen right now, so it should be fairly safe to play with. The current "stable" tree does not have KGI/GGIcons in, so it doesn't install properly, if not installing LibGGI-only. It will be copied to the stable tree on the 1st of July. CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 29 07:38:02 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA29238; Mon, 29 Jun 1998 07:38:00 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA18040; Mon, 29 Jun 1998 07:36:11 -0700 Resent-Date: Mon, 29 Jun 1998 07:36:11 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806291435.QAA01335@sunserver1.rz.uni-duesseldorf.de> Subject: Re: fbcon-KGI bridge In-Reply-To: from Geert Uytterhoeven at "Jun 29, 98 01:08:43 pm" To: ggi-develop@eskimo.com Date: Mon, 29 Jun 1998 16:35:27 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-kZ0j1.0.dP4.QPwbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3161 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > However, there is just one feature we would really like added to > > the fbcon interface: a "gateway" ioctl to allow direct access to the > > underlying KGI accel subsystem. This is only one more ioctl, so no bloat, > > and anything in userspace that wants to talk to KGI directly can shoot > > messages through the ioctl to the drivers. Removes the need to mmap the > > That's trivial. Frame buffer devices can have their own private ioctls. > Ioctls not recognized by drivers/char/fbmem.c are simply passed to the > corresponding frame buffer device. So we just have to check for conflicts (do the fbmem-internal ioctls have some magic number or similar, so we can avoid conflicts for all future releases beforehand, too ?) and we are done ? Great ! This should make writing an accelerated version of the fbmem target a SMOP. It could just do something like open("/dev/fbmem");ioctl(fb,KGI_VERSION_CHECK,&rc); if (kgi_present(rc)) vis=ggiOpen("kgi:/dev/fbmem"); Or simply add the "generic-ioctl" driver to the list of driver modules. CU,Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 29 08:20:07 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA29269; Mon, 29 Jun 1998 08:20:06 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA03987; Mon, 29 Jun 1998 08:17:16 -0700 Resent-Date: Mon, 29 Jun 1998 08:17:16 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806291516.RAA06361@sunserver1.rz.uni-duesseldorf.de> Subject: Re: Future of GGI project In-Reply-To: from KC5TJA at "Jun 28, 98 10:31:44 pm" To: ggi-develop@eskimo.com Date: Mon, 29 Jun 1998 17:16:26 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FxfXd3.0.zz.v_wbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3162 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > True, and I have no doubts that it does work. GGI's text modes, after > all, do seem to work well when I make a KGI-enabled kernel. What does not > seem to work is that I routinely get "Cannot open /dev/graphics -- device > in use" errors all over the place. You might want to try starting the test apps from another console as the one you inserted the driver on. I am not sure, if this particular bug has been fixed in GGIcons - it used to be around in the Dali version for quite some time. CU,ANdy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Mon Jun 29 09:10:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA29316; Mon, 29 Jun 1998 09:10:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA22707; Mon, 29 Jun 1998 09:03:50 -0700 Resent-Date: Mon, 29 Jun 1998 09:03:50 -0700 Date: Mon, 29 Jun 1998 18:03:39 +0200 (CEST) From: Geert Uytterhoeven To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: <199806291435.QAA01335@sunserver1.rz.uni-duesseldorf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"lohoX2.0.EY5.Zhxbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3163 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 29 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > > > However, there is just one feature we would really like added to > > > the fbcon interface: a "gateway" ioctl to allow direct access to the > > > underlying KGI accel subsystem. This is only one more ioctl, so no bloat, > > > and anything in userspace that wants to talk to KGI directly can shoot > > > messages through the ioctl to the drivers. Removes the need to mmap the > > > > That's trivial. Frame buffer devices can have their own private ioctls. > > Ioctls not recognized by drivers/char/fbmem.c are simply passed to the > > corresponding frame buffer device. > > So we just have to check for conflicts (do the fbmem-internal ioctls have > some magic number or similar, so we can avoid conflicts for all future > releases beforehand, too ?) and we are done ? Great ! The current ioctls are: #define FBIOGET_VSCREENINFO 0x4600 #define FBIOPUT_VSCREENINFO 0x4601 #define FBIOGET_FSCREENINFO 0x4602 #define FBIOGETCMAP 0x4604 #define FBIOPUTCMAP 0x4605 #define FBIOPAN_DISPLAY 0x4606 /* 0x4607-0x460B are defined below */ /* #define FBIOGET_MONITORSPEC 0x460C */ /* #define FBIOPUT_MONITORSPEC 0x460D */ /* #define FBIOSWITCH_MONIBIT 0x460E */ #define FBIOGET_CON2FBMAP 0x460F #define FBIOPUT_CON2FBMAP 0x4610 These do not comply (yet) to the `standard ioctl scheme'. BTW, Jakub Jelinek is working on merging in the current SBUS frame buffer ioctls, while writing frame buffer devices for SPARC. > This should make writing an accelerated version of the fbmem target a > SMOP. > > It could just do something like > > open("/dev/fbmem");ioctl(fb,KGI_VERSION_CHECK,&rc); ^^^^^^^^^^ Beep... /dev/fb%d BTW, devices.t{ex,xt} is obsolete. The patch is with Peter Anvin since a few months. Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium From ggi-develop-request@eskimo.com Mon Jun 29 09:18:51 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA29321; Mon, 29 Jun 1998 09:18:50 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA29186; Mon, 29 Jun 1998 09:18:52 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 09:18:52 -0700 (PDT) Date: Mon, 29 Jun 1998 09:03:27 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: GGI Compilation Bug In-Reply-To: <199806291429.QAA00477@sunserver1.rz.uni-duesseldorf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ZvsCW3.0.t77.evxbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3164 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > The current "stable" tree does not have KGI/GGIcons in, so it doesn't > install properly, if not installing LibGGI-only. > > It will be copied to the stable tree on the 1st of July. Problem: all I want is libGGI. I was told by a number of people to CVS the tree, switch into lib/libggi, make config, and make. Unfortunately, out of the box, it does not work. I had to finesse it a bit. Specifically, I had to cp -R ../../include/* ./include in the libGGI directory before ANYTHING would compile. And then there's those execute permissions... :) After I got everything compiled, NOW it's telling me that libggi.so.1 cannot be opened, or it cannot open a file -- the error message in ambiguous. I have yet to figure out why this is. What would I do to debug this? I tried everything *I* know how, perhaps someone else here would know something else. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Mon Jun 29 09:26:29 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA29326; Mon, 29 Jun 1998 09:26:27 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA28505; Mon, 29 Jun 1998 09:17:49 -0700 Resent-Date: Mon, 29 Jun 1998 09:17:49 -0700 Date: Mon, 29 Jun 1998 09:09:47 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"fVR-A2.0.Dz6.iuxbr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3165 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > The current ioctls are: > > How about inserting something like: /* GGI gets 0x8000-0xDFFF */ #define FBIOGGI_START 0x8000 That's quite a number of ioctls... :) But having a hard specification sounds like it would make more sense. > Beep... /dev/fb%d /dev/fb0 is the "current framebuffer" I hope, like /dev/tty0 is an alias for the current console... :) ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Mon Jun 29 09:28:25 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA29331; Mon, 29 Jun 1998 09:28:23 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA31208; Mon, 29 Jun 1998 09:24:33 -0700 Resent-Date: Mon, 29 Jun 1998 09:24:33 -0700 From: Andrew Apted Message-ID: <19980630022010.63249@ajax.netspace.net.au> Date: Tue, 30 Jun 1998 02:20:10 +1000 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI progress Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Jon M. Taylor on Mon, Jun 29, 1998 at 02:52:30AM -0700 Resent-Message-ID: <"7UIK23.0.Td7.0_xbr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3167 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon writes: > Thanks to Geert's fixes, I now have Dali's Trio64V+ driver > inserting as an fbdev module, and 'con2fbmap 0 1' gives me nice 640x400x32 > graphical consoles. Scrollback works. Display is rotated on VC switches. > I tried LibGGI/Degas's fbdev target but the setsid() call dies. And I > cannot find a precomplied XF86_fbdev anywhere.... The fbdev target should run as root... I'm still sorting out some of the non-suid issues (whether there is a "right" way, or whether the kernel is somewhat broken...). I can also send you a pre-compiled XF68_FBDev X server. It's 1 MB when compressed -- too much for an email ? It doesn't have support for 32 bit mode either, so it won't work until you get 8 & 16 bit modes going :-) Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Mon Jun 29 09:38:31 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA29336; Mon, 29 Jun 1998 09:38:29 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA01138; Mon, 29 Jun 1998 09:34:51 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 09:34:51 -0700 (PDT) Date: Mon, 29 Jun 1998 12:27:04 -0400 (EDT) From: Steve Cheng Sender: steve@maxt6m32.ipoline.com To: ggi Mailingliste Subject: Re: display-tile? In-Reply-To: <199806291616.SAA07366@cip8.e-technik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"0RcJj2.0.gH.f8ybr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3169 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 29 Jun 1998, Hartmut Niemann wrote: > Hi! > I tried my first libggi build from the develcvs today. > > Where is the tile target? It is in the tree but config/libggi.conf doesn't know it. Want to add it back in? > Is it usable? Not really :-) It's still doing that framebuffer blit hack. I haven't touched in a long while so it might have some nasty bugs. If anyone does test it, please go ahead and fix any problems, or just tell me about the problems and I'll fix it. I'm busy with a new VNC target now, then I'll update display-tile... -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Mon Jun 29 09:39:01 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA29341; Mon, 29 Jun 1998 09:38:59 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA32535; Mon, 29 Jun 1998 09:31:27 -0700 Resent-Date: Mon, 29 Jun 1998 09:31:27 -0700 From: Hartmut Niemann Message-Id: <199806291631.SAA07628@cip8.e-technik.uni-erlangen.de> Subject: display-mult: how? To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Mon, 29 Jun 1998 18:31:22 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Xlkam1.0.1y7.S5ybr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3168 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I tried export LIBGGI_DISPLAY="display-multi:display-X;display-X" and ran demo, and two windows popped up; one of them got actually drawn, the other one reacted on the key presses (actually: one window reacted on the keypresses to the other window). What did I do wrong? What is the exact display-multi syntax? Hartmut -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 29 09:40:23 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA29352; Mon, 29 Jun 1998 09:40:21 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA29588; Mon, 29 Jun 1998 09:24:17 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 09:24:17 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806291616.SAA07366@cip8.e-technik.uni-erlangen.de> Subject: display-tile? To: ggi-develop@eskimo.com (ggi Mailingliste) Date: Mon, 29 Jun 1998 18:16:54 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"chA3Z.0.CE7.l-xbr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3166 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi! I tried my first libggi build from the develcvs today. Where is the tile target? Is it usable? And I'm going to hunt the bug in ggiCIrcle ... Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 29 09:44:08 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA29358; Mon, 29 Jun 1998 09:44:06 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA02237; Mon, 29 Jun 1998 09:42:32 -0700 Resent-Date: Mon, 29 Jun 1998 09:42:32 -0700 Sender: thomas@eskimo.com Message-ID: <3597C146.1DA62292@gmx.de> Date: Mon, 29 Jun 1998 18:31:02 +0200 From: Thomas Tanner X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Future of GGI project References: <3594D413.17546C54@vertech.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"19F_-.0.HY.lFybr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3170 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Torgeir Veimo wrote: > Thomas presented an idea a while back with a 'new' libggi system, which > dealt with the interoperation between the kgi part of a driver and the > userland-library part of the driver more than with the api nature of > libggi. Not really. I proposed a libggi system, which does not fix us to *any* drawing API, moves events completely out to libgii and has IMHO better abstraction and consistency than our exisiting libggi. I've collected my ideas and have written a specification for this new design, which is, however, quite incompatible with the current "design". Specificiation and snapshot can be obtained from http://home.pages.de/~tanner/ggi.html#design -- Thomas Tanner ----------------------------- email: tanner@gmx.de tanner@ggi-project.org web: http://home.pages.de/~tanner GGI: http://www.ggi-project.org From ggi-develop-request@eskimo.com Mon Jun 29 10:11:31 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA29380; Mon, 29 Jun 1998 10:11:27 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA05871; Mon, 29 Jun 1998 10:13:07 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 10:13:07 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806291705.TAA08139@cip8.e-technik.uni-erlangen.de> Subject: Re: display-tile? To: ggi-develop@eskimo.com Date: Mon, 29 Jun 1998 19:05:32 +0200 (MESZ) In-Reply-To: <199806291616.SAA07366@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at Jun 29, 98 06:16:54 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"C1DXd2.0.ZR1.Uiybr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3171 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > And I'm going to hunt the bug in ggiCIrcle ... > Found and fixed. Somebody replaces a ggiCircle call in the testpattern demo with a draw-box command. Oh boy... Hartmut -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 29 12:05:18 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA29476; Mon, 29 Jun 1998 12:04:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA21907; Mon, 29 Jun 1998 12:07:01 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 12:07:01 -0700 (PDT) From: Andrew Apted Message-ID: <19980630045519.07634@ajax.netspace.net.au> Date: Tue, 30 Jun 1998 04:55:19 +1000 To: ggi-develop@eskimo.com Subject: Re: display-mult: how? Reply-To: ggi-develop@eskimo.com References: <199806291631.SAA07628@cip8.e-technik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199806291631.SAA07628@cip8.e-technik.uni-erlangen.de>; from Hartmut Niemann on Mon, Jun 29, 1998 at 06:31:22PM +0200 Resent-Message-ID: <"nLXtq1.0.4M5.IN-br"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3172 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut writes: > I tried export LIBGGI_DISPLAY="display-multi:display-X;display-X" > and ran demo, and two windows popped up; > one of them got actually drawn, the other one reacted on the key > presses (actually: one window reacted on the keypresses to the > other window). > > What did I do wrong? > > What is the exact display-multi syntax? Sub-targets should be parenthesized. EG: multi:(X):(X) trueemu:8d4:(fbdev:/dev/fb0) monotext:1x2:(KGI) but if they're the last thing on the line, it isn't mandatory. EG: multi:(X):X trueemu:8d4:fbdev:/dev/fb0 Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Mon Jun 29 12:17:32 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA29481; Mon, 29 Jun 1998 12:17:26 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA23116; Mon, 29 Jun 1998 12:14:13 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 12:14:13 -0700 (PDT) Date: Mon, 29 Jun 1998 21:04:43 +0200 (MEST) From: Jan Kneschke To: ggi-develop@eskimo.com Subject: Re: tutorial for ggi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"63EUk1.0.3f5.3U-br"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3173 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Sun, 28 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > Hi ! > > > the first step is easy: > > > > ggiInit(); > > ggiOpen(); > > setGraphMode(); > > ggiPuts("HELLO WORLD"); > > > > (wait) > > > > setTextMode(); > > This is not needed. ggiClose is supposed to restore the state of the target. > You cannot know the mode it had before, anyway. > > > i think the next step will be getBox/putBox example. what about "hello > > world" moving over the display transformed over an sinus ? > > Hmm - BTW - there already is a section on that in the LibGGI docs, so you > might want to enhance this one. And check demo.c which is our primary > commented example. i know that demo.c is a good example, but it is too huge for beginners. i will look at the docs for startin this tutorial. > > after that some clipping? BTW: is there a definition in libggi for inner and > > outer clipping ?? virge can do it. > > You mean "clip inside rect" and "clip outside rect" ? yes. > No. But I suppose LibGGI2D might want to handle that. Though outside- > clipping isn't a too common operation anyway ... ok. > > but what after this basic steps ?? can you give me some advices ?? > > Read the existing examples. demo.c should be well commented. i don't want to see what has been done because i've already seen it. i just want to have a hint into which direction my tutorial should aim. perhaps i should take the warp-demo. it is small and not too complex. it just needs some enhancements for input, ggi-console ... please give me some ideas taht would discribe to features of ggi. i want to collect them and start a nice tutorial based on these ideas. but i need your input, because i don't know the bleeding edges of ggi (ggi-console, ...). > CU, Andy > > -- > = Andreas Beck | Email : = > > thats all Jan --- Project: GGI - S3-Vision-driver -- http://www.ggi-project.org/ -)= Jan (Weigon) Kneschke -- Kiel -- Northern Germany =(- From ggi-develop-request@eskimo.com Mon Jun 29 12:20:28 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA29486; Mon, 29 Jun 1998 12:20:11 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA24315; Mon, 29 Jun 1998 12:22:15 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 12:22:15 -0700 (PDT) Date: Mon, 29 Jun 1998 12:14:33 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI progress In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"eDYeB3.0.nx5.Zb-br"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3175 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 29 Jun 1998, Geert Uytterhoeven wrote: > On Mon, 29 Jun 1998, Jon M. Taylor wrote: > > Thanks to Geert's fixes, I now have Dali's Trio64V+ driver > > inserting as an fbdev module, and 'con2fbmap 0 1' gives me nice 640x400x32 > > graphical consoles. Scrollback works. Display is rotated on VC switches. > > I tried LibGGI/Degas's fbdev target but the setsid() call dies. And I > > cannot find a precomplied XF86_fbdev anywhere.... > > > > I cannot seem to be able to compile the driver into the kernel, > > though - if VGA console is enabled none of the other compiled-in drivers > > show up in /proc/fb, and if VGA is not selected the system boots up with > > Did you add the init function of your Trio64V+ `frame buffer device' (:-) to > drivers/char/fbmem.c? Grrr... nope. That's probably it. > Other thing I can think of: the late initialization of the PCI subsystem. > > > no display. I think I will wait for the console initialization questions > > to be resolved in linux-kernel before I try this again. Damn, I want to > > see that peguin logo on bootup |->. > > Then hardcode the address for your graphics board, so it doesn't rely on the > PCI subsystem :-) I did. But, that is not a permanent solution. PCI *has* to be present when the display subsystem is initialized. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Mon Jun 29 12:21:34 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA29496; Mon, 29 Jun 1998 12:21:18 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA18861; Mon, 29 Jun 1998 12:18:18 -0700 Resent-Date: Mon, 29 Jun 1998 12:18:18 -0700 Date: Mon, 29 Jun 1998 12:18:02 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"jXjdx1.0.Vc4.uX-br"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3174 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 29 Jun 1998, Geert Uytterhoeven wrote: > On Mon, 29 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > > > This should make writing an accelerated version of the fbmem target a > > SMOP. > > > > It could just do something like > > > > open("/dev/fbmem");ioctl(fb,KGI_VERSION_CHECK,&rc); > ^^^^^^^^^^ > Beep... /dev/fb%d How do you know which fbx device to open, though? Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Mon Jun 29 12:23:44 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA29503; Mon, 29 Jun 1998 12:23:30 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA19270; Mon, 29 Jun 1998 12:20:24 -0700 Resent-Date: Mon, 29 Jun 1998 12:20:24 -0700 Date: Mon, 29 Jun 1998 12:20:09 -0700 (PDT) From: "Jon M. Taylor" To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI progress In-Reply-To: <19980630022010.63249@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"fAMii.0.zi4.tZ-br"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3176 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 30 Jun 1998, Andrew Apted wrote: > Jon writes: > > > Thanks to Geert's fixes, I now have Dali's Trio64V+ driver > > inserting as an fbdev module, and 'con2fbmap 0 1' gives me nice 640x400x32 > > graphical consoles. Scrollback works. Display is rotated on VC switches. > > I tried LibGGI/Degas's fbdev target but the setsid() call dies. And I > > cannot find a precomplied XF86_fbdev anywhere.... > > The fbdev target should run as root... I'm still sorting out some of the > non-suid issues (whether there is a "right" way, or whether the kernel > is somewhat broken...). I didn't try it as root, I'll try that. > I can also send you a pre-compiled XF68_FBDev X server. It's 1 MB when > compressed -- too much for an email ? Try it and see |->. > It doesn't have support for 32 > bit mode either, so it won't work until you get 8 & 16 bit modes going :-) Which I need to do anyway.... Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Mon Jun 29 12:34:21 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA29518; Mon, 29 Jun 1998 12:34:18 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA24186; Mon, 29 Jun 1998 12:32:12 -0700 Resent-Date: Mon, 29 Jun 1998 12:32:12 -0700 Message-Id: <199806291931.VAA01559@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: display-mult: how? In-reply-to: Your message of "Mon, 29 Jun 1998 18:31:22 +0200." <199806291631.SAA07628@cip8.e-technik.uni-erlangen.de> Date: Mon, 29 Jun 1998 21:31:50 +0200 From: Marcus Sundberg Resent-Message-ID: <"wb2dE1.0.jv5.sk-br"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3177 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > I tried export LIBGGI_DISPLAY="display-multi:display-X;display-X" > and ran demo, and two windows popped up; > one of them got actually drawn, the other one reacted on the key > presses (actually: one window reacted on the keypresses to the > other window). > > What did I do wrong? > > What is the exact display-multi syntax? I haven't looked at the multi target, so I don't know what it's supposed to do. But due to the X-targets emulation of a DB, opening more than one visual in SYNC mode causes what can be best described as undefined behaviour. And I also just now noted that the mansync implementation causes the same behaviour in ASYNC mode. Luckily I also came up with an idea of how to fix this for both ASYNC and SYNC mode. :) I'll give it a try right away. //Marcus From ggi-develop-request@eskimo.com Mon Jun 29 13:11:18 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA29572; Mon, 29 Jun 1998 13:11:13 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA03903; Mon, 29 Jun 1998 13:03:19 -0700 Resent-Date: Mon, 29 Jun 1998 13:03:19 -0700 Date: Mon, 29 Jun 1998 22:03:07 +0200 (CEST) From: Geert Uytterhoeven To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"CmOIu3.0.ky.6C_br"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3178 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 29 Jun 1998, KC5TJA wrote: > > Beep... /dev/fb%d > > /dev/fb0 is the "current framebuffer" I hope, like /dev/tty0 is an alias > for the current console... :) No, dev/fb0 is the first frame buffer device. Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium From ggi-develop-request@eskimo.com Mon Jun 29 13:12:01 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA29573; Mon, 29 Jun 1998 13:11:16 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id NAA04189; Mon, 29 Jun 1998 13:04:20 -0700 Resent-Date: Mon, 29 Jun 1998 13:04:20 -0700 Date: Mon, 29 Jun 1998 22:04:17 +0200 (CEST) From: Geert Uytterhoeven To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"gSYtJ3.0.L11.3D_br"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3179 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 29 Jun 1998, Jon M. Taylor wrote: > On Mon, 29 Jun 1998, Geert Uytterhoeven wrote: > > On Mon, 29 Jun 1998 becka@rz.uni-duesseldorf.de wrote: > > > > > This should make writing an accelerated version of the fbmem target a > > > SMOP. > > > > > > It could just do something like > > > > > > open("/dev/fbmem");ioctl(fb,KGI_VERSION_CHECK,&rc); > > ^^^^^^^^^^ > > Beep... /dev/fb%d > > How do you know which fbx device to open, though? You have to know on what display you want to work. If you want to open the frame buffer device for the current console, you can use con2fbmap (the mapping console<->frame buffer device), for which there's an ioctl. Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium From ggi-develop-request@eskimo.com Mon Jun 29 15:48:18 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA29752; Mon, 29 Jun 1998 15:48:10 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id PAA22667; Mon, 29 Jun 1998 15:48:29 -0700 Resent-Date: Mon, 29 Jun 1998 15:48:29 -0700 Message-Id: <199806292248.AAA15191@zafir.e.kth.se> To: ggi-develop@eskimo.com Subject: Re: display-mult: how? In-reply-to: Your message of "Tue, 30 Jun 1998 04:55:19 +1000." <19980630045519.07634@ajax.netspace.net.au> Date: Tue, 30 Jun 1998 00:48:27 +0200 From: Marcus Sundberg Resent-Message-ID: <"1MeSn3.0.tX5.yc1cr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3180 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Sub-targets should be parenthesized. EG: > > multi:(X):(X) Won't work. Display targets are lowercase only. Exceptions are display-X, display-Xlib and display-KGI which are kept for backward compability. But I'd say they can be removed when we make all the other breaking changes next month. Or we can simply convert the display strings to lowercase before matching them. Also, multi:(x):(x) will open only one window, whereas multi:x;x opens two. I believe the latter is correct behaviour for multi, isn't it ? //Marcus From ggi-develop-request@eskimo.com Mon Jun 29 16:25:14 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA29789; Mon, 29 Jun 1998 16:25:09 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id QAA29334; Mon, 29 Jun 1998 16:18:01 -0700 Resent-Date: Mon, 29 Jun 1998 16:18:01 -0700 Message-Id: <199806292317.BAA03360@zafir.e.kth.se> To: ggi-develop@eskimo.com Cc: becka@ggi-project.org Subject: Bugfixes for X-target (was: Re: display-mult: how?) In-reply-to: Your message of "Mon, 29 Jun 1998 21:31:50 +0200." <199806291931.VAA01559@zafir.e.kth.se> Date: Tue, 30 Jun 1998 01:17:39 +0200 From: Marcus Sundberg Resent-Message-ID: <"H7XRb2.0.DA7.f22cr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3181 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Luckily I also came up with an idea of how to fix this for > both ASYNC and SYNC mode. :) I'll give it a try right away. Ok, here's a diff against the current CVS devel tree. It should support any number of simultaneous X visuals in the same process - both SYNC and ASYNC ones. I've tested it with LIBGGI_DISPLAY="multi:x;x;x;x" and it works fine with the "demo" demo. It also fixes a bug in the X-target: vis=ggiOpen(); ggiClose(vis); would cause a segfault if you didn't make a successful call to ggiSetMode() between them. Andy, do you want me to commit this before July 1st ? //Marcus ------------------------ cut here ----------------------- diff -burd degas/lib/libggi/display/X/Xvisual.h comp/lib/libggi/display/X/Xvisual.h --- degas/lib/libggi/display/X/Xvisual.h Fri Jun 19 20:11:58 1998 +++ comp/lib/libggi/display/X/Xvisual.h Tue Jun 30 00:36:10 1998 @@ -42,11 +42,36 @@ #define MANSYNC_CHILD #define MANSYNC_ISASYNC (((struct Xhooks *)LIBGGI_PRIVATE(vis))->isasync) -#define MANSYNC_DOFLUSH _GGIdoflush(xhk) #ifdef MANSYNC_CHILD +typedef struct { + ggi_visual **visuals; + int nrvisuals; + int nrsync; +} mansync_hook; + #define MANSYNC_CHILDPID (((struct Xhooks *)LIBGGI_PRIVATE(vis))->syncpid) #define MANSYNC_OLDHANDLER (((struct Xhooks *)LIBGGI_PRIVATE(vis))->oldsynchandler) + +/* This is defined in visual.c */ +extern mansync_hook mansync_hook_with_a_clashpreventing_name; + +#define MANSYNC_DOFLUSH { \ + if (mansync_hook_with_a_clashpreventing_name.nrsync) { \ + int i = 0; \ + while (i < mansync_hook_with_a_clashpreventing_name.nrvisuals) { \ + if (!XLIB_PRIV(mansync_hook_with_a_clashpreventing_name.visuals[i]) \ + ->isasync) { \ + _GGIdoflush(XLIB_PRIV(mansync_hook_with_a_clashpreventing_name.visuals[i])); \ + } \ + i++; \ + } \ + } \ +} +#elif defined(MANSYNC_PTHREAD) +#define MANSYNC_DOFLUSH _GGIdoflush(XLIB_PRIV(vis)) +#else +#define MANSYNC_DOFLUSH #error NEED TO DEFINE MANSYNC_PTHREAD or MANSYNC_CHILD #endif @@ -84,4 +109,3 @@ #define RELPTR_KEYS { XK_Control_L, XK_Alt_L, 'm' } #define RELPTR_KEYINUSE (1 | (1<<1) | (1<<2)) #define RELPTR_NUMKEYS 3 - diff -burd degas/lib/libggi/display/X/mode.c comp/lib/libggi/display/X/mode.c --- degas/lib/libggi/display/X/mode.c Tue Jun 23 20:51:13 1998 +++ comp/lib/libggi/display/X/mode.c Tue Jun 30 00:32:15 1998 @@ -196,9 +196,42 @@ return 0; } -static struct Xhooks *xhk; #include "../common/mansync.inc" +#ifdef MANSYNC_CHILD +int GGIflush(ggi_visual *vis) +{ + if (!XLIB_PRIV(vis)->ximage) return -1; + + if (MANSYNC_ISASYNC && !(LIBGGI_FLAGS(vis) & GGIFLAG_ASYNC)) { + if (!mansync_hook_with_a_clashpreventing_name.nrsync) + _mansync_start(vis); + else + MANSYNC_ISASYNC = 0; + mansync_hook_with_a_clashpreventing_name.nrsync++; + } else if (!MANSYNC_ISASYNC && (LIBGGI_FLAGS(vis) & GGIFLAG_ASYNC)) { + mansync_hook_with_a_clashpreventing_name.nrsync--; + if (!mansync_hook_with_a_clashpreventing_name.nrsync) + _mansync_stop(vis); + else + MANSYNC_ISASYNC = 1; + } + + return _GGIdoflush(XLIB_PRIV(vis)); +} +#else +int GGIflush(ggi_visual *vis) +{ + if (MANSYNC_ISASYNC && !(LIBGGI_FLAGS(vis) & GGIFLAG_ASYNC)) + _mansync_start(vis); + + else if (!MANSYNC_ISASYNC && (LIBGGI_FLAGS(vis) & GGIFLAG_ASYNC)) + _mansync_stop(vis); + + return MANSYNC_ISASYNC; +} +#endif /* MANSYNC_CHILD */ + #ifndef NO_SHM /* Hack to fall back when shm is not working. */ static int shmerror; @@ -409,7 +442,7 @@ AllocNone); } - _GGIdoflush(xhk=xhook); + _GGIdoflush(xhook); DPRINT("X: Flush.\n"); diff -burd degas/lib/libggi/display/X/visual.c comp/lib/libggi/display/X/visual.c --- degas/lib/libggi/display/X/visual.c Mon Jun 22 20:35:33 1998 +++ comp/lib/libggi/display/X/visual.c Tue Jun 30 00:15:24 1998 @@ -34,6 +34,9 @@ #include "ggi-dl.h" #include "Xvisual.h" + +mansync_hook mansync_hook_with_a_clashpreventing_name = { NULL, 0, 0 }; + /* * We are guaranteed to have been checked already... */ @@ -41,6 +44,7 @@ int GGIdlinit(ggi_visual *vis,const char *args) { struct Xhooks *xinfo; + int nrvisuals; DPRINT("X-lib starting.\n"); LIBGGI_PRIVATE(vis)=xinfo=malloc(sizeof(struct Xhooks)); @@ -89,6 +93,14 @@ DPRINT("X-lib has screen.\n"); DPRINT("X-lib fully up.\n"); + nrvisuals = ++mansync_hook_with_a_clashpreventing_name.nrvisuals; + if ((mansync_hook_with_a_clashpreventing_name.visuals = + realloc(mansync_hook_with_a_clashpreventing_name.visuals, + sizeof(ggi_visual*)*nrvisuals)) == NULL) + return GGI_DL_ERROR; + mansync_hook_with_a_clashpreventing_name.visuals[nrvisuals-1] + = vis; + if (GGI_VERSION_FUNCS(vis->opdisplay->version) >= 10) { /* Has mode management */ vis->opdisplay->flush=GGIflush; @@ -111,15 +123,13 @@ { struct Xhooks *xinfo; - ggiFlush(vis); - /* prevents a soon-to-be unloaded function from being called */ - if (!(LIBGGI_FLAGS(vis) & GGIFLAG_ASYNC)) - _mansync_stop(vis); + ggiSetInfoFlags(vis, GGIFLAG_ASYNC); + ggiFlush(vis); /* FIXME !!! */ - if ((xinfo=LIBGGI_PRIVATE(vis)) != NULL) - { + if ((xinfo=LIBGGI_PRIVATE(vis)) != NULL) { + int i, nrvisuals = mansync_hook_with_a_clashpreventing_name.nrvisuals; if (xinfo->cmap) XFreeColormap(xinfo->display,xinfo->cmap); #ifndef NO_SHM @@ -138,7 +148,23 @@ XDestroyWindow(xinfo->display,xinfo->window); if (xinfo->display) XCloseDisplay(xinfo->display); - free(LIBGGI_PRIVATE(vis)); + for (i = 0; i < nrvisuals; i++) { + if (mansync_hook_with_a_clashpreventing_name.visuals[i] + == vis) { + i++; + while (i < nrvisuals) { + memcpy(mansync_hook_with_a_clashpreventing_name.visuals[i-1], + mansync_hook_with_a_clashpreventing_name.visuals[i], + sizeof(ggi_visual *)); + i++; + } + if ((realloc(mansync_hook_with_a_clashpreventing_name.visuals, + sizeof(ggi_visual*)*nrvisuals)) != NULL) { + mansync_hook_with_a_clashpreventing_name.nrvisuals--; + } + } + } + free(xinfo); } return 0; Binary files degas/lib/libggi/display/X/visual.o and comp/lib/libggi/display/X/visual.o differ diff -burd degas/lib/libggi/display/aa/mode.c comp/lib/libggi/display/aa/mode.c --- degas/lib/libggi/display/aa/mode.c Mon Jun 22 20:35:34 1998 +++ comp/lib/libggi/display/aa/mode.c Mon Jun 29 22:30:24 1998 @@ -125,6 +125,17 @@ static struct AAhooks *ahk; #include "../common/mansync.inc" +int GGIflush(ggi_visual *vis) +{ + if (MANSYNC_ISASYNC && !(LIBGGI_FLAGS(vis) & GGIFLAG_ASYNC)) + _mansync_start(vis); + + else if (!MANSYNC_ISASYNC && (LIBGGI_FLAGS(vis) & GGIFLAG_ASYNC)) + _mansync_stop(vis); + + return MANSYNC_ISASYNC; +} + int GGIsetmode(ggi_visual *vis,ggi_mode *tm) { struct AAhooks *aahook; diff -burd degas/lib/libggi/display/common/mansync.inc comp/lib/libggi/display/common/mansync.inc --- degas/lib/libggi/display/common/mansync.inc Fri Jun 19 20:12:41 1998 +++ comp/lib/libggi/display/common/mansync.inc Tue Jun 30 00:11:31 1998 @@ -88,8 +88,8 @@ void _mansync_handler(int unused) { - signal(MANSYNC_SIGNAL,_mansync_handler); MANSYNC_DOFLUSH; + signal(MANSYNC_SIGNAL,_mansync_handler); } void _mansync_start(ggi_visual *vis) @@ -117,7 +117,7 @@ signal(MANSYNC_SIGNAL, MANSYNC_OLDHANDLER); kill(MANSYNC_CHILDPID, SIGKILL); waitpid(MANSYNC_CHILDPID, NULL, 0); - MANSYNC_ISASYNC= 1; + MANSYNC_ISASYNC = 1; } void _mansync_ignore(ggi_visual *vis) @@ -214,16 +214,5 @@ } #endif /* MANSYNC_ALARM */ - -int GGIflush(ggi_visual *vis) -{ - if (MANSYNC_ISASYNC && !(LIBGGI_FLAGS(vis) & GGIFLAG_ASYNC)) - _mansync_start(vis); - - else if (!MANSYNC_ISASYNC && (LIBGGI_FLAGS(vis) & GGIFLAG_ASYNC)) - _mansync_stop(vis); - - return MANSYNC_DOFLUSH; -} #endif /* MANSYNC_INC armor */ ------------------ cut here ----------------------------- PS. sorry for the terrible format of the diff! DS. From ggi-develop-request@eskimo.com Mon Jun 29 17:29:22 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA29877; Mon, 29 Jun 1998 17:29:18 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA25532; Mon, 29 Jun 1998 17:27:04 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 17:27:04 -0700 (PDT) Date: Mon, 29 Jun 1998 20:24:27 -0400 (EDT) From: MenTaLguY X-Sender: mental@moonbase To: ggi-develop@eskimo.com Subject: Re: Future of GGI project In-Reply-To: <199806300013.UAA04388@mentalnet.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"NnTlf.0.mE6.M33cr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3182 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Try submitting your stuff to Freshmeat or Slashdot. I've yet to see any > GGI-related announcements there. http://slashdot.org/. Freshmeat has a > link on Slashdot's web page. There's been some GGI-related discussion on Slashdot occasionally, and there is actually a Freshmeat entry on freshmeat. However, the former is extremely rare (most major one was Linux folks either throwing fits or celebrating -- mostly the former, which is a good sign :) -- due to rumors that we were dropping Linux for *BSD), and the latter is extremely out of date. Definitely need to start aggressively pursueing this end of the PR thing. -=MenTaLguY=- From ggi-develop-request@eskimo.com Mon Jun 29 17:32:29 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA29882; Mon, 29 Jun 1998 17:32:27 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id RAA26748; Mon, 29 Jun 1998 17:31:59 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 17:31:59 -0700 (PDT) Date: Mon, 29 Jun 1998 17:16:33 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"pkd3e.0.nX6.z73cr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3183 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Mon, 29 Jun 1998, Geert Uytterhoeven wrote: > On Mon, 29 Jun 1998, KC5TJA wrote: > > > Beep... /dev/fb%d > > > > /dev/fb0 is the "current framebuffer" I hope, like /dev/tty0 is an alias > > for the current console... :) > > No, dev/fb0 is the first frame buffer device. Admittedly, not the UNIX way of doing things... :) The con2fb command you mentioned in a previous message seems like too much overkill. But then, that's just me. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Mon Jun 29 17:53:28 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA29896; Mon, 29 Jun 1998 17:53:25 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id RAA20466; Mon, 29 Jun 1998 17:50:40 -0700 Resent-Date: Mon, 29 Jun 1998 17:50:40 -0700 Sender: torgeir@eskimo.com Message-ID: <359835B5.CB8EAD63@vertech.no> Date: Tue, 30 Jun 1998 02:47:49 +0200 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.1.104 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Future of GGI project References: <3594D413.17546C54@vertech.no> <3597C146.1DA62292@gmx.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"XbLxi3.0.E_4.TP3cr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3184 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Thomas Tanner wrote: > > I've collected my ideas and have written a specification for this new design, > which is, however, quite incompatible with the current "design". > Specificiation and snapshot can be obtained from > http://home.pages.de/~tanner/ggi.html#design Is it impossible to have a libGGI compatible api implemented using such a library <-> kgi interaction framework? -- -Torgeir From ggi-develop-request@eskimo.com Mon Jun 29 18:35:36 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA29959; Mon, 29 Jun 1998 18:35:33 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id SAA07291; Mon, 29 Jun 1998 18:35:31 -0700 Resent-Date: Mon, 29 Jun 1998 18:35:31 -0700 Message-ID: <00b501bda3cf$b311fc20$070a0a0a@MASSACRE> From: "David Waite" To: Subject: Re: job offers Date: Mon, 29 Jun 1998 21:35:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0518.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.0 Resent-Message-ID: <"m7XHh1.0.gn1.X34cr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3185 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com -----Original Message----- From: Jon M. Taylor > This fight is EvStack's now, not KGI's. KGI has the chance to get >into the kernel proper now, providing us with respectability and a >beachhead for the the future. It will give LibGGI a lot of much-needed >exposure (people are STILL working on SVGALib, for RMS' sake!) and maybe >make people look more kindly on EvStack when it's time to shine comes. So let me get all of this straight: KGI will not be changed (still be kept independant), but fbcon is being modified to use KGI and (hopefully) have a single ioctl for accel interfacing? Then the whole mess can either be used with the fbcon target for libggi, the kgi target for libggi, or to-the-metal KGI driver programming? If I got this right, this is extremely good news. We get KGI support into the 2.2 kernels (well, in one form or another), and get PR for native KGI, libGGI, and EvStacks. Then later on, perhaps fbcon gets collapsed into KGI (their roles reversed), EvStack becomes popular on its merits, etc. >> That sound resonable to me. We keep /dev/graphic and provide a >> compatibility fbcon module that translates fbcon calls to KGI one. > > I like Andy's "wrapper ioctl" idea better - add one more ioctl to >fbcon which is used to tunnel through to the KGI layer directly. Having >two devices controlling the same hardware at the same time is asking for >synchronization problems. > Yeah (based on my understanding above) adding acceleration into fbcon (to a KGI target) is much better than trying to get KGI in front of fbcon. Keeping the two seperate is a bad idea... people will be motivated to use our code by integrating it with fbcon (Why to I feel like Microsoft? Here comes GGI Explorer) Trying to create two interfaces to the device is a bad idea. Compromising in a way that gets KGI leveraged into fbcon could mean that later on (perhaps 2.3.x) fbcon gets depreciated and KGI takes over. I don't think the raw horsepower to get this done for all the needed hardware, targets, platforms can be gotten by staying independant from the main Linux tree. If KGI is kept as 'bridged' from fbcon, anyone can still do anything they want with it. KGI is currently aimed to be (mostly) platform independant correct? >> Again no. You are proposing to throw code away which was once believed to >> be the solution of all problems :=) > > Not throw it away, but throw it *out* - of KGI and into EvStack, >where it really belongs anyway. > If EvStack is really as independant from KGI as I gather from this list, this sounds like a good idea. Dump it all to the linux-input list, and have them work on it/make it grow. I still think that EvStack will be incredibly useful in the future. >> AFAIK >> there's no way in standard kernel to attach/detach keyboards and other input >> devices on the fly to consoles. If we want to provide libGII one day, this >> lib will also require evstack > > EvStack is a wonderful idea, but it is really about consoles and >input devices, not graphics. KGI is a great idea too, but it is really >about a nice video driver model and not about consoles. Either should be >useable without the other (KGI+fbcon or EvStack+old kernel drivers), even >though we all hope to have KGI+EvStack eventually. > I agree completely. Support for current video cards in Linux won't happen until something like KGI exists. IMHO, good graphics support is neccessary for Linux to continue to grow, at least in the direction I personally would like. EvStack is an awesome idea, but if it prevents our accelerated graphics support from getting in, drop it. I am convinced it will eventually get in on its own merits; for a while there everyone was saying how they didn't think KGI could get in, and hoped EvStack would leverage it. >> Just because fbcon is in devel kernel now and works doesn't mean we have to >> trash our code. At least not now. We are still in early devel stage (which >> is IMHO a shame) and we should be free to code our way. Yes, our consoles >> have unmapped keys, but that's rather an implementation problem and shows >> that our progress is slow. > > Again, the code is not getting trashed but moved to EvStack >(unless a better implementation already exists in EvStack of course). > Our progress will greatly speed up once KGI is noticed =) >> Let the user decide - if GGI is good, GGI will be adopted and fbcon >> forgetten. Standard kernel != good. Not necessarily. (For example, I >> never liked /dev/vcsa?? > > "GGI" is the developer community. What goes or does not go into >the kernel is EvStack/KGI/KGI drivers, etc. We _cannot_ have the "all or >nothing" attitude, because then we will likely get nothing |- <. Whereas >if we get the KGI driver system into the kernel, we will have lots of >people who may never have heard of GGI before become exposed to our work >and the rest of our work will have a leg up at that point. > Exactly. On both points. If KGI grows to be as good as I hope it to be, fbcon will get dropped on all the platforms that currently need it. If the EvStack concept grows to be necessary (I'm gathering from the existance of linux-input that it will) it will get in. But I see KGI getting acceptance much quicker, and creating much more attention among graphics companies toward Linux. >> IIRC, there were good reasons to justify a major change in the >> driver API. Adapting the drivers is quite some work, but doable. And once >> again, I don't care about fbcon. > > Let me tell you what *will* happen if we were to insist that >things stay as they are and that KGI consoles should replace fbcon. What >will happen is that people will begin porting X, SVGALib and KGI drivers >directly to fbcon. They will then have even LESS incentive to switch from >fbcon, and in addition they will have to work within the chaos that is the >existing driver/video "structure". > > We ***HAVE*** to care about and work with fbcon. > Right. If we let a non-accelerated solution like fbcon get acceptance, we will have that much more to overcome to get accepted. Imagine how much opposition there was before, now add creating duplication of functionality, conflicts between the two interfaces when both are used at once, and much less to gain. To me, KGI isn't as attractive to me in not requiring SUID, but because companies can create a driver for linux once, and can release it as a single binary module per platform. >> Sometimes we have to make compromises, sometimes we are better off going >> into contest. If we are good we have a good chance to win. > > Which I say that we do not. > I don't think so either. It is different facing a kernel that has no graphics support or standard, and facing one that has an accepted standard (even if that standard isn't the absolute best way to do something). If we can get our foot in the door now, we need to. If KGI can get in the kernel in any form without sacrificing important ideals such as platform independance, IMHO everyone should jump for the chance =) -David Waite From ggi-develop-request@eskimo.com Mon Jun 29 19:13:07 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA29983; Mon, 29 Jun 1998 19:13:05 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA25375; Mon, 29 Jun 1998 19:11:58 -0700 Resent-Date: Mon, 29 Jun 1998 19:11:58 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: tutorial for ggi To: ggi-develop@eskimo.com Date: Tue, 30 Jun 1998 00:09:28 +0200 (MET DST) In-Reply-To: <199806281620.SAA26684@zafir.e.kth.se> from "Marcus Sundberg" at Jun 28, 98 06:20:31 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"AmBaO.0.AC6.hb4cr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3187 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > ggiInit(); > ggiOpen(); > setGraphMode(); > + ggiSetInfoFlags(GGIFLAG_ASYNC); > ggiPuts("HELLO WORLD"); > + ggiFlush(); > > (wait) > > - setTextMode(); > ggiClose(); > ggiExit(); Patch acknowledged. Both good points ! Maybe one should heavily comment on what the difference between SYNC and ASYNC mode is, and why ASYNC is _much_ preferred. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 29 19:15:14 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA29988; Mon, 29 Jun 1998 19:15:12 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA25249; Mon, 29 Jun 1998 19:11:25 -0700 Resent-Date: Mon, 29 Jun 1998 19:11:25 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: tutorial for ggi To: ggi-develop@eskimo.com Date: Mon, 29 Jun 1998 23:29:47 +0200 (MET DST) In-Reply-To: <35969CEE.28EA55B2@stu.ac.cc.md.us> from "Chris Meadors" at Jun 28, 98 03:43:42 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"l3H0A2.0.LA6.Bb4cr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3186 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > but what after this basic steps ?? can you give me some advices ?? > > How about the "proper" way to get keypresses (since demo.c doesn't use it)? > Something simple like moving box on the screen with the arrow key that > leaves trails behind (see the svgalib demos). That's a good one. Together with a few standard ASCII keys like "c" to change color or such. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Mon Jun 29 19:20:42 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA29995; Mon, 29 Jun 1998 19:20:39 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id TAA27268; Mon, 29 Jun 1998 19:17:54 -0700 Resent-Date: Mon, 29 Jun 1998 19:17:54 -0700 From: Andrew Apted Message-ID: <19980630121330.48681@ajax.netspace.net.au> Date: Tue, 30 Jun 1998 12:13:30 +1000 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Jon M. Taylor on Mon, Jun 29, 1998 at 12:18:02PM -0700 Resent-Message-ID: <"nmJaU.0.tf6.Gh4cr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3188 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Jon writes: > > > open("/dev/fbmem");ioctl(fb,KGI_VERSION_CHECK,&rc); > > ^^^^^^^^^^ > > Beep... /dev/fb%d > > How do you know which fbx device to open, though? It's like "How do you know which head to run the gfx app on ?". The fbdev target follows the convention of the FRAMEBUFFER env-var. So you can tell libggi explicity (e.g. "fbdev:/dev/fb1"), or implicity ("export FRAMEBUFFER=/dev/fb1"), otherwise it defaults to /dev/fb0. Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Mon Jun 29 19:26:11 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA30000; Mon, 29 Jun 1998 19:26:09 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id TAA10774; Mon, 29 Jun 1998 19:29:01 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 19:29:01 -0700 (PDT) From: Andrew Apted Message-ID: <19980630121715.36134@ajax.netspace.net.au> Date: Tue, 30 Jun 1998 12:17:15 +1000 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge Reply-To: ggi-develop@eskimo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from KC5TJA on Mon, Jun 29, 1998 at 05:16:33PM -0700 Resent-Message-ID: <"iOPSo.0.Ee2.hr4cr"@mx2> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3189 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com KC5TJA writes: > > > /dev/fb0 is the "current framebuffer" I hope, like /dev/tty0 is an alias > > > for the current console... :) > > > > No, dev/fb0 is the first frame buffer device. > > Admittedly, not the UNIX way of doing things... :) Does UNIX have a "current hard disk" ? :-). There is one /dev/fbN device for each head ( = monitor + card). Cheers, _____________________________________________ ____ \ / Andrew Apted \/ From ggi-develop-request@eskimo.com Mon Jun 29 23:06:43 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA30094; Mon, 29 Jun 1998 23:06:40 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id WAA21708; Mon, 29 Jun 1998 22:54:27 -0700 Resent-Date: Mon, 29 Jun 1998 22:54:27 -0700 Message-ID: <19980630005256.40136@fries.net> Date: Tue, 30 Jun 1998 00:52:56 -0500 From: "Todd T. Fries" To: ggi-develop@eskimo.com Subject: back up Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e Resent-Message-ID: <"hFsUL1.0.4J5.Is7cr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3190 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I don't know how many of you attempted to access my anoncvs server while the power was out in my apartment for 6 hours or so due to storms in the area .. but, power's back now. -- Todd Fries .. toddf@acm.org From ggi-develop-request@eskimo.com Mon Jun 29 23:52:57 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA30147; Mon, 29 Jun 1998 23:52:55 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id XAA09051; Mon, 29 Jun 1998 23:54:54 -0700 (PDT) Resent-Date: Mon, 29 Jun 1998 23:54:54 -0700 (PDT) From: Hartmut Niemann Message-Id: <199806300647.IAA29127@cip8.e-technik.uni-erlangen.de> Subject: Re: fbcon-KGI bridge To: ggi-develop@eskimo.com Date: Tue, 30 Jun 1998 08:47:34 +0200 (MESZ) In-Reply-To: <19980630121715.36134@ajax.netspace.net.au> from "Andrew Apted" at Jun 30, 98 12:17:15 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lQW3v1.0.FD2.yk8cr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3192 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > KC5TJA writes: > > > Admittedly, not the UNIX way of doing things... :) > > Does UNIX have a "current hard disk" ? :-). > No, but Unix has a current working directory. Does that count? Hartmut -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Mon Jun 29 23:59:30 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA30154; Mon, 29 Jun 1998 23:59:23 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id XAA27832; Mon, 29 Jun 1998 23:45:11 -0700 Resent-Date: Mon, 29 Jun 1998 23:45:11 -0700 From: Hartmut Niemann Message-Id: <199806300645.IAA29119@cip8.e-technik.uni-erlangen.de> Subject: Re: tutorial for ggi To: andreas.beck@ggi-project.org Date: Tue, 30 Jun 1998 08:45:13 +0200 (MESZ) Cc: ggi-develop@eskimo.com (ggi Mailingliste) In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jun 30, 98 00:09:28 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"v2wkC2.0.mo6.sb8cr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3191 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > > > ggiInit(); > > ggiOpen(); > > setGraphMode(); > > + ggiSetInfoFlags(GGIFLAG_ASYNC); > > ggiPuts("HELLO WORLD"); > > + ggiFlush(); > > > > (wait) > > > > - setTextMode(); > > ggiClose(); > > ggiExit(); > > Patch acknowledged. Both good points ! > > Maybe one should heavily comment on what the difference between SYNC and > ASYNC mode is, and why ASYNC is _much_ preferred. > > CU,Andy http://cip8.e-technik.uni-erlangen.de:8080/hyplan/niemann/ggidoc/libggi/libggi-5.html#ss5.1 but you knew that ... Hartmut. -- Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi] From ggi-develop-request@eskimo.com Tue Jun 30 01:01:13 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA30275; Tue, 30 Jun 1998 01:01:11 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id BAA16147; Tue, 30 Jun 1998 01:02:26 -0700 (PDT) Resent-Date: Tue, 30 Jun 1998 01:02:26 -0700 (PDT) Date: Tue, 30 Jun 1998 00:54:42 -0700 (PDT) From: "Jon M. Taylor" To: GGI mailing list Subject: Heretic and Hexen source code released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"RLicb.0.9y3.Fk9cr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3193 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Saw this on Slashdot. The Doom source has been ported to GGI so this shouldn't be too tough.... Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed From ggi-develop-request@eskimo.com Tue Jun 30 05:22:30 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA30529; Tue, 30 Jun 1998 05:22:27 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id FAA21438; Tue, 30 Jun 1998 05:11:35 -0700 Resent-Date: Tue, 30 Jun 1998 05:11:35 -0700 Sender: torgeir@eskimo.com Message-ID: <3598C001.C3F1D851@vertech.no> Date: Tue, 30 Jun 1998 12:37:53 +0200 From: Torgeir Veimo Organization: Vertech AS X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.1.104 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge References: <199806300647.IAA29127@cip8.e-technik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"z1wWK1.0.mE5.sNDcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3194 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hartmut Niemann wrote: > > > > > KC5TJA writes: > > > > > Admittedly, not the UNIX way of doing things... :) > > > > Does UNIX have a "current hard disk" ? :-). > > > No, but Unix has a current working directory. Does that count? The _shell_ has a current working directory. Unix itself only has one current working process... (Yeah, I know about SMP...) 8) -- -Torgeir From ggi-develop-request@eskimo.com Tue Jun 30 06:44:15 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA30605; Tue, 30 Jun 1998 06:44:12 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id GAA31697; Tue, 30 Jun 1998 06:28:22 -0700 Resent-Date: Tue, 30 Jun 1998 06:28:22 -0700 X-Authentication-Warning: acc7.ac.cc.md.us: acom93.ac.cc.md.us [208.214.13.93] didn't use HELO protocol Message-ID: <359916A3.1DD5@stu.ac.cc.md.us> Date: Tue, 30 Jun 1998 09:47:31 -0700 From: Chris Meadors X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: ggiGetc or ggiGetkey? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"QbT4P.0.9l7.rVEcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3195 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com I don't know if this is a problem with all targets, but at least 'display-x' (the only one I could get working with Degas) ggiGetc doesn't work as I would expect. I wrote a simple program to start testing the input fuctions for a game engine I've been fooling around with. The program just opens a visual sets the foreground and background colors, and then ggiPuts's a simple string to the visual. Then it goes into a do while loop that has a "keypress = ggiGetc(); printf("%X", keypress)" (yeah, I know I won't see the printf output on most displays, but hey I'm just playing). It does that as long as you don't press an undefined key (PrintScrn, Scroll Lock, Pause, the Context menu key on a Windows keyboard): i.e. while(keypress). Well anyway my problem. ggiGetc is described as "Gets a character from the keyboard. Blocks if no key is available. Return: a 16-bit Unicode character." Really sounds like it should return a charater. But when I press "Shift" I get the scancode for the shift key. While holding Shift I press 'c', I get ASCII value for 'c' not 'C'. Num Lock, Caps Lock, and Scroll Lock all return values (that could be cool, but not what I expected) and their state doesn't matter. I can never enter values from the num pad, num pad '5' returns '0' and exits my program. Just bunches of unexpected stuff. Am I expecting the wrong thing. If so how do I get an uppercase letter from libggi? Or is just the disply-x target broken? Sorry I couldn't test it anywhere else, I'm just having bundles of trouble getting the svgalib and aalib targets working with Degas, while they worked fine with Dali (but that is for another mail). -Chris From ggi-develop-request@eskimo.com Tue Jun 30 07:04:04 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA30651; Tue, 30 Jun 1998 07:04:01 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id GAA20601; Tue, 30 Jun 1998 06:42:26 -0700 (PDT) Resent-Date: Tue, 30 Jun 1998 06:42:26 -0700 (PDT) Date: Tue, 30 Jun 1998 09:35:05 -0400 (EDT) From: Jonathan C Day X-Sender: j.c.day@express.larc.nasa.gov To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: <3598C001.C3F1D851@vertech.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"JffZ12.0.n15.0jEcr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3196 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 30 Jun 1998, Torgeir Veimo wrote: > Hartmut Niemann wrote: > > > > > > > > KC5TJA writes: > > > > > > > Admittedly, not the UNIX way of doing things... :) > > > > > > Does UNIX have a "current hard disk" ? :-). > > > > > No, but Unix has a current working directory. Does that count? Depends a bit on what's meant by "current hard disk". If it's the hard disk that a given process would be accessing, if it were to access the current working directory, then that information is available. (Well, obviously, since Unix needs that information and both 'mount' and 'df' display it!) If it's the "default" hard disk (a-la DOS), then no. > > The _shell_ has a current working directory. Unix itself only has one > current working process... > > (Yeah, I know about SMP...) 8) Don't forget Beowulf! :) (Although I suppose that's still one current process per box...) From ggi-develop-request@eskimo.com Tue Jun 30 07:35:26 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA30691; Tue, 30 Jun 1998 07:35:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id HAA10292; Tue, 30 Jun 1998 07:12:12 -0700 Resent-Date: Tue, 30 Jun 1998 07:12:12 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3598F24D.C1D85177@e.kth.se> Date: Tue, 30 Jun 1998 16:12:30 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: ggiGetc or ggiGetkey? References: <359916A3.1DD5@stu.ac.cc.md.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"JE_ls.0.hW2.x8Fcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3197 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Chris Meadors wrote: > Well anyway my problem. ggiGetc is described as "Gets a character from > the keyboard. Blocks if no key is available. Return: a 16-bit Unicode > character." Really sounds like it should return a charater. But when I > press "Shift" I get the scancode for the shift key. While holding Shift > I press 'c', I get ASCII value for 'c' not 'C'. Num Lock, Caps Lock, > and Scroll Lock all return values (that could be cool, but not what I > expected) and their state doesn't matter. I can never enter values from > the num pad, num pad '5' returns '0' and exits my program. Just bunches > of unexpected stuff. > > Am I expecting the wrong thing. If so how do I get an uppercase letter > from libggi? Or is just the disply-x target broken? Sorry I couldn't > test it anywhere else, I'm just having bundles of trouble getting the > svgalib and aalib targets working with Degas, while they worked fine > with Dali (but that is for another mail). The whole keyboard subsystem in GGI is severely broken. The agreement was that this should be taken care of after the move to EvStack, and IIRC someone even said that he'd take that task. And now we have moved to EvStack, so we better do something about it! //Marcus From ggi-develop-request@eskimo.com Tue Jun 30 08:16:56 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA30729; Tue, 30 Jun 1998 08:16:50 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA30447; Tue, 30 Jun 1998 08:06:10 -0700 Resent-Date: Tue, 30 Jun 1998 08:06:10 -0700 From: becka@rz.uni-duesseldorf.de Message-Id: <199806301504.RAA10703@sunserver1.rz.uni-duesseldorf.de> Subject: Re: ggiGetc or ggiGetkey? In-Reply-To: <359916A3.1DD5@stu.ac.cc.md.us> from Chris Meadors at "Jun 30, 98 09:47:31 am" To: ggi-develop@eskimo.com Date: Tue, 30 Jun 1998 17:04:42 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"S2Rh61.0.rQ7.RxFcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3198 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > Well anyway my problem. ggiGetc is described as "Gets a character from > the keyboard. Blocks if no key is available. Return: a 16-bit Unicode > character." Really sounds like it should return a charater. But when I > press "Shift" I get the scancode for the shift key. Hmm - you should get something like the K_VOID key showing that a key was pressed, but it had no significant translation. It could as well return some value from the Unicode reserved pages. > While holding Shift I press 'c', I get ASCII value for 'c' not 'C'. This is a bug in the X target. Someone who knows how to do that, PLEASE fix that - it has been in there for too long now. > Num Lock, Caps Lock, and Scroll Lock all return values (that could be cool, > but not what I expected) Thi is o.k., as long as the Rcs are from the Unicode reserved pages. > and their state doesn't matter. That isn't o.k. and should be fixed. > Am I expecting the wrong thing. If so how do I get an uppercase letter > from libggi? You should get it just the way you try. Someone please fix the X target. CU, Andy -- Andreas Beck | Email : From ggi-develop-request@eskimo.com Tue Jun 30 08:54:27 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA30751; Tue, 30 Jun 1998 08:54:23 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA18697; Tue, 30 Jun 1998 08:46:06 -0700 Resent-Date: Tue, 30 Jun 1998 08:46:06 -0700 Sender: core@orb.suntech.fr Message-ID: <3599084F.846F8281@suntech.fr> Date: Tue, 30 Jun 1998 15:46:24 +0000 From: Emmanuel Marty Reply-To: core@suntech.fr Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"nTNk01.0.bZ4.zWGcr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3200 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > And the reason UNIX doesn't have a notion of current harddisk is because > everything is mounted (ultimately) off a single mount point -- / . > Something like AmigaOS, however, DOES support the notion of a current > harddisk. DOS does as well, but nowhere near as good, IMHO. But that's a > different topic all-together. ;P Actually AmigaOS doesn't either, "kernel-wise", as you mean it. The shell does. -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 30 08:56:54 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA30756; Tue, 30 Jun 1998 08:56:52 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id IAA16714; Tue, 30 Jun 1998 08:42:20 -0700 Resent-Date: Tue, 30 Jun 1998 08:42:20 -0700 Date: Tue, 30 Jun 1998 08:34:06 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: <19980630121715.36134@ajax.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"W-fi1.0.x44.QTGcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3199 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Does UNIX have a "current hard disk" ? :-). There is one /dev/fbN > device for each head ( = monitor + card). A bad comparison, in my opinion, since UNIX does support the notion of a "current terminal." (/dev/console or /dev/tty depending on UNIX version). Why can't we extend this to include framebuffer dvices too? It doesn't seem like it'd be that hard. Even if it's /dev/framebuf or whatever... And the reason UNIX doesn't have a notion of current harddisk is because everything is mounted (ultimately) off a single mount point -- / . Something like AmigaOS, however, DOES support the notion of a current harddisk. DOS does as well, but nowhere near as good, IMHO. But that's a different topic all-together. ;P ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Tue Jun 30 09:34:47 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA30800; Tue, 30 Jun 1998 09:34:44 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA31659; Tue, 30 Jun 1998 09:18:59 -0700 Resent-Date: Tue, 30 Jun 1998 09:18:59 -0700 Date: Tue, 30 Jun 1998 09:10:38 -0700 (PDT) From: KC5TJA To: Emmanuel Marty cc: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: <3599084F.846F8281@suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"O3--c1.0.Vk7.n_Gcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3201 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 30 Jun 1998, Emmanuel Marty wrote: > Actually AmigaOS doesn't either, "kernel-wise", as you mean it. The > shell does. Not according to my AmigaDOS Programmers Reference Manual. There are tons of dos.library functions that rely on the existance of a 'current device' if one isn't specified explicitly, and also a 'current directory' too. The dos.library Execute() function, for instance, or even Open(). ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Tue Jun 30 09:38:34 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA30811; Tue, 30 Jun 1998 09:38:30 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA00845; Tue, 30 Jun 1998 09:22:52 -0700 Resent-Date: Tue, 30 Jun 1998 09:22:52 -0700 Date: Tue, 30 Jun 1998 09:14:21 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Degas Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"N8wbR1.0.yC.O3Hcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3202 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com When will the CVS trees for degas be finished and made "stable"? I tried re-building libggi, with absolutely no success. It compiles fine, but it does not install all necessary include files. Then, after I hand-copy them to /usr/local/include/ggi, I find that GGI applications (*ALL* of them) report that "libggi.so.1: Cannot open shared object file: No such file or directory". Does ANYONE have any ideas as to why this is happening? I think I can get my copy to work once I figure out just what the heck that means! Thanks for the assistance. I'm using Debian Hamm 2.0 distribution. All I want to do is compile libGGI on my computer -- I want nothing else. For targets, I'm compiling X, Xlib, X DGA, multi, tile, and trueemu. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Tue Jun 30 09:42:26 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA30823; Tue, 30 Jun 1998 09:42:20 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA06496; Tue, 30 Jun 1998 09:37:44 -0700 Resent-Date: Tue, 30 Jun 1998 09:37:44 -0700 Date: Tue, 30 Jun 1998 12:36:43 -0400 (EDT) From: Steve Cheng Sender: steve@maxt1m08.ipoline.com To: ggi-develop@eskimo.com Subject: Re: ggiGetc or ggiGetkey? In-Reply-To: <3598F24D.C1D85177@e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"TvBHF2.0.9a1.GHHcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3204 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 30 Jun 1998, Marcus Sundberg wrote: > And now we have moved to EvStack, so we better do something > about it! Sorry for this stupid question, but how exactly is it supposed to work? What was the old "U(x)" business supposed to do anyway? I used to hack event handling in the targets to what I _thought_ it was, but I want a definite answer now. (Yes, I want a totally-for-idiots explanation, on everything from the fields of ggi_key_event to the proper way to handle every conceivable case. We need this for the docs anyway. I hope that isn't too much to ask for :) -- Steve Cheng email: steve@ggi-project.org www: From ggi-develop-request@eskimo.com Tue Jun 30 09:52:34 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA30834; Tue, 30 Jun 1998 09:52:31 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id JAA14084; Tue, 30 Jun 1998 09:28:40 -0700 (PDT) Resent-Date: Tue, 30 Jun 1998 09:28:40 -0700 (PDT) To: ggi-develop@eskimo.com Subject: ggi Debian packages From: Falk Hueffner Date: 30 Jun 1998 18:25:46 +0200 Message-Id: Lines: 31 X-Mailer: Quassia Gnus v0.37/XEmacs 20.3 - "Vatican City" Resent-Message-ID: <"aca5R2.0.sR3.r8Hcr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3203 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi, I've tried the Debian packages from ggi-stable_980619 created by Charles Briscoe-Smith, and I must say I'm very happy these things are now available, since it saves me quite some time in compiling and installing. Thanks Charles! I've noticed some small problems, though ;) - I can't seem to get any program with aalib to work. Which should work? - The libggi doc says: ggi_pixel ggiMapColor(ggi_visual_t vis, ggi_color * col); Gets the pixelvalue for the given color. Return: 0 for OK, otherwise an error code. but it seems to me that it returns the pixel and not an error code. (I read without thinking and triggered a panic if the result is != 0, and I really wondered how this function cold fail). - There's complete doc for libggi2d, and it seems nice, but where is it? Is it not yet implemented, or is it just me not #incuding the right header? Falk From ggi-develop-request@eskimo.com Tue Jun 30 10:10:29 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA30862; Tue, 30 Jun 1998 10:10:27 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id JAA14075; Tue, 30 Jun 1998 09:58:03 -0700 Resent-Date: Tue, 30 Jun 1998 09:58:03 -0700 Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <3599192C.5D8BD00F@e.kth.se> Date: Tue, 30 Jun 1998 18:58:20 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Degas References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"foT451.0.lR3.QaHcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3205 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com KC5TJA wrote: > > When will the CVS trees for degas be finished and made "stable"? I tried > re-building libggi, with absolutely no success. It compiles fine, but it > does not install all necessary include files. Then, after I hand-copy > them to /usr/local/include/ggi, I find that GGI applications (*ALL* of > them) report that "libggi.so.1: Cannot open shared object file: No such > file or directory". Does ANYONE have any ideas as to why this is > happening? I think I can get my copy to work once I figure out just what > the heck that means! > > Thanks for the assistance. > > I'm using Debian Hamm 2.0 distribution. All I want to do is compile > libGGI on my computer -- I want nothing else. For targets, I'm compiling > X, Xlib, X DGA, multi, tile, and trueemu. The "Devel" CVS tree works fine for me right know. The "Stable" CVS tree will work fine from 1 July and until forever. The only flaw regarding installation is that degas/include/ggi/* files are not installed with libggi. I'll fix that tonight when I get to a computer which isn't behind a firewall... As for the libggi.so.1 error you have either: * Not installed libggi * Not run ldconfig * A broken system... //Marcus From ggi-develop-request@eskimo.com Tue Jun 30 10:12:56 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA30867; Tue, 30 Jun 1998 10:12:54 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id KAA18339; Tue, 30 Jun 1998 10:15:46 -0700 (PDT) Resent-Date: Tue, 30 Jun 1998 10:15:46 -0700 (PDT) Sender: Marcus.Sundberg@ebc.ericsson.se Message-ID: <35991CC1.963FACC6@e.kth.se> Date: Tue, 30 Jun 1998 19:13:37 +0200 From: Marcus Sundberg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: ggiGetc or ggiGetkey? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"CIYWv3.0.MU4.yqHcr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3206 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Steve Cheng wrote: > > On Tue, 30 Jun 1998, Marcus Sundberg wrote: > > > And now we have moved to EvStack, so we better do something > > about it! > > Sorry for this stupid question, but how exactly is it supposed to work? > What was the old "U(x)" business supposed to do anyway? I used to hack > event handling in the targets to what I _thought_ it was, but I want a > definite answer now. > > (Yes, I want a totally-for-idiots explanation, on everything from the fields > of ggi_key_event to the proper way to handle every conceivable case. We > need this for the docs anyway. I hope that isn't too much to ask for :) That's not a stupid quastion at all! As with most libggi related issues most of the work is actually defining a documented behaviour. The implementation will then be very simple. //Marcus From ggi-develop-request@eskimo.com Tue Jun 30 10:39:27 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA30899; Tue, 30 Jun 1998 10:39:25 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA31191; Tue, 30 Jun 1998 10:34:06 -0700 Resent-Date: Tue, 30 Jun 1998 10:34:06 -0700 Sender: core@orb.suntech.fr Message-ID: <35992109.D42CC707@suntech.fr> Date: Tue, 30 Jun 1998 17:31:53 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"yaK5w3.0.Ed7.C6Icr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3207 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com s/current\ console/fg_console/ -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 30 10:41:57 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA30906; Tue, 30 Jun 1998 10:41:53 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA00292; Tue, 30 Jun 1998 10:37:14 -0700 Resent-Date: Tue, 30 Jun 1998 10:37:14 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: display-tile? To: ggi-develop@eskimo.com Date: Tue, 30 Jun 1998 07:36:50 +0200 (MET DST) In-Reply-To: <199806291616.SAA07366@cip8.e-technik.uni-erlangen.de> from "Hartmut Niemann" at Jun 29, 98 06:16:54 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"b_oEY1.0.X3.59Icr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3209 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > I tried my first libggi build from the develcvs today. > > Where is the tile target? Is it usable? Yes. Just enable it by editing .config. Or better: patch the config system to include it. > And I'm going to hunt the bug in ggiCIrcle ... Which Bug ? CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 30 10:42:00 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA30910; Tue, 30 Jun 1998 10:41:57 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA32697; Tue, 30 Jun 1998 10:36:42 -0700 Resent-Date: Tue, 30 Jun 1998 10:36:42 -0700 Sender: core@orb.suntech.fr Message-ID: <359921AE.5A23ABFB@suntech.fr> Date: Tue, 30 Jun 1998 17:34:38 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge References: <359920C9.248CBCF8@suntech.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"R03by2.0.S-7.f8Icr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3208 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com KC5TJA wrote: > Not according to my AmigaDOS Programmers Reference Manual. There are > tons of dos.library functions that rely on the existance of a 'current > device' if one isn't specified explicitly, and also a 'current directory' > too. The dos.library Execute() function, for instance, or even Open(). Yes, there is a current directory, like under *nix ; this is a per-task thing, not a global system setting, like the 'current console' under linux; that's where I think we aren't talking about the same thing .. About having a 'current framebuffer', this doesn't make much sense, as a framebuffer is obviously associated to the console you are rendering to; so, you convert the current console to current framebuffer and render there - until fbcon supports multiple heads, not much choice but to do what Geert did.. -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 30 10:42:38 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA30917; Tue, 30 Jun 1998 10:42:36 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA00337; Tue, 30 Jun 1998 10:37:20 -0700 Resent-Date: Tue, 30 Jun 1998 10:37:20 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: fbcon-KGI bridge To: ggi-develop@eskimo.com Date: Tue, 30 Jun 1998 18:53:30 +0200 (MET DST) In-Reply-To: from "Geert Uytterhoeven" at Jun 29, 98 06:03:39 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"HG7vH3.0.r4.B9Icr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3210 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > So we just have to check for conflicts (do the fbmem-internal ioctls have > > some magic number or similar, so we can avoid conflicts for all future > > releases beforehand, too ?) and we are done ? Great ! > > The current ioctls are: > > #define FBIOGET_VSCREENINFO 0x4600 > #define FBIOPUT_VSCREENINFO 0x4601 > #define FBIOGET_FSCREENINFO 0x4602 > #define FBIOGETCMAP 0x4604 > #define FBIOPUTCMAP 0x4605 > #define FBIOPAN_DISPLAY 0x4606 > /* 0x4607-0x460B are defined below */ > /* #define FBIOGET_MONITORSPEC 0x460C */ > /* #define FBIOPUT_MONITORSPEC 0x460D */ > /* #define FBIOSWITCH_MONIBIT 0x460E */ > #define FBIOGET_CON2FBMAP 0x460F > #define FBIOPUT_CON2FBMAP 0x4610 So you actually have 0x4600 ("F") as your magic. This is fine with us, as it ensures we will not clash until we define subsystem 0x46. We use the encoding proposed in asm/ioctl.h which makes the bits 8-15 define the subsystem we are accessing. Even if fbcon changes to this scheme fully, too (this is very nice, because you can do copying of user-mode-memory in a central place), we will not conflict. GGI subsystems are yet defined up to 0x07 and 0xff for a broadcast, so we will nicely coexist with fbcon. > These do not comply (yet) to the `standard ioctl scheme'. If you need help with that, just ask. We've been using it for quite some time now. It really simplifies things for KGI. CU, Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 30 10:42:39 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA30918; Tue, 30 Jun 1998 10:42:36 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA00720; Tue, 30 Jun 1998 10:38:07 -0700 Resent-Date: Tue, 30 Jun 1998 10:38:07 -0700 Date: Tue, 30 Jun 1998 10:48:59 -0700 (MST) From: teunis Reply-To: teunis To: GGI Developers Subject: fbcon / KGI / ... (?) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"JrYSH2.0.oA.v9Icr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3211 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com So - _is_ there a 2.1 kernel I can develop the S3-ViRGE stuff on (I haven't gotten any kernel to work yet) or should I wait for decision on the fbcons/KGI issue to be resolved? Incidentally I agree with going with fbcons for now and upgrading it over time to KGI/EvStacks[GGI Console] *grin*.... [if there's some way to incorporate a series of running patches/upgrades, noone on linux may even notice anything unusual :] One thing I noticed with EvStacks as of 2.1.8x was that all existing software (except gpm) worked fine - it was just the GGI stuff that didn't work yet.... if that helps arguments any? Mayhaps: GGI Console -> find a way to upgrade fbcons to GGI/Console; libGGI -> seems to be good :) : GGI input - please shouldn't this be started soon? : GGI 2D - this due anytime soon? GGI drivers / KGI -> make an fbcons mapping for now.... [let us minions know, hey? Need to know what's going on before working with drivers again] I'm still fussing with the tools to build my own libGGI3D varient - don't ask beyond that the tools are 95% operational *grin* (needed a real multithreaded debugger and scripting tool - I don't know perl well enough and I -definitely- don't have a decent debugger for Linux. Too used to DOS-style platforms with interactive debuggers) Incidentally, as soon as I get this monster up and running I'll start working on getting libGGI thread-safe *giggle*.... G'day, eh? :) - Teunis From ggi-develop-request@eskimo.com Tue Jun 30 10:45:06 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA30928; Tue, 30 Jun 1998 10:45:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA00786; Tue, 30 Jun 1998 10:38:16 -0700 Resent-Date: Tue, 30 Jun 1998 10:38:16 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: GGI Compilation Bug To: ggi-develop@eskimo.com Date: Tue, 30 Jun 1998 19:25:10 +0200 (MET DST) In-Reply-To: from "KC5TJA" at Jun 29, 98 09:03:27 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"GS0ZD2.0.QB.z9Icr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3212 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi ! > > It will be copied to the stable tree on the 1st of July. > > Problem: all I want is libGGI. I was told by a number of people to CVS > the tree, switch into lib/libggi, make config, and make. Unfortunately, > out of the box, it does not work. I had to finesse it a bit. > Specifically, I had to cp -R ../../include/* ./include in the libGGI > directory before ANYTHING would compile. Yes - very sorry about that - though ... actually it _should_ compile without ... -I paths are set ... > And then there's those execute permissions... :) Sorry - that's some problem with the anoncvs repository. > After I got everything compiled, NOW it's telling me that libggi.so.1 > cannot be opened, Did you "make install" ? > or it cannot open a file -- the error message in ambiguous. > I have yet to figure out why this is. What would I do to debug this? Two primary tricks for that : 1. set LIBGGI_DEBUG=255. This will make LibGGI spit quite some debugging output. 2. use strace to see what fails. I case you can't make sense from the output, just send us both traces and we will check what is wrong. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 30 11:04:03 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA30950; Tue, 30 Jun 1998 11:04:01 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id KAA09319; Tue, 30 Jun 1998 10:59:27 -0700 Resent-Date: Tue, 30 Jun 1998 10:59:27 -0700 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Last chance to get things in ... To: ggi-develop@eskimo.com (mailing list GGI) Date: Tue, 30 Jun 1998 19:58:01 +0200 (MET DST) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"VUYWz1.0.KH2.yTIcr"@mx1> Resent-From: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3213 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi folks ! I'll probably take the devel snapshot tonight, check it thoroughly and then move it over to the stable tree. So if you have bugfixes pending, please commit them _NOW_. CU,Andy -- = Andreas Beck | Email : = From ggi-develop-request@eskimo.com Tue Jun 30 11:24:53 1998 Return-Path: Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA30960; Tue, 30 Jun 1998 11:24:48 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA17054; Tue, 30 Jun 1998 11:20:16 -0700 Resent-Date: Tue, 30 Jun 1998 11:20:16 -0700 From: fwmiller@cs.umd.edu (Frank W. Miller) Message-Id: <199806301820.OAA29531@yangtze.cs.umd.edu> Subject: Porting GGI to a new operating system To: ggi-develop@eskimo.com Date: Tue, 30 Jun 1998 14:20:14 -0400 (EDT) Cc: fwmiller@cs.umd.edu (Frank W. Miller) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"UDxRV2.0.GA4.VnIcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3214 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Greetings, I don't know if this is the right list for this or even if there is a right list for this but I'd like to ask a few questions about porting GGI to a new operating system. First, is it possible, if so how much effort would it take? I guess this boils down to how much dependency is there on the underlying OS APIs and is this code compartmentalized? I would need some low level device support, for which I would probably use SVGAlib. Which version should I use, yours? How hard is that to port? The OS I am porting to is commercial, what are the licensing implications? Many thanks and sorry if this is off topic. BTW info on the OS is available at http://www.cs.umd.edu/~fwmiller/roadrunner Later, FM -- Frank W. Miller Department of Computer Science fwmiller@cs.umd.edu University of Maryland http://www.cs.umd.edu/~fwmiller College Park, Maryland 20742 From ggi-develop-request@eskimo.com Tue Jun 30 11:25:04 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA30965; Tue, 30 Jun 1998 11:24:58 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA17291; Tue, 30 Jun 1998 11:21:52 -0700 Resent-Date: Tue, 30 Jun 1998 11:21:52 -0700 Date: Tue, 30 Jun 1998 11:13:44 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: Degas In-Reply-To: <3599192C.5D8BD00F@e.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"33J173.0.2E4.0pIcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3215 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > As for the libggi.so.1 error you have either: > * Not installed libggi > * Not run ldconfig > * A broken system... Well, I have installed libggi (I'll give you a shell account if you'd like to verify this), and I have run ldconfig 17 times since I first started the installation about two days ago (moving files here and there, running ldconfig, seeing if that worked, if not, repeat process). This means, then, that Debian is a broken system by your logic. Yet, I've seen plenty of other claims to the contrary on this very list. Therefore, I doubt I have a broken system. THUS, I have only to conclude that there is a bug in libggi.so somewhere. Before we jump to such conclusions, though, what are the factors that affect ld.so's ability to load shared object files? Give me **EVERYTHING** that affects this ability; don't just tell me to re-run ldconfig, because that obviously isn't working. Once again, thanks in advance for the assistance. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Tue Jun 30 11:27:54 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA30970; Tue, 30 Jun 1998 11:27:40 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA17644; Tue, 30 Jun 1998 11:23:35 -0700 Resent-Date: Tue, 30 Jun 1998 11:23:35 -0700 Date: Tue, 30 Jun 1998 11:15:22 -0700 (PDT) From: KC5TJA To: Emmanuel Marty cc: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge In-Reply-To: <359920C9.248CBCF8@suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"TC5QM1.0.aJ4.cqIcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3216 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > About having a 'current framebuffer', this doesn't make much sense, as a > framebuffer > is obviously associated to the console you are rendering to; so, you convert > the current console to current framebuffer and render there - until fbcon > supports > multiple heads, not much choice but to do what Geert did.. So in any Linux system, /dev/fb0 refers to an entire MONITOR/CARD pair, rather than a "virtual" console? If this is the case, then that would make much sense. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Tue Jun 30 11:34:06 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA30980; Tue, 30 Jun 1998 11:34:02 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id LAA18324; Tue, 30 Jun 1998 11:26:14 -0700 Resent-Date: Tue, 30 Jun 1998 11:26:14 -0700 Date: Tue, 30 Jun 1998 11:17:57 -0700 (PDT) From: KC5TJA To: andreas.beck@ggi-project.org cc: ggi-develop@eskimo.com Subject: Re: GGI Compilation Bug In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"GJeMK3.0.AU4.4tIcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3217 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > After I got everything compiled, NOW it's telling me that libggi.so.1 > > cannot be opened, > > Did you "make install" ? Thrice. > Two primary tricks for that : > > 1. set LIBGGI_DEBUG=255. This will make LibGGI spit quite some debugging > output. > > 2. use strace to see what fails. Hmmm...never thought of that... > I case you can't make sense from the output, just send us both traces and > we will check what is wrong. I'll do that later tonight. Thanks! ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Tue Jun 30 12:09:04 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31141; Tue, 30 Jun 1998 12:09:00 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA03890; Tue, 30 Jun 1998 12:04:18 -0700 Resent-Date: Tue, 30 Jun 1998 12:04:18 -0700 Sender: core@orb.suntech.fr Message-ID: <35993623.BFD17E2@suntech.fr> Date: Tue, 30 Jun 1998 19:01:55 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: fbcon-KGI bridge References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"2d4AU3.0.Fy.kQJcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3220 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com KC5TJA wrote: > So in any Linux system, /dev/fb0 refers to an entire MONITOR/CARD pair, > rather than a "virtual" console? If this is the case, then that would > make much sense. That's right. I admit, it's a bit cumbersome when looked from outside, but what isn't, in a kernel formed of 10 megs of source in a low-level language, statically linked together for the most part :) -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 30 12:11:17 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31146; Tue, 30 Jun 1998 12:11:12 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA04832; Tue, 30 Jun 1998 12:13:00 -0700 (PDT) Resent-Date: Tue, 30 Jun 1998 12:13:00 -0700 (PDT) Date: Tue, 30 Jun 1998 12:02:07 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: Degas In-Reply-To: <35993342.1F07A3D1@suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"VuOMJ3.0.LB1.sYJcr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3222 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com On Tue, 30 Jun 1998, Emmanuel Marty wrote: > Well, I'm afraid of saying something really basic but - IIRC libggi installs > itself in /usr/local/lib by default. Make sure you have that in the searchpath > > for ld.so, in /etc/ld.so.conf ; that will at least rule that out.. That did the trick. Now it's reporting that it "can't open default visual," but that's to be expected: not much of a visual can be opened over Telnet.... :-) Thanks a bunch for everyone's help. Next time this occurs on a system, I'll be sure to remember this "trick" of common sense... :) (*kicks* himself in the rear for not thinking of this sooner) ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Tue Jun 30 12:11:58 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31151; Tue, 30 Jun 1998 12:11:54 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA02562; Tue, 30 Jun 1998 12:00:57 -0700 Resent-Date: Tue, 30 Jun 1998 12:00:57 -0700 Sender: core@orb.suntech.fr Message-ID: <35993561.DC5D318C@suntech.fr> Date: Tue, 30 Jun 1998 18:58:41 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Porting GGI to a new operating system References: <199806301820.OAA29531@yangtze.cs.umd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Njomc3.0.ud.dNJcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3219 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi Frank, First, I did hear about RoadRunner, there is even some machine running it online iirc, I never managed to connect to it tho :) But I'd be curious to. > I don't know if this is the right list for this or even if there is > a right list for this but I'd like to ask a few questions about porting > GGI to a new operating system. Well, this is the GGI development list - that's the right place. > First, is it possible, if so how much effort would it take? I guess > this boils down to how much dependency is there on the underlying > OS APIs and is this code compartmentalized? It depends what you want to port: * libggi: the application front-end. If RoadRunner supports shared libraries or a similar mechanism, and uses a fairly standard C compiler (gcc would be best), then it should be rather easy. libggi runs on most *nix flavors already, and will begin its career on win32 soon. * kgi device drivers : the kernel-level display drivers which actually talk to the display board - this shouldn't be too hard either, since all system-dependent code is supposed to be in the KGI manager - however it has never been tried, and there are a couple of things in the driver (such as pci device lookup) that use direct linux kernel calls - should be trivial to fix though.. * kgi manager/multihead console - that will be the hard bit, it's got to be rewritten for RoadRunner, however, you won't need it probably - all you need is libggi, the kgi drivers and to write some code in your kernel to make them communicate. > I would need some low level device support, for which I would probably > use SVGAlib. Which version should I use, yours? How hard is that > to port? You can use the KGI drivers, they support boards that svgalib doesn't, and as I said, shouldn't be hard to port. > The OS I am porting to is commercial, what are the licensing > implications? libggi is LGPL, the KGI drivers are GPL. Provided that you put under GPL anything you link to the KGI drivers (to the exception of kernel modules, if there is such a thing under roadrunner), that you redistribute the sources of the whole GPL part, and that you provide libggi either in shared library form, or if nothing like that is available, as the a relinkable object, nothing should get in your way. The GPL bit might be a pain though.. > Many thanks and sorry if this is off topic. BTW info on the OS is > available at http://www.cs.umd.edu/~fwmiller/roadrunner Yup, I've been there a couple of times .. Good luck with your project, and be sure to ask for any information here. -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 30 12:12:20 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31156; Tue, 30 Jun 1998 12:12:16 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA03929; Tue, 30 Jun 1998 12:09:32 -0700 (PDT) Resent-Date: Tue, 30 Jun 1998 12:09:32 -0700 (PDT) Date: Tue, 30 Jun 1998 11:58:43 -0700 (PDT) From: KC5TJA To: ggi-develop@eskimo.com Subject: Re: Degas In-Reply-To: <35993342.1F07A3D1@suntech.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"-X0eo2.0.7z.XVJcr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3221 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Well, I'm afraid of saying something really basic but - IIRC libggi installs > itself in /usr/local/lib by default. Make sure you have that in the searchpath > > for ld.so, in /etc/ld.so.conf ; that will at least rule that out.. Thanks for the tip; I will look into this as soon as I get some free time. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net From ggi-develop-request@eskimo.com Tue Jun 30 12:14:53 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31163; Tue, 30 Jun 1998 12:14:14 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA06707; Tue, 30 Jun 1998 12:12:14 -0700 Resent-Date: Tue, 30 Jun 1998 12:12:14 -0700 Sender: core@orb.suntech.fr Message-ID: <35993805.7FAAB872@suntech.fr> Date: Tue, 30 Jun 1998 19:09:57 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Degas References: <3599192C.5D8BD00F@e.kth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"jhD7P3.0.Ye1.8YJcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3223 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > The only flaw regarding installation is that > degas/include/ggi/* files are not installed with > libggi. I'll fix that tonight when I get to a > computer which isn't behind a firewall... Marcus, is there any port that goes through your firewall, and doesn't conflict with standard services, that you'd want me to run the cvs server on as well? If it can be useful for you, just let me know. Sidenotes : There is more bandwidth for the repository since this afternoon. It should be at least a bit faster, if not sensibly (if the problems arise on the upstreams). It won't hurt anyway. There will be an interruption of service for the CVS server, for about 5 hours, sometime between july 10 and july 20; I'll warn about it 24 hours earlier. The exact day depends on telecom, so it might even be later - I certainly hope not. The server will physically be migrating. When the interruption is over, network problems will only be something we will remember with a nostalgic smile :) -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 30 12:18:57 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31168; Tue, 30 Jun 1998 12:18:52 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id LAA02728; Tue, 30 Jun 1998 11:59:05 -0700 (PDT) Resent-Date: Tue, 30 Jun 1998 11:59:05 -0700 (PDT) Sender: core@orb.suntech.fr Message-ID: <35993342.1F07A3D1@suntech.fr> Date: Tue, 30 Jun 1998 18:49:38 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Degas References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"VWajy.0.Sg.tLJcr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3218 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com KC5TJA wrote: > Before we jump to such conclusions, though, what are the factors that > affect ld.so's ability to load shared object files? Give me > **EVERYTHING** that affects this ability; don't just tell me to re-run > ldconfig, because that obviously isn't working. Well, I'm afraid of saying something really basic but - IIRC libggi installs itself in /usr/local/lib by default. Make sure you have that in the searchpath for ld.so, in /etc/ld.so.conf ; that will at least rule that out.. -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 30 12:25:36 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31173; Tue, 30 Jun 1998 12:25:32 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA12470; Tue, 30 Jun 1998 12:22:02 -0700 Resent-Date: Tue, 30 Jun 1998 12:22:02 -0700 Sender: thomas@eskimo.com Message-ID: <35993749.9C1CBBD6@gmx.de> Date: Tue, 30 Jun 1998 21:06:49 +0200 From: Thomas Tanner X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: ggi Debian packages References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hP7oe2.0.f23.NhJcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3225 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Falk Hueffner wrote: > - There's complete doc for libggi2d, and it seems nice, but where is > it? Is it not yet implemented, or is it just me not #incuding the > right header? It was not commited to the stable tree yet and the version in the devel tree is not working. You can download a working snapshot from http://home.pages.de/~tanner/files/libggi2d.tar.gz (unpack it to /lib) -- Thomas Tanner ----------------------------- email: tanner@gmx.de tanner@ggi-project.org web: http://home.pages.de/~tanner GGI: http://www.ggi-project.org From ggi-develop-request@eskimo.com Tue Jun 30 12:27:08 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31180; Tue, 30 Jun 1998 12:27:06 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA10796; Tue, 30 Jun 1998 12:17:40 -0700 Resent-Date: Tue, 30 Jun 1998 12:17:40 -0700 Sender: core@orb.suntech.fr Message-ID: <3599394E.C1D20EED@suntech.fr> Date: Tue, 30 Jun 1998 19:15:26 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Degas References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"bWV2m1.0.yd2.GdJcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3224 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com KC5TJA wrote: > That did the trick. Now it's reporting that it "can't open default > visual," but that's to be expected: not much of a visual can be opened > over Telnet.... :-) Ahh.. Good to know it works now. I would hardly have believed a 'bug in libggi.so' would make it fail to be found by the dynamic loader - we aren't _that_ good (yet) :) Maybe make install should grep /etc/ld.so.conf when under linux just to make sure the path it is installing to is there, before doing the ldconfig? It will save Debian users a lot of trouble - I remember now that it doesn't do that by default, while RH does; I forgot about this because I add that without even thinking about it every time I install a new host from my favorite distro.. -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 30 12:28:19 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31185; Tue, 30 Jun 1998 12:28:17 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA13565; Tue, 30 Jun 1998 12:24:26 -0700 Resent-Date: Tue, 30 Jun 1998 12:24:26 -0700 Sender: core@orb.suntech.fr Message-ID: <35993AD4.BE020B7A@suntech.fr> Date: Tue, 30 Jun 1998 19:21:56 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: CVS news Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"76LBb.0.rI3.XjJcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3226 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Hi all, Three good news about our CVS repositories : 1) Sometime between July 10 and July 20, the machine hosting the CVS repository will be moved to our new access point ; as soon as the links are physically up. Bandwidth should be a little higher, but above that, network will run much smoother. Our NAP partner, ISDnet, is really doing well, and will be linking to the new monaco exchanger, putting degas.ggi-project.org two hops from miami and singapore, in addition to the existing direct links to esplanade3000 to new york; unisource to washington and europe, etc. 2) Jason Gunthorpe of Debian, is going to setup an anonymous CVS repository mirror for GGI in the USA. That'll relieve Todd a bit.. Manyt thanks to the Debian people who really _do_ things for the community, as always. 3) Lysator is going to setup an european anonymous CVS repository mirror, 34 mbits and one hop from D-GUX (the huge stockholm exchanger). Just wanted to keep you updated.. -- Emmanuel From ggi-develop-request@eskimo.com Tue Jun 30 12:37:28 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31190; Tue, 30 Jun 1998 12:37:18 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA17806; Tue, 30 Jun 1998 12:33:01 -0700 Resent-Date: Tue, 30 Jun 1998 12:33:01 -0700 Message-Id: <199806301932.VAA08609@stockholm.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: ggi-develop@eskimo.com cc: fwmiller@cs.umd.edu (Frank W. Miller) Subject: Re: Porting GGI to a new operating system In-reply-to: Your message of "Tue, 30 Jun 1998 14:20:14 EDT." <199806301820.OAA29531@yangtze.cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 21:32:35 +0200 From: Marcus Sundberg Resent-Message-ID: <"2_9G21.0.qL4.grJcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3227 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Greetings, > > I don't know if this is the right list for this or even if there is > a right list for this but I'd like to ask a few questions about porting > GGI to a new operating system. > > First, is it possible, if so how much effort would it take? I guess > this boils down to how much dependency is there on the underlying > OS APIs and is this code compartmentalized? This depends very much on which part of GGI you want to port. GGI currently consists of four main parts: * The GGI Console (former EvStack) - A console and inputmanagement system with advanced features for multihead. * KGI - an interface between hardware drivers and the OS * A bunch of Gfx-board drivers for KGI. * libggi - a userlevel API library which lets the same program run on a variety of OSes, hardware and displays The hardware drivers and KGI should be pretty easy to port. The GGI Console I have no idea about... Libggi should run on any system with an ANSI C compiler and dynamic loading of libraries with very little porting. > I would need some low level device support, for which I would probably > use SVGAlib. Which version should I use, yours? How hard is that > to port? Our version of SVGAlib runs on _top_ of libggi, and is as far from lowlevel you get. I suggest you use KGI as the lowlevel interface, which will make all our gfx-drivers available to you once you've ported KGI to your OS (and we've changed our licensing, see below) > The OS I am porting to is commercial, what are the licensing > implications? We're currently discussing licensing issues for GGI. GGI Console, most Gfx-board drivers and KGI are currently under the GNU General Public Licence (GPL), so unless you release roadrunner with sourcecode under the GPL you can not use any code from them right now. But the new licensing we're working on will NOT be GPL for these parts of GGI. Most certainly you will be allowed to use this code for your commercial OS without having to release any source, you'll just have to wait until we have the new licence ready. Libggi on the other hand is under the GNU Library General Public license (LGPL) and will probably remain so. LGPL basicly states: * If you change libggi _itself_ or make additions to it you have to release the changes under LGPL with source. * If you only link code with libggi you must provide source- OR object-code for your code, but your code can have any licensing you wish. Thus there's no problem with using libggi for commercial OSes or applications. > Many thanks and sorry if this is off topic. BTW info on the OS is > available at http://www.cs.umd.edu/~fwmiller/roadrunner People wanting to port GGI to other platforms are never off-topic. We'll try to give you all the help you need. //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Tue Jun 30 12:43:01 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31207; Tue, 30 Jun 1998 12:42:56 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA21451; Tue, 30 Jun 1998 12:40:55 -0700 Resent-Date: Tue, 30 Jun 1998 12:40:55 -0700 Message-Id: <199806301940.VAA09083@stockholm.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: ggi-develop@eskimo.com Subject: Re: Degas In-reply-to: Your message of "Tue, 30 Jun 1998 19:09:57 -0000." <35993805.7FAAB872@suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 21:40:36 +0200 From: Marcus Sundberg Resent-Message-ID: <"k0u_X3.0.0F5.4zJcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3229 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > The only flaw regarding installation is that > > degas/include/ggi/* files are not installed with > > libggi. I'll fix that tonight when I get to a > > computer which isn't behind a firewall... > > Marcus, is there any port that goes through your firewall, > and doesn't conflict with standard services, that you'd want > me to run the cvs server on as well? If it can be useful > for you, just let me know. Unfortunately the only way through the firewall is via http or ftp proxy, so unless you know of a way to tunnel cvs through the http or ftp protocol there's nothing to do about it. ;-) But it wouldn't be of much use anyway as the connection to the outside world at work is severely overloaded during daytime. FTP transfer rates are typically 10-20kbps. (And I do mean bits, not bytes...) //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Tue Jun 30 12:47:44 1998 Return-Path: Received: from mx2.eskimo.com (smartlst@mx2.eskimo.com [204.122.16.49]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31212; Tue, 30 Jun 1998 12:47:41 -0700 Received: (from smartlst@localhost) by mx2.eskimo.com (8.8.8/8.8.8) id MAA09996; Tue, 30 Jun 1998 12:42:07 -0700 (PDT) Resent-Date: Tue, 30 Jun 1998 12:42:07 -0700 (PDT) From: fwmiller@cs.umd.edu (Frank W. Miller) Message-Id: <199806301934.PAA29630@yangtze.cs.umd.edu> Subject: Re: Porting GGI to a new operating system To: ggi-develop@eskimo.com Date: Tue, 30 Jun 1998 15:34:44 -0400 (EDT) Cc: fwmiller@cs.umd.edu (Frank W. Miller) In-Reply-To: <35993561.DC5D318C@suntech.fr> from "Emmanuel Marty" at Jun 30, 98 06:58:41 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_VItT3.0.0S2.D-Jcr"@mx2> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3228 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > > First, I did hear about RoadRunner, there is even some machine running > it online iirc, I never managed to connect to it tho :) But I'd be curious > to. > Whats iirc? Sorry about the machine being down. Its actually quite stable but once in a while someone logs in and brings it down. The machine is at school so I cat reboot it til I get there the next morning. Actually, I've had the box offline the last week or so, have been making a major change to the internal file system implementations. > * libggi: the application front-end. If RoadRunner supports shared > libraries or a similar mechanism, and uses a fairly standard C compiler > (gcc would be best) I actually would like to modify the user's few of the graphics system. The point of the Roadrunner I/O system is to allow true zero-copy streaming between devices. This requires some changes to the normal way of doing buffering and the API. I would probably try to encapsulate the libGGI function under a GGI file system API. > * kgi device drivers : the kernel-level display drivers which actually talk > to the display board - this shouldn't be too hard either, since all > system-dependent > code is supposed to be in the KGI manager - however it has never been tried, > I will look at this. I actually have a similar issue at the device level. Again, in order to facilitate true zero-copy streaming, the device API is different (a little, not too much). > > * kgi manager/multihead console - that will be the hard bit, it's got to be > rewritten for Not sure what this is, window manager? I actually do need something like this. The point of using GGI is to allow me to write a simple windowing system quickly. > You can use the KGI drivers, they support boards that svgalib doesn't, and as > I said, shouldn't be hard to port. Groovy! > libggi is LGPL Whats's LGPL, I know about GPL but not LGPL. > The GPL bit might be a pain though.. > Shouldnt be too bad, I plan to release source, at least to the alpha customers... I do wish it was more BSDish... Thanks for the tips!! Later, FM -- Frank W. Miller Department of Computer Science fwmiller@cs.umd.edu University of Maryland http://www.cs.umd.edu/~fwmiller College Park, Maryland 20742 From ggi-develop-request@eskimo.com Tue Jun 30 12:48:16 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31217; Tue, 30 Jun 1998 12:48:13 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA23151; Tue, 30 Jun 1998 12:43:14 -0700 Resent-Date: Tue, 30 Jun 1998 12:43:14 -0700 Sender: thomas@eskimo.com Message-ID: <35993A9A.452615A@gmx.de> Date: Tue, 30 Jun 1998 21:20:59 +0200 From: Thomas Tanner X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Future of GGI project References: <3594D413.17546C54@vertech.no> <3597C146.1DA62292@gmx.de> <359835B5.CB8EAD63@vertech.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"q1Jmd1.0.9f5.E_Jcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3230 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Torgeir Veimo wrote: > > I've collected my ideas and have written a specification for this new design, > > which is, however, quite incompatible with the current "design". > > Specificiation and snapshot can be obtained from > > http://home.pages.de/~tanner/ggi.html#design > Is it impossible to have a libGGI compatible api implemented using such > a library <-> kgi interaction framework? Well, it would be theoretically possible to make a emulation wrapper for the old libggi API, but there would be some symbol conflicts etc., i.e not binary compatibility. -- Thomas Tanner ----------------------------- email: tanner@gmx.de tanner@ggi-project.org web: http://home.pages.de/~tanner GGI: http://www.ggi-project.org From ggi-develop-request@eskimo.com Tue Jun 30 12:55:32 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA31235; Tue, 30 Jun 1998 12:55:28 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA27735; Tue, 30 Jun 1998 12:50:26 -0700 Resent-Date: Tue, 30 Jun 1998 12:50:26 -0700 Message-Id: <199806301949.VAA09101@stockholm.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: ggi-develop@eskimo.com Subject: Re: CVS news In-reply-to: Your message of "Tue, 30 Jun 1998 19:21:56 -0000." <35993AD4.BE020B7A@suntech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 21:49:57 +0200 From: Marcus Sundberg Resent-Message-ID: <"YJfLD1.0.Qm6.-5Kcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3231 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > 3) Lysator is going to setup an european anonymous CVS repository mirror, > 34 mbits and one hop from D-GUX (the huge stockholm exchanger). Could we move the www tree into CVS too, like we had with dali? That mirror would make updating my www mirror a lot more pleasant than ftp-ing from synergy *grin*. //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Tue Jun 30 13:01:02 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA31242; Tue, 30 Jun 1998 13:00:57 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA30074; Tue, 30 Jun 1998 12:54:08 -0700 Resent-Date: Tue, 30 Jun 1998 12:54:08 -0700 Message-Id: <199806301953.VAA09152@stockholm.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: ggi-develop@eskimo.com Subject: Re: ggi Debian packages In-reply-to: Your message of "Tue, 30 Jun 1998 21:06:49 +0200." <35993749.9C1CBBD6@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 21:53:38 +0200 From: Marcus Sundberg Resent-Message-ID: <"5OwF31.0.dL7.S9Kcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3233 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com > Falk Hueffner wrote: > > > - There's complete doc for libggi2d, and it seems nice, but where is > > it? Is it not yet implemented, or is it just me not #incuding the > > right header? > > It was not commited to the stable tree yet and the version in the > devel tree is not working. You can download a working snapshot from > http://home.pages.de/~tanner/files/libggi2d.tar.gz > (unpack it to /lib) Excuse me? If there's a working libggi2d, why do we have a broken one in the CVS tree that will become a stable release in a few hours?!? //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: e94_msu@e.kth.se From ggi-develop-request@eskimo.com Tue Jun 30 13:01:28 1998 Return-Path: Received: from mx1.eskimo.com (smartlst@mx1.eskimo.com [204.122.16.48]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA31251; Tue, 30 Jun 1998 13:01:22 -0700 Received: (from smartlst@localhost) by mx1.eskimo.com (8.8.8/8.8.8) id MAA29584; Tue, 30 Jun 1998 12:53:19 -0700 Resent-Date: Tue, 30 Jun 1998 12:53:19 -0700 Sender: core@orb.suntech.fr Message-ID: <359941A5.7027895@suntech.fr> Date: Tue, 30 Jun 1998 19:51:01 +0000 From: Emmanuel Marty Organization: Suntech X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.103 i686) MIME-Version: 1.0 To: ggi-develop@eskimo.com Subject: Re: Porting GGI to a new operating system References: <199806301934.PAA29630@yangtze.cs.umd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FcRE73.0.iD7.h8Kcr"@mx1> Resent-From: ggi-develop@eskimo.com Reply-To: ggi-develop@eskimo.com X-Mailing-List: archive/latest/3232 X-Loop: ggi-develop@eskimo.com Precedence: list Resent-Sender: ggi-develop-request@eskimo.com Frank W. Miller wrote: > Whats iirc? Oops - sorry, it means: "if I remember correctly". > Sorry about the machine being down. Its actually quite stable but > once in a while someone logs in and brings it down. The machine is at > school so I cat reboot it til I get there the next morning. Please, don't worry about it - it's not like I am expecting a system under development and constant change, to achieve 24/7