kgi-develop

Re: CVS access

[Alastair H. <ag...@ri...>]

So, my search-fu on freshports.org. was clearly lacking, it only showed
up a few results for cvs, yet, out of frustration, I cd to devel/cvs and
viola! cvs is still in Ports. I checked freshports.org again, and it
returns many hits for cvs now. Sorry for the noise.

CVS access

[Alastair H. <ag...@ri...>]

Hello,

Are there any lurkers left out there? I came across
https://gitlab.freedesktop.org/mesa/kmscube on FreeBSD recently, and
have been following the DRM development in the project too for sometime.
I was thinking about KGI, and how, Linux, and now FreeBSD are going
about KMS and video terminal integration...I really loved what KGI was
aiming for and the implementation on FreeBSD was pretty good. The tight
integration of the terminal, the console, and GPU mode setting, input,
and events was very well thought out, and with GGI on top.....my gosh,
another great loss in computer science history. Anyways, I wanted to
download the code and read it again. Does anyone know how? There is no
cvs on FreeBSD anymore, opencvs (OpenBSD's CVS) requires SSH, I no
longer have or remember my SF login.

I see kgi-project.org is still online :-) very nice. So, I suspect
Nicolas is still out there?

To health and anarchy.

Fwd: [3]

[Dee S. <dem...@ne...>]

Hey there! 
http://guiahotelerabolivia.com/_topic.forum?wibugyp=6040007&itikasug=862682

Re: KGI/GGI & The Pyro Operating System

[Nicolas S. <ns...@fr...>]

On Sat, Jun 16, 2012 at 10:54:49PM -0500, Dee Sharpe wrote:
> On 6/16/2012 4:10 PM, Nicolas Souchu wrote:
> 
> >Hello Dee,
> Hello there!
> 
> >Thanks for your interest in KGI and the GGI stuff. Currently, KGI has been 
> >developped and ported to Linux and FreeBSD i386 archs only. I don't know 
> >what your target is. Yes KGI permits pix boot thanks to VESA modes. A 
> >console fronted is running on top of it for *nix purpose.
> I've kept an eye on KGI over the years. I'd hoped that it'd really take 
> off. However, it might've been a bad idea to attempt to start with 
> Linux. Unfortunately, hindsight is 20/20. What I'm looking for is kernel 

The issue has been longly debated already...

> mode setting, as our current design uses userland mode setting. We're a 
> fork of Syllable, which is similar to BeOS. We boot directly into a gui 
> after the kernel & drivers are loaded. Also, all of the kernel side is 
> in C, all of the userland stuff is in C++. I'm trying to put together a 
> complete idea of what all I want, so I'm a bit open for ideas. I 
> definitely don't want DRI/DRM, as it's too *nix-y. However, now that you 
> mention it, it might be great to be able to supply the kernel with it's 
> own console (with input).
> 
> >What is your boot frontend ? KGI/GGI is perfectly designed to adopt new 
> >input systems. Basically, KGI infrastructure is independent of the final 
> >user interfaces (graphic or input). Thus you should be able to connect 
> >your own input/output systems.
> Our current frontend is an appserver which communicates directly with 
> the userspace video driver, much like XWindows. It also coordinates 

So it means user-land is already up and running when graphic boot appears.

> input. I'm in the process of splitting out from the appserver all 
> functionality which would be better suited in it's own process --hence 
> the coding of the almost complete inputserver. When not in kernel debug 
> mode (which hasn't been completed yet), all input should go into 
> userspace as normal. However, all video card specific functionality 

In KGI, inputs are dispatched to consoles by the kernel allowing interception
of key controls triggering console switching. This might be to Un*x specific
for you.

> should go into the kernel driver (possibly KGI). On top of the kernel 
> driver should be the usermode component (possibly GGI). Afterwards, the 
> plan would be for the GGI component to serve as the bridge between Pyro 
> & Gallium3d. The appserver should communicate with Gallium3d in order to 
> draw a composited desktop.
> 
> >I suggest you look at http://www.kgi-project.org/interfaces.html.
> I've taken a summary look at it, I currently don't have enough time to 
> dig too deep. I plan to take a closer look in the near future, time 
> permitting.
> 
> >KGI community is, hmm let say... quite, some would say died or roasted.
> >KGI is a total alternative to dri/drm. Different driver systems were 
> >developped for KGI, either as a linuxfb compatibility interface or kgi 
> >true drivers. You should be able to interface yours. I think KGI could be 
> >a good canditate for your needs. Nethertheless, you should consider GGI 
> >also indepently since it is a very hw independent library.
> Yeh, I've noticed. I seem to recall seeing a driver for Radeons in the 

IIRC yes.

> codebase, though I may be mistaken. GGI probably would simplify 
> communications with the KGI driver, which 'should' result in less code 
> for me to write. Our team's rather sparse, so it's really all on me to 
> get this all up & running. Has there been no interest within your 
> community to port other hardware drivers to KGI?

GGI would definitly save you work for interfacing with KGI.
No, no adoption for KGI in an OS project and different visions in its community
prevented initiatives. Personnaly, I was not a graphic developper and my
contribution was only to OS infrastructure & porting to FreeBSD. 6 years ago...

-nicholas

Re: KGI/GGI & The Pyro Operating System

[Dee S. <dem...@ne...>]

On 6/16/2012 4:10 PM, Nicolas Souchu wrote:

> Hello Dee,
Hello there!

> Thanks for your interest in KGI and the GGI stuff. Currently, KGI has been developped and ported to Linux and FreeBSD i386 archs only. I don't know what your target is. Yes KGI permits pix boot thanks to VESA modes. A console fronted is running on top of it for *nix purpose.
I've kept an eye on KGI over the years. I'd hoped that it'd really take 
off. However, it might've been a bad idea to attempt to start with 
Linux. Unfortunately, hindsight is 20/20. What I'm looking for is kernel 
mode setting, as our current design uses userland mode setting. We're a 
fork of Syllable, which is similar to BeOS. We boot directly into a gui 
after the kernel & drivers are loaded. Also, all of the kernel side is 
in C, all of the userland stuff is in C++. I'm trying to put together a 
complete idea of what all I want, so I'm a bit open for ideas. I 
definitely don't want DRI/DRM, as it's too *nix-y. However, now that you 
mention it, it might be great to be able to supply the kernel with it's 
own console (with input).

> What is your boot frontend ? KGI/GGI is perfectly designed to adopt new input systems. Basically, KGI infrastructure is independent of the final user interfaces (graphic or input). Thus you should be able to connect your own input/output systems.
Our current frontend is an appserver which communicates directly with 
the userspace video driver, much like XWindows. It also coordinates 
input. I'm in the process of splitting out from the appserver all 
functionality which would be better suited in it's own process --hence 
the coding of the almost complete inputserver. When not in kernel debug 
mode (which hasn't been completed yet), all input should go into 
userspace as normal. However, all video card specific functionality 
should go into the kernel driver (possibly KGI). On top of the kernel 
driver should be the usermode component (possibly GGI). Afterwards, the 
plan would be for the GGI component to serve as the bridge between Pyro 
& Gallium3d. The appserver should communicate with Gallium3d in order to 
draw a composited desktop.

> I suggest you look at http://www.kgi-project.org/interfaces.html.
I've taken a summary look at it, I currently don't have enough time to 
dig too deep. I plan to take a closer look in the near future, time 
permitting.

> KGI community is, hmm let say... quite, some would say died or roasted.
> KGI is a total alternative to dri/drm. Different driver systems were developped for KGI, either as a linuxfb compatibility interface or kgi true drivers. You should be able to interface yours. I think KGI could be a good canditate for your needs. Nethertheless, you should consider GGI also indepently since it is a very hw independent library.
Yeh, I've noticed. I seem to recall seeing a driver for Radeons in the 
codebase, though I may be mistaken. GGI probably would simplify 
communications with the KGI driver, which 'should' result in less code 
for me to write. Our team's rather sparse, so it's really all on me to 
get this all up & running. Has there been no interest within your 
community to port other hardware drivers to KGI?


-- 

Dee Sharpe

The difference between what IS done
&  what COULD be done is relational to
what you ARE doing&  what you COULD be doing!

KGI/GGI & The Pyro Operating System

[A. D. S. <dem...@ne...>]

Hello all,

I'm Dee Sharpe, from the Pyro OS core group. Pyro is a fork of the 
Syllable operating system. Currently, I'm shopping for a new video 
driver architecture & I'd like a bit of advice & insight into KGI & GGI 
for consideration for our OS. Since we're not another *nix clone, we 
boot into a GUI. It's not possible to boot Pyro to a command line. Is 
this easily supportable by KGI/GGI? Also, since we don't boot into a 
console, we have our own input system. Is it possible to use KGI/GGI 
without including anything that's not specifically video card/gpu 
related? In addition, the overall direction that we're trying to go in 
is to use our new video driver system as a backend to Gallium3d as a 
replacement for the common dri/drm setup; has this been tried & used 
successfully in the KGI/GGI community? Any advice, guidance, and/or 
comments would be greatly appreciated.

This email has been sent to the kgi-developer, ggi-develop, & ggi-users 
groups.

-- 

A. D. Sharpe

FreeBSD update

[Alastair H. <ag...@co...>]

Hello all,

The FreeBSD-8 port is coming along slowly. Multiuser mode is working, there 
is, however, still a problem with single user mode, but that may be my 
hardware, so I need help from users, testers, contributors, tribbles or etc.

Currently the code is developed against 8.0-RC1 (svn r197633)

If you're interested you can download the source code via CVS:

cvs -d:pserver:ano...@kg...:/cvsroot/kgi login
cvs -z3 -d:pserver:ano...@kg...:/cvsroot/kgi co -P 
freebsd

You then need to copy the checkout over your local copy of the FreeBSD source 
tree. 

For example, if you ran the commands above from ${HOME}, you would now have a 
freebsd/ directory. You will also need an up to date version of the FreeBSD 8 
source tree, somewhere around 2009-09-30.

You may want to make a backup of your src/ tree.

cp -R ~/freebsd/sys /usr/src && cp -R ~/freebsd/usr.sbin /usr/src;

Then

cd /usr/src && make kernel KERNCONF=KGI INSTKERNNAME=kernel.KGI

If the build succeeds, you will have a KGI kernel in /boot/kernel.KGI. Restart 
your system, and when the boot loader screen shows up, hit 6 on your keyboard 
and:

# unload <ENTER>
# load /boot/kernel.KGI/kernel <ENTER>
# boot <ENTER>

Enjoy.

Check out kgi-project.org for some screen shots and further details about the 
project.

-al
 Alastair Hogge

Error in the KGI

[Carlos C. <cd...@bs...>]

Hi *:

       I have some questions;

        I followed the steps I have indicated, I have updated yesterday to
FreeBSD 8, he fell from the cvs newtree with KGI als sources and have
installed the GGI libraries, these are the steps I have taken a you upgraded
to FreeBSD 8:
My configuration:

[root@Reina-Tonia /]# uname -srip; pkg_info | grep -E 'libgi|libgg'
FreeBSD 8.0-CURRENT i386 Segvfault
libggi-2.2.2_3,1    A flexible drawing library
libggigcp-1.0.2_1   A libggi extension for advanced color and palette
handling
libggimisc-2.2.2_1  A libggi extension providing support for hard to
categorize
libggiwmh-0.3.2_2   A libggi extension, wmh stands for Window Manager Hints
libgii-1.0.2_2      GGI API for input sources
libgiigic-1.1.2_1   A library on top of libgii, gic stands for General Input
Co
[root@Reina-Tonia /]#


Steps:

[root@Reina-Tonia /]# cd /usr/ports/graphics/libggi && make install clean
[root@Reina-Tonia /]# cd /usr/ports/graphics/libggigcp && make install clean
[root@Reina-Tonia /]# cd /usr/ports/graphics/libggimisc && make install
clean
[root@Reina-Tonia /]# cd /usr/ports/graphics/libggiwmh && make install clean
[root@Reina-Tonia /]# cd /usr/ports/devel/libgii && make install clean
[root@Reina-Tonia /]# cd /usr/ports/devel/libgiigic && make install clean



Download KGI Sources;

[root@Reina-Tonia /]# cd root/Sistema/KGI-Proyect/
[root@Reina-Tonia ~/Sistema/KGI-Proyect]# cvs -z3
-d:pserver:ano...@kg...:/cvsroot/kgi co -P
newtree
 cvs checkout: Updating newtree
cvs checkout: Updating newtree/fbsd
U newtree/fbsd/kgi_pager.c.diff
U newtree/fbsd/kgi_pager.h.diff
U newtree/fbsd/kgia.c.diff
U newtree/fbsd/sys-patch.diff
cvs checkout: Updating newtree/kgc

ETC....

U newtree/scemul/sce_vtconsole.c
[root@Reina-Tonia ~/Sistema/KGI-Proyect]#

Next, moves to the sources and apply the patch:

[root@Reina-Tonia /]# cd /usr/src/sys/dev/
[root@Reina-Tonia /usr/src/sys/dev]# cp -R
/root/Sistema/KGI-Proyect/newtree/* .

Apply the patch*;
[root@Reina-Tonia /usr/src]# patch <
/root/Sistema/Prueba/newtree/fbsd/kgi_pager.c.diff
[root@Reina-Tonia /usr/src]# patch <
/root/Sistema/Prueba/newtree/fbsd/kgi_pager.h.diff
[root@Reina-Tonia /usr/src]# patch <
/root/Sistema/Prueba/newtree/fbsd/kgia.c.diff
[root@Reina-Tonia /usr/src]# patch <
/root/Sistema/Prueba/newtree/fbsd/sys-patch.diff




Next, rebuild wolrd and Kernel;


[root@Reina-Tonia /usr/src]# make buildworld
*****************************************************************

>>> World build completed on Wed Dec 24 17:22:17 UTC 2008


Edit the kernel and add the following:

[root@Reina-Tonia /usr/src]# cd sys/i386/conf/
[root@Reina-Tonia /usr/src/sys/i386/conf]# nano Segvfault

## Otros ##

options         VESA
options         SC_PIXEL_MODE
options         SC_NORM_ATTR=(FG_LIGHTGREEN|BG_BLACK)
options         SC_NORM_REV_ATTR=(FG_BLACK|BG_GREEN)
options         SC_KERNEL_CONS_ATTR=(FG_LIGHTRED|BG_BLACK)
options         SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)



## KGI


#options        KGI_NOSPLASH
options         KGI_COMPAT
options         KGI_DBG_LEVEL=0
device          kgi            # Kernel Graphic Interface
device          kip            # KII input parser
device          kgy            # KGI VESA compatible display
device          scemul         # syscons emulation for KGC
device          kgc            # KGI console
device          kgu            # KGI graphic user interface
device          kiu            # KGI input user interface
device          kgim            # KGI module driver interface

Comment this;

#device         splash          # Splash screen and screen saver support

# syscons is the default console driver, resembling an SCO console
#device         sc


Then, symlink;

[root@Reina-Tonia /usr/src]# ln -s /usr/src/sys/dev/kii /usr/include/dev
[root@Reina-Tonia /usr/src]# ln -s /usr/src/sys/dev/kgi /usr/include/dev

The error:



[root@Reina-Tonia /usr/src]# make buildkernel KERNCONF=Segvfault

--------------------------------------------------------------
>>> Kernel build for Segvfault started on Wed Dec 24 19:46:38 UTC 2008
--------------------------------------------------------------
===> Segvfault
mkdir -p /usr/obj/usr/src/sys

--------------------------------------------------------------
>>> stage 1: configuring the kernel
--------------------------------------------------------------
cd /usr/src/sys/i386/conf;
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/u

sr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src

/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:

/bin:/usr/sbin:/usr/bin  config  -d /usr/obj/usr/src/sys/Segvfault
/usr/src/sys

/i386/conf/Segvfault
config: Error: device "kgy" is unknown
config: Error: device "kgim" is unknown
config: 2 errors
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
[root@Reina-Tonia /usr/src]#



In the doc of /newtree/kgi/NOTES referring to a patch;

#################################

 INSTALL
#########

Check you have a source tree installed in /usr/src.

Get the file kgi4bsd-Rxxx-yymmdd.diffs in /usr/src directory.

Patch the sources with (use -C option if you want to try before applying)

patch -p5 < kgi4bsd-Rxxx-yymmdd.diffs

If you plan to compile graphic driver modules,

cp share/mk/bsd.kgim.mk /usr/share/mk

Edit your machine file and do the following:

###################################



An error in the procedure?, any comments?


Thanks in advance ;)



-- 
Carlos Corona
CdK1
BSD Chile
http://www.bsd.cl

Re: Greetings and information.-

[Nicolas S. <ns...@fr...>]

On Mon, Dec 22, 2008 at 10:23:17AM -0300, Alex M. Alvarez A. wrote:
> My friend and i try to contribute as beta tester in several versions
> of FreeBSD, but need the procedure to patch.
> 
> Someone place to define as manual.

Welcome Alex and Carlos !

You know, this list is really quiet these days... like the project :)
You're welcome anyway. Did you have a look to the kgi-project homepage?

Nicholas

Re: Greetings and information.-

[Alastair H. <ag...@co...>]

On Monday 22 December 2008 12:01:36 Carlos Corona wrote:
> First of all, "hello"), is a pleasure to have signed to the list,
G'day Carlos,

Welcome to the list :-)

> especially given the fact that I have searching this type of proyect in
> FreeBSD for a while;)
>
> Well, to the point, I have FreeBSD 7.1-PreRelease, as well as the libraries
> install it, there is a special procedure for applying the patches?, In fact
> some sort of documentation to FreeBSD?
There's some KGI documentation on/at the kgi-project.org website. There is 
also some text in the cvs newtree branch, you can get the later via:
cvs -d:pserver:ano...@kg...:/cvsroot/kgi login 
cvs -z3 -d:pserver:ano...@kg...:/cvsroot/kgi co -P

For FreeBSD you will need to patch the diffs to a 8.0 system from 200801, you 
will also need to copy the KGI components from that checkout to 
/usr/src/sys/dev.

> My system:
>
>
> [root@Reina-Tonia /]# uname -a
> FreeBSD Reina-Tonia 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Thu Nov 27
> 14:58:34 UTC 2008     CdK1@Reina-Tonia:/usr/obj/usr/src/sys/Segvfault  i386
> [root@Reina-Tonia /]#
>
>
> Packages:
>
> [root@Reina-Tonia /]# pkg_info | grep -E 'libgi|libgg'
> libggi-2.2.2_3,1    A flexible drawing library
> libggigcp-1.0.2_1   A libggi extension for advanced color and palette
> handling
> libggimisc-2.2.2_1  A libggi extension providing support for hard to
> categorize
> libggiwmh-0.3.2_2   A libggi extension, wmh stands for Window Manager Hints
> libgii-1.0.2_2      GGI API for input sources
> libgiigic-1.1.2_1   A library on top of libgii, gic stands for General
> Input Co
> [root@Reina-Tonia /]#
For GGI related questions try the GGI lists.

> PD: I have the system up to date, as kernel level system;)
KGI on FreeBSD has stagnated somewhat at the moment, so don't expect much, 
unless you feel like booting an old RELENG_6 machine and using the last stable 
patches.

-Alastair

Re: Greetings and information.-

[Alex M. A. A. <ku...@fr...>]

My friend and i try to contribute as beta tester in several versions
of FreeBSD, but need the procedure to patch.

Someone place to define as manual.

See you later.

2008/12/22 Carlos Corona <cd...@bs...>:
>
> First of all, "hello"), is a pleasure to have signed to the list, especially
> given the fact that I have searching this type of proyect in FreeBSD for a
> while;)
>
> Well, to the point, I have FreeBSD 7.1-PreRelease, as well as the libraries
> install it, there is a special procedure for applying the patches?, In fact
> some sort of documentation to FreeBSD?
>
> My system:
>
>
> [root@Reina-Tonia /]# uname -a
> FreeBSD Reina-Tonia 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Thu Nov 27
> 14:58:34 UTC 2008     CdK1@Reina-Tonia:/usr/obj/usr/src/sys/Segvfault  i386
> [root@Reina-Tonia /]#
>
>
> Packages:
>
> [root@Reina-Tonia /]# pkg_info | grep -E 'libgi|libgg'
> libggi-2.2.2_3,1    A flexible drawing library
> libggigcp-1.0.2_1   A libggi extension for advanced color and palette
> handling
> libggimisc-2.2.2_1  A libggi extension providing support for hard to
> categorize
> libggiwmh-0.3.2_2   A libggi extension, wmh stands for Window Manager Hints
> libgii-1.0.2_2      GGI API for input sources
> libgiigic-1.1.2_1   A library on top of libgii, gic stands for General Input
> Co
> [root@Reina-Tonia /]#
>
>
> PD: I have the system up to date, as kernel level system;)
>
>
>
> --
> Carlos Corona
>       CdK1
> BSD Chile
> http://www.bsd.cl
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> kgi-develop mailing list
> kgi...@li...
> https://lists.sourceforge.net/lists/listinfo/kgi-develop
>
>



-- 
Alex M. Alvarez A.
FreeBSD Chile
http://kuarzo.FreeBSD.cl

Greetings and information.-

[Carlos C. <cd...@bs...>]

First of all, "hello"), is a pleasure to have signed to the list, especially
given the fact that I have searching this type of proyect in FreeBSD for a
while;)

Well, to the point, I have FreeBSD 7.1-PreRelease, as well as the libraries
install it, there is a special procedure for applying the patches?, In fact
some sort of documentation to FreeBSD?


My system:


[root@Reina-Tonia /]# uname -a
FreeBSD Reina-Tonia 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Thu Nov 27
14:58:34 UTC 2008     CdK1@Reina-Tonia:/usr/obj/usr/src/sys/Segvfault  i386
[root@Reina-Tonia /]#


Packages:

[root@Reina-Tonia /]# pkg_info | grep -E 'libgi|libgg'
libggi-2.2.2_3,1    A flexible drawing library
libggigcp-1.0.2_1   A libggi extension for advanced color and palette
handling
libggimisc-2.2.2_1  A libggi extension providing support for hard to
categorize
libggiwmh-0.3.2_2   A libggi extension, wmh stands for Window Manager Hints
libgii-1.0.2_2      GGI API for input sources
libgiigic-1.1.2_1   A library on top of libgii, gic stands for General Input
Co
[root@Reina-Tonia /]#


PD: I have the system up to date, as kernel level system;)



-- 
Carlos Corona
      CdK1
BSD Chile
http://www.bsd.cl

Re: Modaration (was: KGI site was down)

[Nicolas S. <ns...@fr...>]

On Thu, Oct 09, 2008 at 01:42:46AM +0200, ola...@gm... wrote:
> Hi,
> 
> On Thu, Oct 02, 2008 at 09:11:53PM +0200, Nicolas Souchu wrote:
> 
> > Still filtering is ON to prevent SPAM which delays your posts. Sorry.
> > If the traffic was heavier, I'd disable it.
> 
> I don't understand the problem: You should be able to configure it so
> that only mails from non-subscribed users are held for moderation, and
> on first moderation you can also put the user on a whitelist...

You're right. Only, non-member posts are now held for moderation.

-nicholas

Modaration (was: KGI site was down)

[<ola...@gm...>]

Hi,

On Thu, Oct 02, 2008 at 09:11:53PM +0200, Nicolas Souchu wrote:

> Still filtering is ON to prevent SPAM which delays your posts. Sorry.
> If the traffic was heavier, I'd disable it.

I don't understand the problem: You should be able to configure it so
that only mails from non-subscribed users are held for moderation, and
on first moderation you can also put the user on a whitelist...

-antrik-

KGI site was down

[Nicolas S. <ns...@fr...>]

Hi guys,

due to SF DNS migration, domain redirection was incorrectly configured which
prevented www.kgi-project.org to work properly.

now it's fixed !

Still filtering is ON to prevent SPAM which delays your posts. Sorry. If
the traffic was heavier, I'd disable it.

Nicholas

Re: [ggi-develop] Proposel for a new KGI tree in CVS

[<ola...@gm...>]

Hi,

On Sun, Aug 31, 2008 at 04:27:56PM +0800, Alastair Hogge wrote:

> Its been discussed before for on IRC, and I think the consensus from
> the remaining interested KGI party (the IRC clan), was that KGI be
> moved to a central repository, with the appropriate OS hooks/ties
> separated from the KGI core, but remaining in CVS under a defined file
> hierarchy structure.
> 
> I've collected Nicholas Souchu's last p4 updates, and merged them with
> his last FreeBSD-6 patch. I managed to port this effort to FreeBSD-8.
> With this, and some new or renewed interest in KGI, I would, without
> any objections, like to create a new tree in CVS using the FreeBSD-8
> patch.

Well, as I was the main advocate of a shared tree in the debate two
years ago -- in fact started it -- I guess I should speak up here...

My original conclusion was that, as KGI touches various parts of the
kernel, the only sane option is to have one module for the shared core,
and then one module for each system, containing the *complete* kernel
source -- this is the only way to do integration without some ugly
scripts that implement custom revision control functionality...

Back then I also suggested that perhaps we should take a look at how DRM
(the kernel component of DRI) is doing it, as they are in exactly the
same situation: graphics drivers portable between several kernels.

I got somewhat familiar with DRM in the mean time, and have a rough idea
now how they are doing it -- but right now they are just in the process
of revamping the approach...

Up till now, there was the DRM tree with a shared-core and with system
specific parts like linux-core and bsd-core. (Though the supposedly
system-specific parts are also mostly just copied AIUI...) While FreeBSD
seems to have used the stuff from the DRM tree mostly unmodified, Linux,
OpenBSD and NetBSD all had their own trees, and merged changes by hand.
In the case of Linux, this is unavoidable, most notably because the
Linux folks don't want any compatibility code for other systems or for
other kernel versions in their tree. Not sure about the reasons for
OpenBSD and NetBSD.

The DRM tree is self-contained enough that at least on Linux, DRM can
also be compiled directly from the DRM tree, and thus used with kernels
that haven't merged the newer stuff yet. This is considered quite useful
for early testing of new features.

As for the changes, things haven't quite settled yet, but from the looks
of it the DRM tree will be changed to resemble the Linux tree much more,
so merging to Linux becomes a lot easier, and merging to other system
slightly harder. This is generally considered a reasonable and fair
compromise, as all DRM development is actually done by the Linux
crowd... (In fact, almost all X development in general is done by
GNU/Linux developers nowadays.)

The second part of the plan is to implement all changes to the DRM tree
on separate branches, and have a common branch with all new stuff only
for testing; merging changes to the various systems directly from the
topic branches. This would make a lot of sense IMHO, also for KGI.

Now there is one important thing to point out though: The original
discussion was done in a situation where KGI was still the only project
(to my knowledge) that tried to introduce general graphics hardware
drivers in the kernel, and thus was worth persuing further. The
situation is quite changed nowadays, with Xorg (and with it all systems
that care about good X support) moving to DRM-based kernel modesetting.
The KGI drivers were never in good shape, and now they are simply not
needed anymore.

The KGI input drivers were already deemed a bad idea before, so this
leaves KGI with pretty much only the console system. I for my part was
never interested in this bit (considered it a quite separate project
indeed), but I know that for Nicholas Souchu this was the major
motivation for his FreeBSD KGI work... So maybe some systems will still
consider the KGI console stuff valuable, after moving it to use DRM
modesetting drivers. (Or perhaps whatever framebuffer drivers the kernel
in question is already providing.)

Considering that KGI for Linux has been pretty much dead for years, and
the console part probably never really had a chance; and that I'm not
interested in the console part for my Hurd port (which BTW, at this
stage, I'm only doing as proof of concept and temporary base for other
work, to be replaced by DRM as The Real Thing (TM) once DRM modesetting
stabilizes and I have some understanding of the stuff); this means that
the only potential users of what remains of KGI are most likely the BSDs
-- which might put the whole shared-tree consideration in quite a
different light...

-antrik-

Proposel for a new KGI tree in CVS

[Alastair H. <ag...@co...>]

Hello,

Its been discussed before for on IRC, and I think the consensus from the 
remaining interested KGI party (the IRC clan), was that KGI be moved to a 
central repository, with the appropriate OS hooks/ties separated from the KGI 
core, but remaining in CVS under a defined file hierarchy structure.

I've collected Nicholas Souchu's last p4 updates, and merged them with his 
last FreeBSD-6 patch. I managed to port this effort to FreeBSD-8. With this, 
and some new or renewed interest in KGI, I would, without any objections, like 
to create a new tree in CVS using the FreeBSD-8 patch.

cvs-root:
	CVS/
	CVSROOT/
	html/
	kgi-0.9/
	tools/
	newtree/
		fbsd/
		scemul/
		kgi/
		kgc/
		....

You may aim flame throwers at bike sheds now.
	-Al

Re: KGI thesis...

[<ola...@gm...>]

Hi,

On Fri, Mar 07, 2008 at 09:30:11AM +0100, Nicolas Souchu wrote:

> Do you know more exactly where DRM is at the moment? I have no clue
> even about the directions it's taking.

It's hard to compare for me, as I don't really know all the details
about KGI either. But it seems to me that the design is more and more
resembling KGI -- the graphics driver part of KGI, that is.

There seem to be some differences, in how multihead is handled for
example. But it looks like it will be able to do everything KGI could
do, and more.

> Remember that KGI is not only a driver interface but also a console
> framework. I know this is not it's primary characterisc for other
> people than me but it makes some difference with all other stuff
> around. Also, KGI should be able to accept any kind of drivers (X,
> fbdev, KGI or whatever) with the appropriate glue code. I could port
> an fbdev driver quite easily after developing the right glue for it.

I'm perfectly aware of this. In fact, I stated a while ago (perhaps you
were not participating in that discussion), that if you want to preserve
the console part of KGI, you should port it to use DRM as the driver
backend.

I for my part was never very much interested in the console part. In
fact, unlike for the actual drivers, I can't see any reason why totally
different operating systems should even attempt to share the console
code.

The reason why KGI might still be an intersting intermediate option, is
that we have the KGI backend of libggi, implementing the abstraction
part of the drivers in a generic library. For DRM, there is the DRI
backend of Mesa doing this, but only for 3D. 2D acceleration will be
folded into DRI as well at some point it seems, though this part is not
firm yet. For DRM modesetting, there is no generic library so far -- and
I'm not sure there will be, any time soon. X will probably just
implement it's own handling, like it always did, and others will have to
cope.

I originially wanted to implement a libggi backend for DRM modesetting,
and try to persuade X folks to use that. But by now I realize this is
hopeless. They'd never see the benefit of such a major change. The best
we can try for is taking the X code into a simple library, in the hope
that at least that could be shared between X and libggi (and probably
DirectFB and maybe others). But that's a project for the future. It's
not something I could work with right now.

-antrik-

Re: KGI thesis... (was: Moderation of KGI lists)

[Nicolas S. <ns...@fr...>]

Hi antrik,

Depends what your objectives are. Do you know more exactly where DRM is
at the moment? I have no clue even about the directions it's taking. A side
effect of OSS is the multiplicity of solutions proposed and the difficulty
to make long term valuable choices.

Remember that KGI is not only a driver interface but also a console
framework. I know this is not it's primary characterisc for other people
than me but it makes some difference with all other stuff around. Also,
KGI should be able to accept any kind of drivers (X, fbdev, KGI or whatever)
with the appropriate glue code. I could port an fbdev driver quite easily
after developing the right glue for it.

Before GGI and KGI were forked, GGI was userland with drivers embedded IIRC.

Nicholas

On Wed, Mar 05, 2008 at 04:15:55AM +0100, ola...@gm... wrote:
> Hi,
> 
> On Mon, Mar 03, 2008 at 12:43:44PM +0100, Nicolas Souchu wrote:
> 
> > What's up antrik ? How's going your thesis ?
> 
> Well, pretty much unchanged I'm afraid :-( I constantly get distracted
> by all kinds of stuff.
> 
> It doesn't exactly help that with all the DRM modesetting stuff on the
> way, I have serious doubts whether it's even useful anymore to port KGI.
> On the other hand the DRM stuff will still take a while till it's ready
> for prime time. Also I fear that being a more complete solution, it will
> be more involved to port... So not really suitable for my thesis.
> 
> Another thing that made me doubt is that thinking about how to make KGI
> run in a userspace server, I came to the conclusion that it's easiest to
> check how X handles it -- after all, it does exactly that: Runs the
> driver in a userspace server... But once I use X as inspiration, I could
> just as well also use parts of the code -- or even use the whole
> driver... But then, why bother with KGI at all?...
> 
> On the other hand, with KGI at least there is a complete userspace
> infrastructure -- once I have the actual driver part running, I should
> be all settled...
> 
> But then again, I'm not at all convinced anymore that GGI in it's
> present state is really the right approach for what I want to achieve...
> 
> So you see, not an easy decision at all :-(
> 
> -antrik-

KGI thesis... (was: Moderation of KGI lists)

[<ola...@gm...>]

Hi,

On Mon, Mar 03, 2008 at 12:43:44PM +0100, Nicolas Souchu wrote:

> What's up antrik ? How's going your thesis ?

Well, pretty much unchanged I'm afraid :-( I constantly get distracted
by all kinds of stuff.

It doesn't exactly help that with all the DRM modesetting stuff on the
way, I have serious doubts whether it's even useful anymore to port KGI.
On the other hand the DRM stuff will still take a while till it's ready
for prime time. Also I fear that being a more complete solution, it will
be more involved to port... So not really suitable for my thesis.

Another thing that made me doubt is that thinking about how to make KGI
run in a userspace server, I came to the conclusion that it's easiest to
check how X handles it -- after all, it does exactly that: Runs the
driver in a userspace server... But once I use X as inspiration, I could
just as well also use parts of the code -- or even use the whole
driver... But then, why bother with KGI at all?...

On the other hand, with KGI at least there is a complete userspace
infrastructure -- once I have the actual driver part running, I should
be all settled...

But then again, I'm not at all convinced anymore that GGI in it's
present state is really the right approach for what I want to achieve...

So you see, not an easy decision at all :-(

-antrik-

Re: Moderation of KGI lists

[Nicolas S. <ns...@fr...>]

On Sun, Mar 02, 2008 at 03:11:03AM +0100, ola...@gm... wrote:
> Hi,
> 
> On Wed, Feb 27, 2008 at 10:09:02PM +0100, Nicolas Souchu wrote:
> 
> >  Sorry fed up with spam. I put moderation on every post. Will try to
> >  moderate periodically but this will delay your posts.
> 
> Should suffice to moderate only posts from non-subscribers... These are
> almost always Spam anyways.

Indeed. What's up antrik ? How's going your thesis ?

Nicholas

Re: Moderation of KGI lists

[<ola...@gm...>]

Hi,

On Wed, Feb 27, 2008 at 10:09:02PM +0100, Nicolas Souchu wrote:

>  Sorry fed up with spam. I put moderation on every post. Will try to
>  moderate periodically but this will delay your posts.

Should suffice to moderate only posts from non-subscribers... These are
almost always Spam anyways.

-antrik-

Re: Moderation of KGI lists

[Nicolas S. <ns...@fr...>]

Hi all,
 
 Sorry fed up with spam. I put moderation on every post.
 Will try to moderate periodically but this will delay your posts.
 
 Sorry for the inconvenience.
 
 Nicholas

Your Winning Batch No: WNTO/7416/VA/ES!!!

[Euro M. A. O. <emi...@ya...>]

Computer Ballot Sweepstakes Email Award 2008.
(Euro million loteria Espanol Award 2008).
www.loteria.com
Paseo De La castellana
15-89, 28008 Madrid.
Spain , Branch.


   YOUR E-MAIL ADDRESS WON THIS YEAR EURO MILLION LOTTERY.


Sir/Madam,

   We wish to congratulate you over your email success in our computer  
balloting
held on FEBUARY 20TH,2008. This is a Millennium Scientific Computer Game in
which email addresses were used. It is a promotional program aimed at
encouraging internet users; therefore you do not need to buy ticket to enter
for it. You have been approve for the star prize of ?987,248,00 (Nine Hundred
And Eighty Seven Thousand, Two Hundred And forty Eight Euros Only).To claim
your winning prize you are to contact the appointed claim agent as soon as
possible for the immediate release of your winnings with the following
information below:



Name:.............................
Age:..............................
Sex:..............................
Address:..........................
Email:............................
Phone:............................
Occupation:.......................
Company:..........................
Country:..........................


Mr Goodluck Pereda
Liberty Seguros Trust Agency.
Mario Cabre Sin Numero,
28016, Madrid - Spain
E-mail: (goo...@ai...)

Ref No.ES/037/11/06/MD
Batch No: WNTO/7416/VA/ES
Lucky No: 07-13-31.54-640
Serial No: MUOTI/82536

  The Validity period of the winnings is for 20 working days hence you are
expected to make your claims immediately, any claim not made before this date
will be returned to the MINISTERIO DE E CONOMIA Y HACIENDA .

      Note:You are advised to keep this winning very confidential until you
receive your lump prize in your account or optional cheque issuance to  
you,This
is a protective measure put in place to avoid people applying for your winnig
fund,as we have had cases like this before.


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
The information transmitted is intended only for the person or entity to whom
or which it is addressed.Unauthorised use, disclosure orcopying is strictly
prohibited.The sender accepts no liability for the improper  
ransmission of this
communication nor for any delay in its receipt.






----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

utolatry

[Johanna K. <Joh...@co...>]

Sharon, check out Goliath in my pants! http://orugne.com/