--- Log opened dim fév 19 21:55:06 2006
21:57 < nsouch> kgi meeting part2 takes place on #ggi...
21:57 < antrik> Foske is missing :-(
21:58 < antrik> nsouch: BTW, seen my summary/new agenda I finally managed to send earlier this day?...
21:58 < nsouch> antrik: yes
21:59 < nsouch> antrik: did you post more mail to Xorg list?
21:59 < antrik> nsouch: no more mail :-(
22:00 < antrik> I wonder whether I should submit a KGI talk for FOSDEM in spite of nobody replying to my suggestion on the list...
22:02 < nsouch> antrik: If the FOSDEM talk is just PR and you don't have relations :)
22:02 < antrik> not sure what you mean...
22:03 < nsouch> forget it my english lacks accuracy
22:04 < antrik> so should we start without Foske, or hope he still shows up?...
22:04 < nsouch> are others there?
22:04 < nsouch> antrik: your summary,
22:05 < nsouch> shows that most of ideas are there, we just need to conclude about actions now
22:05 < antrik> is it very inaccurate? ;-)
22:05 < antrik> well, yes, not on all points, but several
22:05 < antrik> all the worse if Foske isn't here :-(
22:06 < nsouch> antrik: want to postone?
22:07 < nsouch> s/postone/postpone/
22:07 < antrik> well, I think there are *some* issues we can discuss
22:08 < nsouch> fbdev?
22:08 < antrik> while writing the summary, I was thinking about a few things, and it's becoming more and more clear to me that we are really talking about two different projects here :-(
22:08 < MooZ> about the name problem why not use mythology names, superheroes names or whatever  instead of acronyms? 
22:08 < MooZ> :)
22:09 < nsouch> MooZ: yes I think the same
22:09 < nsouch> antrik: which are?
22:10 < nsouch> In my summary I proposed to group /dev/graphic with kgim
22:10 < nsouch> in one project
22:10 < antrik> one one hand, there is the console system you are working on, which just happens to use the graphics hardware drivers from KGIM and the other display drivers
22:11 < antrik> on the other hand, there is the graphics hardware access Foske and me work on, and doesn't have anything to do with console etc.
22:12 < nsouch> antrik: were do you put /dev/graphic?
22:12 < antrik> graphics access
22:12 < nsouch> and kgi_display_t?
22:13 < nsouch> will it be still the API between graphic and console?
22:13 < antrik> not sure... I fear I don't understand this enough to tell
22:14 < nsouch> I feel that even with skids design kgi_display_t can remain
22:14 < nsouch> so ok of the two projects
22:14 < nsouch> note that splitting the project will help you and foske working ot graphics but will leak the whole
22:15 < antrik> leak the whole?...
22:15 < nsouch> argh, hmmm
22:16 < nsouch> weaken the whole
22:16 < nsouch> we definitly need to maintain code for both projects at the same place
22:17 < nsouch> this is why we need a global name for the whole
22:17 < antrik> well, the problem is that you are fixed on this whole, why neither Foske nor me nor probably many other people are really interested in it...
22:17 < nsouch> so you want to separate the sources between the two projects?
22:18 < antrik> not necessarily... I just want to make it very clear that what you are working in is only somewhat related to what we are working on
22:19 < antrik> it *might* have sense to separate the source, I don't know
22:19 < antrik> BTW, regard a name for the whole, there already is one: GGI :-)
22:20 < nsouch> unfortunatly, we never got GGI's opinion about integrating back KGI into GGI core
22:21 < nsouch> won't it bloat GGI?
22:21 < antrik> wouldn't know why
22:21 < antrik> well, depends on what you mean by "core"
22:22 < antrik> KGI and KGI's accel helpers aren't fundamentally different than other backends, are they?
22:22 < nsouch> yes they aren't
22:23 < antrik> so what's the problem?
22:23 < nsouch> but I don't understand. You want to split KGI because it is bloat with the console stuff but want to integrate it back into GGI
22:24 < nsouch> or you think of the graphic part back in GGI, not the console part?
22:24 < antrik> for me, it was always part of GGI... what I mean is that in my opinion there is no point in having a stronger grouping between the console handling and the graphics drivers than between any other GGI subprojects
22:25 < nsouch> yes, the only reason was the kernel
22:25 < antrik> right
22:28 < antrik> anyways, I hope you are aware that you are presently the last one working on the console stuff, and this is not likely to change any time soon if ever; and that FreeBSD presently seems to be the only kernel remotely interested in this console stuff, which is not likely to change either...
22:30 < nsouch> yes and this gives low weight to my vote, I'm aware of it
22:30 < antrik> don't mean to discourage you; if you feel you can work on it alone, no problem. just don't expect too much :-)
22:31 < antrik> there is another problem though...
22:31 < nsouch> ah, we were about to conclude :)
22:31 < antrik> LOL
22:31 < antrik> sorry ;-)
22:32 < nsouch> what's the problem ? :)
22:33 < nsouch> concerning projects issue, you have to decide with foske and ask GGI now
22:34 < antrik> IMHO you are generally too much set on Seeger's ideas... not only on his design of a complete integrated console system (which is OK), but also on his attitude of "let's make it perfect and then they will see"... while Foske and me want to involve related projects as much as possible from the start
22:36 < antrik> none of the GGI folks seems to be here presently, which is a bit unfortunate considering that I hoped to discuss libggi's role... but then, we didn't really announce the meeting, so we can't complain :-(
22:37 < nsouch> MooZ: ?
22:37 < nsouch> ok, speak about fbdev?
22:37 < nsouch> or whatelse you want
22:37 < antrik> fbdev seems fine
22:38 < nsouch> what do you have in mind for the hurd?
22:39 < antrik> didn't much think about this, to be honest... my point of view is that with a vesa driver almost anything gets basic coverage, and for advanced stuff we have native drivers
22:39 < antrik> (well, hopefully more complete and recent ones in the future...)
22:39 < MooZ> i'm here
22:40 < nsouch> MooZ: what would you think to KGI back into GGI?
22:40 < nsouch> MooZ: do you know bughunter's opinion?
22:40 < MooZ> nsouch, no
22:40 < MooZ> and what do you mean back?
22:40 < MooZ> back in the repository and all
22:40 < nsouch> same project
22:40 < nsouch> MooZ: I guess same repo, yes
22:40 < MooZ> will it be shipped with ggi releases and all?
22:40 < antrik> however, on Linux, people who are using fbdev right now wouldn't want to go back to vesa or wait for native KGIM drivers I guess, so it seems reasonable at least there to implement a display driver using legacy fbdev drivers...
22:41 < MooZ> well i didn't really understand why it was splitted
22:41 < antrik> I think the "reintegration" part is not that much about technical issues; it's rather a formal one
22:41 < MooZ> yes
22:42 < antrik> should we present GGI/KGI as one large project to the outside, or a number of independant projects that just happen to use stuff provided by the others?
22:42 < MooZ> kgi may "reintegrate" ggi but i don't know if ggi releases should include kgi
22:43 < nsouch> antrik: GGI would be like freedesktop somehow?
22:44 < antrik> nsouch: don't think so. freedesktop is about projects that needn't have any close relation at all, except for being somehow related to free desktop environments :-)
22:46 < nsouch> concerning fbdev, Antonino A. Daplas is the maintainer
22:46 < nsouch> I've contacted him and he told me fbdev is now more stable than in the past
22:47 < nsouch> at least since 2.6. The big changes were between 2.4 and 2.6
22:47 < antrik> in the end, I think it depends mostly on how much libggi is willing to cater to the needs of X or other projects we wish to attract... if it turns out libggi is unaccptable to those, and not willing to change, we might have to split out our stuff after all. but I hope that won't be necessary. would be really unfortunate to loose all the great work in libggi
22:49 < nsouch> and would make us manage a libkgi for each os
22:50 < antrik> right
22:50 < nsouch> so back to fbdev?
22:50 < antrik> yes
22:51 < antrik> what you wanted to say is that fbdev is now a feasible backend driver interface?
22:51 < nsouch> I think, yes
22:52 < antrik> all the better. I just hope it won't distract too much from native KGI drivers :-)
22:52 < nsouch> heh
22:52 < nsouch> we could use fbdev for modesetting and concentrate on accel
22:53 < antrik> well, assuming we have this fbdev backend interface, and people start using KGI. it might turn out that people would prefer improving the existing though limited fbdev drivers instead of writing native KGI ones...
22:53 < nsouch> right
22:53 < antrik> hm.. you think it's a feasible approch to have such mixed drivers?
22:54 < nsouch> yes
22:54 < antrik> how would that work?
22:54 < nsouch> fbdev for modesetting and extensions for accel
22:54 < nsouch> KGI would become the glue between fbdev and DRM actually
22:55 < antrik> but that would need a major revamp of the current KGIM stuff I guess?
22:55 < nsouch> I called it... yes because I call things :)
22:55 < nsouch> LFBM
22:55 < nsouch> actually, just to say KGIM no more exist :)
22:56 < nsouch> KGIM is the old HW paradigm
22:56 < nsouch> fbdev is moving without paradigm
22:56 < antrik> well, there is another problem with fbdev drivers: they are not meant to be portable, and being part of Linux they are usually GPL-licensed I guess...
22:56 < nsouch> antrik: I see, your problem is GPL... :)
22:57 < antrik> not mine, but yours :-P
22:57 < antrik> I have no problem with GPL stuff at all ;-)
22:57 < nsouch> :)
22:58 < nsouch> but KGI drivers will always be thirdparty packages for FreeBSD
22:58 < antrik> so you think it's OK if they are GPL?
22:58 < nsouch> yes, because FreeBSD is not embedded
22:59 < nsouch> so binary distribution is not a problem
22:59 < antrik> OK
22:59 < nsouch> gcc is part of freebsd
22:59 < nsouch> is gcc gpl?
22:59 < antrik> I know... but not part of the kernel, I thought that might be of relevance :-)
23:00 < antrik> sure it is
23:00 < nsouch> you're right, but I don't plan to distribute drivers with the kernel
23:01 < nsouch> though this may not be always true for certain archs
23:01 < antrik> well, I do, at least for Linux... would be very awkward for users to get them from a different place IMHO. Alsa was a regular cause of trouble until it was integrated in Linux at last
23:03 < nsouch> thirdparty drivers will provide extensions (higher modes, accel...) but VESA or a basic one can be in the kernel for basics
23:03 < nsouch> KGI permits substitution of graphic drivers on the flight
23:03 < nsouch> if the console supports it
23:04 < nsouch> antrik: I think any fbdev/DRM solution should not be alone. KGI should also work on advanced topics like skids' proposal
23:05 < antrik> not sure what you mean by "alone"
23:05 < nsouch> I meant should not be the only one
23:06 < antrik> right. I consider it only a legacy solution. that's why I'm not sure hybrid drivers are really useful
23:06 < antrik> regarding DRM: do you really think it's possible to reuse the stuff they provide directly?...
23:07 < nsouch> modesetting is boring to tune, so if it exists already...
23:08 < nsouch> concerning DRM: I analysed it a little but could not come to any conclusion
23:08 < antrik> well, but using existing fbdev and/or X drivers as a base, it shouldn't be hard to create native drivers for otherwise already supported hardware...
23:09 < nsouch> if you keep the fbdev unmodified, it's easy to reuse the linuxfb work
23:09 < antrik> not sure it isn't more awkward in the long run...
23:09 < nsouch> currently the accel api does not depend on the modesetting in KGI
23:10 < antrik> but well, I know this story all to well -- we have the same problem with reusing Linux drivers for Hurd :-)
23:10 < nsouch> heh
23:11 < antrik> using unmodified drivers by means of a glue layer is easiest, but pretty ugly and doesn't make full use of the system's possibilities. porting drivers to a native interface OTOH is much more work
23:11 < nsouch> right
23:12 < nsouch> the pb will be bus management
23:12 < nsouch> fbdev will move with linux solution
23:13 < nsouch> but we should propose something OS independent with KGI
23:13 < antrik> obviously... glue code needs updating from time to time. something we are painfully aware of with the Hurd ;-)
23:15 < nsouch> anything more about fbdev&DRM?
23:15 < antrik> yes
23:15 < antrik> the other side so to say
23:15 < antrik> I wonder whether it makes sense for KGI to emulate fbdev API on Linux...
23:16 < nsouch> heh :)
23:16 < antrik> well, today fbdev is in wide use, and many things depend on it... I wonder whether KGI shouldn't provide an emulated fbdev API for easier migration
23:17 < nsouch> KGI is not supposed to be accessed without GGI yet
23:17 < antrik> this way all fbdev stuff could be used directly -- including the fb console
23:18 < antrik> an alternative would be to provide an fbdev wrapper for libggi, using LD_PRELOAD or something
23:19 < antrik> this would be more elegant, but somewhat harder to use, and wouldn't give us fbconsole
23:20 < antrik> not sure whether this is a problem
23:21 < antrik> providing an fbdev legacy interface would be just the easiest way to integrate KGI into existing systems; it might help acceptance
23:21 < nsouch> if KGI API is better, appli will change for it
23:22 < nsouch> otherwise we should just stop now
23:22 < antrik> right. using real KGI interface, applications get acceleration, so there is incentive to switch
23:22 < nsouch> we just need fbdev for backend modesetting
23:23 < nsouch> and to concentrate on accel
23:23 < nsouch> I also thought of a user-level driver development kit
23:23 < antrik> well, using fbdev drivers for the backend and providing an fbdev frontend are mostly orthogonal issues...
23:25 < nsouch> a framework that would reproduce the KGI kernel APIs but to run in userland
23:25 < antrik> they are only related in that they both make it easier to slip the new approach into existing systems in some aspect...
23:25 < antrik> not sure what you mean
23:26 < nsouch> since KGI is portable in kernels, one can propose the KGI api in userland
23:27 < nsouch> and people would have an development kit to write drivers in userland
23:28 < nsouch> of course this mean a glue layer wraps kernel calls to userland to get the HW setup
23:29 < MooZ> i'm off to bed
23:29 < MooZ> i'll read the log tomorrow
23:29 < MooZ> bye
23:29 < antrik> bye
23:29 < nsouch> bye
23:30 -!- MooZ [i=MooZ@FR-CHA-C4-01-02-087231004236.chello.fr] has quit ["Leaving"]
23:30 < nsouch> just a thought anyway...
23:30 < nsouch> speak about repository?
23:30 < antrik> well, there is another question regarding DRM
23:31 < nsouch> yes?
23:32 < antrik> I wonder whether we could/should use it as a base for a new kernel<->userspace API for KGI...
23:32 < antrik> after all, KGI does quite exactly the same as DRM, only wider in scope; and DRM is already established...
23:33 < nsouch> where is the need of KGI then?
23:33 < antrik> see above -- KGI is wider in scope
23:35 < antrik> in fact, I wouldn't have a problem considering it an extension of DRM; I just doubt the DRM creators are much interested in that :-)
23:37 < nsouch> last time i looked at DRM it was to reuse its code for kernel ressource management
23:38 < nsouch> I had in mind to implement skids' proposal and never thought about DRM user api
23:38 -!- blindvt_ [n=bf@M806P018.adsl.highway.telekom.at] has quit [Read error: 110 (Connection timed out)]
23:39 < antrik> well, I don't know too much about DRM either; but from what I gathered, for the narrow part it covers, it does seem to make it right
23:39 -!- blindvt_ [n=bf@M811P028.adsl.highway.telekom.at] has joined #ggi
23:40 < nsouch> antrik: we are thinking both from our respective OS point of view
23:40 < peda> .oO(MooZ should have checked if w00fie was around before stating that he'll read the log later)
23:40 < antrik> ?
23:40 < antrik> peda: I'm logging with my client; unless it crashes, I'll put up the log
23:41 < peda> I'm with MooZ, I don't understand why kgi was split out. IMO it could quite happily live next to xggi.
23:41 < peda> antrik: Ok, good for MooZ... :-)
23:41 < nsouch> DRM and fbdev integration has never been considered before us in the KGI project
23:41 < antrik> peda: IMHO not only it could, it actually *should* :-)
23:42 < antrik> nsouch: I know... didn't expect any decisions, just some discussion :-)
23:43 < nsouch> antrik: people who decide things is people who do things
23:43 < nsouch> AFAIK we are the only three (with foske) willing to do
23:43 < antrik> right. but I have no strong opinion on these issues myself, so I certainly want input before I even consider implementing any of this
23:45 < nsouch> after all these discussion, we will come rapidly to the point where either we decide to code something, or all them will be garbaged
23:45 < antrik> also note that the fbdev frontend idea is Linux-specific (though other platforms already having a native framebuffer inteface might consider something similar), so it's not very likely I'll ever actually work on this myself
23:46 < antrik> it was more of a suggestion
23:46 < nsouch> ok. So about repository?
23:46 < peda> As is, you'll get the feeling that kgi has been denounced not only by kernel people, but by ggi as well. It hints at fractioning within the ranks...
23:47 < antrik> repository is actually something I'd like to decide as soon as possible, so I get in not trouble when starting the Hurd port; but it's also something we probably can't decide without Foske...
23:47 < peda> (or bughunter)
23:48 < nsouch> yes, bughunter if you really want ggi repo integration
23:48 < antrik> right
23:48 < peda> with that precondition, of course
23:48 < antrik> I'm not sure I ever asked his opinion on that...
23:49 < antrik> but presently I care more about repository organization than hosting
23:49 < nsouch> bughunter won't like a tree in ggi's repo that is maintained like the kgi/kii targets
23:50 < peda> I had a look at one kgi tree and it seemed alien, I didn't understand the build system at all (but didn't look for very long)
23:50 < nsouch> peda: I looked right :)
23:51 < antrik> I already suggested that it might make sense to try moving to freedesktop.org and forget about SF... (well, for GGI too)
23:51 < peda> nsouch: What?
23:51 < antrik> peda: that's the first thing I want to change :-)
23:52 < antrik> the kgi-0.9 build system is really really crappy
23:52 < nsouch> I meant you understood what it is : bloat
23:52 < peda> antrik: Probably wise to shape up then, if you want to attract developers. But you knew that  :-)
23:53 < peda> nsouch: Ahh, you meant "You looked right", not "I looked right"...
23:54 < nsouch> peda: haha, yes
23:54 < nsouch> antrik: I'm not sure freedesktop is a good choice
23:55 < nsouch> jon smirl was banned because he had a different position regarding nvidia drivers integration in X
23:55 < peda> I think X when I hear freedesktop.
23:55 < antrik> nsouch: I don't think this was really political, in spite of his accusations
23:56 < antrik> nsouch: I belive it was just honest stupidity on the admin's side
23:56 < nsouch> antrik: so how do you see the new compilation framework of KGI?
23:57 < nsouch> at least for linux to make the discussion simple
23:57 < nsouch> the kernel size is really a problem
23:58 < antrik> why? at least the SF guys didn't object, and in my local tests there were no big performance issues as well
23:58 < antrik> (note that the x.org tree isn't much smaller than Linux)
--- Log closed lun fév 20 00:00:08 2006
--- Log opened lun fév 20 00:00:08 2006
--- Day changed lun fév 20 2006
00:00 < peda> Baby has fallen asleep, so I have no longer anyexcuse for staying up...
00:00 < nsouch> heh
00:00 < antrik> peda: hehe
00:00 < antrik> peda: good night then :-)
00:00 < nsouch> peda: wake him up
00:02 < nsouch> antrik: I agree about having the freebsd, linux, hurd code at the same place but I don't see how we can share the same code
00:02 < peda> BTW, libgii 1.0.0 was packaged by my for Cygwin the other day, I expect libggi 2.2.0 to go in tomorrow (it already gotten approval, it just needs to be uploaded by core people), read the annoncement tomorrow if all goes well...
00:02 < peda> otb
00:03 < peda> 8don't think I'll wake him up... :-)
00:03 < peda> s/8/(/
00:04 < nsouch> antrik: do you take the action asking bughunter about the repo integration
00:04 < nsouch> ?
00:04 < antrik> nsouch: yes
00:05 -!- buju [n=antoine@peanut.dreadbsd.org] has quit ["zz"]
00:06 < antrik> regarding shared source, I'm not so sure myself
00:06 < nsouch> will you keep kgidrv building tree?
00:06 < antrik> considering that the part that I'm actually interested in isn't that large, it might not make much sense indeed...
00:07 < antrik> I guess I should actually take a closer look at the KGI code before making suggestions on such issues :-)
00:08 < antrik> you mean kgidrv built in an external tree outside the kernel?
00:08 < nsouch> yes, I think it's necessary
00:08 < antrik> well, I think it's awkward :-) I want them build right inside the kernel (or KGI server on Hurd)
00:08 < nsouch> antrik: I asked about the compilation engine itself
00:10 < antrik> compilation engine?...
00:10 < nsouch> yes, the ./configure calling sh functions
00:11 < antrik> well, if I integrate the kgidrv tree into Linux, there won't be any ./configure; it will need to use the Linux make system on Linux
00:11 < antrik> (on Hurd, it will use automake)
00:11 < nsouch> antrik: we disagree on many issues... what make us finally work on the same project?
00:11 < antrik> a misunderstanding ;-)
00:12 < nsouch> you want the code at the same place, but if you use per OS make system, you'll duplicate the code...
00:13 < antrik> when I joined KGI, I thought it was still basically what it was in the beginning: the in-kernel graphics hardware access component of the GGI framework
00:13 < antrik> no, only the make system needs duplication
00:14 < antrik> I wonder how DRM deals with that...
00:14 < nsouch> each OS tree has its DRM
00:14 < antrik> yes, but the actual drivers are portable
00:15 < antrik> (I didn't know that myself until recently...)
00:16 < nsouch> so what's the roadmap for you?
00:16 < antrik> my original plan was first to come up with a repository organization, make it work for Linux, and start porting to Hurd
00:17 < nsouch> do you know how long it would take?
00:17 < antrik> by now, I wonder whether it's not better to start porting right away, and think about repository organization along the way
00:18 < nsouch> you will start from foske's code
00:18 < nsouch> ?
00:18 < antrik> however, I'm not sure whether I should start porting the 2.4 stuff, or better wait for Foske to finish his 2.6 port
00:18 < antrik> I guess his code is closer to what I need
00:19 < nsouch> you should wait since he's also removing the console code
00:19 < antrik> right
00:19 < nsouch> but a long can you wait?
00:19 < antrik> though I'm not sure this is a big issue
00:20 < nsouch> do you have a schedule in mind?
00:20 < antrik> good question... it's not very urgent presently (I slipped the semester start again, so I wan't be able to officially start my thesis sooner than in 7 months or so), but I think I should actually start getting some work doen, instead of just waiting and discussing...
00:22 < antrik> maybe his work so far is actually sufficient for me to start; IIRC it wasn't anything major that's still missing... I guess I should ask him to put it up somewhere temporarily until we have set up a proper repository
00:23 < nsouch> yep
00:23 < antrik> ah no, not quite right. he said that the console works IIRC, but graphics programs don't do so far. so I couldn't really test it before starting the port, which is really a downside
00:24 < antrik> my main concern is to start from something that I know it works and know under which conditions
00:24 < nsouch> yes, of course
00:25 < antrik> anyways, asking him to put up his code is probably a good idea still :-)
00:26 < nsouch> antrik: do you think we have covered enough topics?
00:26 < antrik> well, there is another concern I have. it looks like we will do some considerable changes to KGIM and stuff in the not so distant future, and I'm not sure it's really worthwhile to port the existing stuff... but I guess there is no choice; I can't wait for the redesign
00:27 < antrik> I didn't set any minimum ;-)
00:28 < antrik> you'd like to go to bed I guess?
00:29 < nsouch> not too late yes, but let's speak a bit about the hurd port orientation
00:29 < antrik> orientation?
00:29 < nsouch> ha, direction
00:30 < nsouch> french and english share words with different meaning :(
00:31 < nsouch> the choice you have to face is the downside of changing KGI design right now
00:31 < nsouch> I would the same choice with FreeBSD
00:31 < antrik> no idea what you mean :-(
00:32 < nsouch> I mean concerning the adoption of a design or another of KGIM, if you port the existing one, or wait
00:33 < nsouch> I'm facing the same dilemna with FreeBSD and it worries me
00:34 < antrik> as I said, I don't think I really have a choice. the new design probably won't materialize soon enough
00:34 < antrik> hm... what things do you want to work on next?
00:34 < nsouch> but your port may become obsolete before end
00:36 < nsouch> personally, I'm a bit in expectancy because I have no idea where all these discussion will actually go
00:36 < antrik> hm...
00:37 < nsouch> it is not the first time famous ideas came to the project but the reality is different
00:37 < antrik> I don't think it will change too much regarding the console stuff, so unless the things you need to work on right now are in the graphics hardware handling, it shouldn't be a problem I guess...
00:39 < antrik> well, Foske's ideas aren't really new; it's just now that most of Seeger's supportes dropped out, they meet less opposition :-P
00:42 < antrik> or what ideas do you mean?
00:44 < nsouch> Foske wants to hack graphic drivers/HW and he's not concerned by abstraction of APIs
00:45 < antrik> well, but he is interested in keeping KGI minimal...
00:45 < antrik> anyways, what ideas *do* you mean?
00:47 < nsouch> I meant about organizing, compiling, synchronizing, managing
00:47 < antrik> hm... but none of those affect the existing code too much, I'd say...
00:48 < nsouch> many people asked to change, proposed to change and each time it went nowhere, this is why I'm wondering
00:49 < antrik> OK, I can't say anything on this, as I haven't been around at that time
00:51 -!- bughunter [n=bughunte@t-194-095-230-190.zip.shuttle.de] has quit ["This computer has gone to sleep"]
00:51 < nsouch> the next discussions will depend on our respective progress
00:52 < antrik> progress with what?
00:52 -!- soyt [n=eric@ekyo.pck.nerim.net] has quit ["Leaving"]
00:53 < nsouch> for foske to work on the so called new driver layout, for you on the repositories, for me on the freebsd port
00:54 < antrik> hm... right
00:54 < nsouch> if the console is no more of use in the KGI environement I have to think about some project reorganisation too
00:55 < antrik> in fact, we are doing two things in parallel right now: improving what we have now, and trying to get KGI more accepted
00:55 < antrik> some questions we are discussing here are related more to the former, some to the latter
00:57 < nsouch> what I thought was a freebsd port is becoming more or less a freebsd project
00:57 < antrik> yes, regarding the console stuff, that's probably true
00:58 < antrik> in fact, that's what I was aiming at with my initial comments
00:58 < antrik> but it still depends on the hardware graphics access, and this part is and will remain a multi-platform effort
00:59 < antrik> graphics hardware access I mean :-)
01:01 < antrik> note that the console stuff doesn't really share the special properties of graphics drivers that makes them candidates for system independance; so there is little interest in having a multi-platform console system
01:04 < nsouch> KGIM is dead before end, I'm looking forward Foske proposal of replacement
01:05 < antrik> right. but this will probably be a longish process
01:05 < nsouch> meanwhile, I'm going to think about some redirection of kgi4BSD on one hand and fbdev integration on the other hand
01:06 < antrik> OK
01:07 < nsouch> shall we end now?
01:07 < antrik> seems like a good moment :-)
01:08 < nsouch> g'd night then :)
01:08 < antrik> good night
06:41 -!- alastair [n=agh@220-244-72-6.static.tpgi.com.au] has joined #ggi
07:03 -!- antrik [n=olaf@port-212-202-210-123.dynamic.qsc.de] has quit ["bye"]
07:35 -!- soyt [n=eric@ekyo.pck.nerim.net] has joined #ggi
07:38 -!- blindvt_ [n=bf@M811P028.adsl.highway.telekom.at] has quit [Read error: 110 (Connection timed out)]
07:39 -!- blindvt_ [n=bf@M891P012.adsl.highway.telekom.at] has joined #ggi
08:38 -!- blindvt_ [n=bf@M891P012.adsl.highway.telekom.at] has quit [Read error: 110 (Connection timed out)]
08:39 -!- blindvt [n=bf@M920P026.adsl.highway.telekom.at] has joined #ggi
08:49 -!- alastair [n=agh@220-244-72-6.static.tpgi.com.au] has quit [Read error: 110 (Connection timed out)]
08:54 -!- alastair [n=agh@220-244-72-6.static.tpgi.com.au] has joined #ggi
09:00 -!- rohara [n=xyxyxyxy@ip70-171-72-167.no.no.cox.net] has quit ["Client exiting"]
--- Log closed lun fév 20 09:57:55 2006