moving to CVS development

[Steffen Seeger <s.seeger@ph...>]

Hello all maintainers,

as announced, the CVS repository is available now, and I would like
to ask every maintainer to checkout a tree and move outstanding
changes over to the CVS tree.

Please be careful at the first checkin so that you do not override
any changes unintentionally.

Please let me know if you have any troubles accessing the repository.

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:seeger@...

Re: First impression

[Steffen Seeger <s.seeger@ph...>]

Mardy wrote:

> Hi!
> I installed successfully the latest snapshot (actually, I forgot to do
> "make modules_install", but it booted + o - ok :-) ).

Fine!

> I noticed the missing of console beeps, that were so cute... :-)
> I did a fast browse in the source files, and looks like it's a TODO.
> Do you confirm this?

Yes. This is a TODO I have ignored so far in order to get the graphics
stuff running. 

Basically, what needs to be done is to add a 'beeper device' to 
kii_focus_t, implement scroll_mksound() to call kiidev_mksound()
and implement kiidev_mksound() to issue a command to the 'beeper device'.

> As to the matrox driver: what is working and what isn't?

As far as I can tell, it compiles, and might load detecing the card
properly. However, the maintainer (Johan Karlberg) is likely to give a
more correct status evaluation.

			Steffen

PS: I am setting up a web-page that will report status of each driver.
Until then, please contact the maintainer of the driver directly.

_______________________________________________________________________________
Steffen Seeger                              mailto:seeger@...

Re: KGI portability

[Steffen Seeger <s.seeger@ph...>]

Tomasz Wegrzanowski wrote:

> How portable KGI is ?

I have tried to keep it as portable as possible.

> Is only mechanism used to obtain hardware resources
> needed to be changed when porting KGI to other POSIX system,
> or is this very Linux-specific ?

I will split my answer according to the various KGI subsystems:

1)	KGI environment (console management, boot display drivers,
	/dev/graphic special file mapper etc.)

	This is quite Linux specific in terms of the TTY driver
	and /dev/graphic special file driver interface used to
	actually link these driver into Linux.
	However, I tried to keep OS dependencies out of
	all KGI internal stuff where that seemed to make sense
	An exception is that it assumes a monolithic
	kernel design, which is that we assume we are running
	non-preemptive when executing this code.

	The boot display and input device drivers are i386 and
	PC architecture specific. They are just there to ge a machine
	running, until we have a file system and can get the real
	display drivers loaded. Thus porting KGI to another
	(Linux-)architecture will require implementation of proper
	boot drivers too.

2)	KGI display drivers (in the drv/display directory, formerly
	referenced as driver/graphics)

	These drivers require only a working KGI environment, so
	once you have the environment ported, you should have all the
	drivers. Actually not even that, the drivers themselves only
	need the hardware resource allocation and handling to work
	properly. (e.g. as long as the stuff in
	http://kgi.sourceforge.net/source/kgi-0.9/kgi/include/kgi/io.h
	is supplied by the 'other POSIX OS'

If you intend porting KGI to another OS, starting to look over 
system.h, io.h and creating <cpu-type>-compiler.h, <cpu-type>-types.h
should make definitions of most KGI basic types and the basic
I/O operations operational. Done this the drivers should already
compile. (Re-)implementing the OS environment will take some more work,
depending on how much the 'other POSIX OS' will differ from Linux.

I hope that answers your question, if not, don't hesiate to ask further
questions.

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:seeger@...