[17:01] <Foske> First I want to make compliments about the progress we made in the last months
[17:02] <ortalo> ok. (someone volunteer to coordinate?)
[17:02] <Foske> ok.. top of the list: the crt driver
[17:02] <Foske> is it good enough to replace everything else
[17:02] <golbez> I think so.
[17:03] <skids> I am fine with the CRT driver being the default, but a few caveats:
[17:03] <skids> 1) Should be integrated smoothly into build system
[17:03] <skids> 2) Failure to set valid timing when DDC1 fails on Radeon
[17:03] <skids> (valid timing negotaited, but doesn't take)
[17:03] <skids> 3) DDC2 would be really nice (otherwise people have to power cycle
[17:03] <skids> monitors if they run a DDC2 app.)
[17:03] <bughunter> How does it handle plasma, lcd, tft displays?
[17:03] <Foske> IMHO it is, though we need an option to tell the driver not to do ddc
[17:03] <Foske> bughunter: My tft eats the mode just fine
[17:03] <bughunter> ok
[17:04] <bughunter> someone here is plasma and/or lcd displays?
[17:04] <bughunter> s/is/with/
[17:04] <Foske> though there is a minor issue that I want in future...
[17:04] <philbo_> skids: 1) assumedly fixed once it becomes default 2) will need to work on that, any help appreciated (i.e., works here)
[17:04] <Foske> I am working on DDC2. can't do anything more than say that :)
[17:05] <skids> bughunter: crt will be better on a lcd than the other drivers, because at least it bothers to ask the lcd what it can do, the other drivers just fly off and send what they think is a "standard" mode but the LCD might have a different opinion on that matter.
[17:05] <cow> a) what was that stuff with reversed order of found modes from monitor? b) who will (? needed?) fix the mode-negotiation loop regarding LOWER/RAISE?
[17:05] <Foske> A tft has a "preferred mode", for me it is 1280x1024 @ 60 Hz. this is part of the DDC data. this means if the user requests a default mode, the monitor driver should propose it, not the chipset driver
[17:06] <philbo_> Ok. Since nobody seems to be radically against it, it's agreed on. I volunteer to do the work of getting rid of the rest (should be a good exercise in understanding the build system). Any concerns should be directed to me.
[17:06] <ortalo> I should really try something different from the SVGA driver for the monitor! ;-)
[17:06] <bughunter> then the crt driver should have a name sounding more generic like "unimon" or something like that, to not confuse users.
[17:06] <ortalo> bughunter: good idea
[17:06] <bughunter> I am pretty sure, that user will come and ask "can I use it on my tft?"
[17:07] <philbo_> but they all support crt timings! it's a driver for all display devices that support the crt way of setting display mode
[17:07] <cow> bughunter, ortalo, i tend to agree with philbo that "crt" does match quite well
[17:07] <Foske> okay. philbo_ will start the cleanup. what about my comment ?
[17:07] <golbez> Does it really matter when the monitor driver is compiled into the display driver. It is rather transparent to the user...
[17:08] <Foske> no reactions ?
[17:08] <cow> i do not see why we should rename a directory (in cvs!) as users are _NOT_ supposed to be bothered with it when it is the default monitor driver.
[17:08] <philbo_> Foske: I'm for transferring the responsibility for setting the default resolution on TC_PROPOSE from the chipset driver to the monitor driver
[17:09] <Foske> crt definitely is wrong, but ok. make it general for now ?
[17:09] <skids> Keeping the dir is fine IMO, just the configure system should call it something other than crt.
[17:09] <bughunter> philbo_: Independent of the common technical base, user thinks, those are different (because they look different?)
[17:09] <Foske> it is in the monitor dir already
[17:09] <skids> As in, the front page menu where you select the driver.
[17:09] <philbo_> cow: what do you mean by the fixing of the mode negotiation loop
[17:09] <ortalo> If there is not DDC, can the monitor propose a decent default mode?
[17:10] <Foske> ortalo: only with parameters about the monitor applied
[17:10] <skids> ortalo: if you tell it it's limits via insmod.
[17:10] <philbo_> ortalo: only if you manually specify limits because ther is no decent default that all monitors will support
[17:10] <Foske> okay, details will follow in a document I'm going to write on the driver.
[17:11] <cow> skids, the config-system will not provide a choice for selecting the "monitor"stuff anymore. just the boards which have to build (which should be "all" sooner than later anyways; e.g. either fix or hide the TNT2 thing from configure)
[17:11] <Foske> philbo: can you rearrange the proposal loop while you work on the cleanup ?
[17:11] <Foske> I'll do the ddc2 stuff asap
[17:12] <Foske> more comments that need everyones attention ?
[17:12] <philbo_> Foske: should be trivial, I'll add to your document what change to the chipset drivers is neede (basically only matter of *not* setting the resolution when it is 0,0)
[17:13] <skids> OK, then the last thing is, what do we do with all those hard-earned timing lists and frequency ranges?
[17:13] <Foske> philbo: ok
[17:13] <bughunter> cow: When you are about fixing up the dialog - could you fix it up for 80 column textmodes, please?
[17:13] <philbo_> skids: there are no hard earned timing lists (the crt driver has the greatest list of all the drivers in cvs), for the range we need a .spec->arg script
[17:14] fraggle has joined #kgi
[17:14] <Foske> skids: imho they were crazy from the beginning, for now we could store them somewhere, so we could use them in a user level config tool
[17:14] <cow> philbo, the mode negotiation currently checks against the monitor if all other subsys already agreed. iirc i locally had to run through four loops to get a (somewhat) proper mode as my crap monitor is limited to a quite low resolution which the other subsys need to be lowered to match
[17:14] <bughunter> fraggle: hi
[17:14] <skids> philbo_: I don't know about you, but I spent a good deal of googling trying to get the HP timing list.
[17:14] <fraggle> hiya
[17:14] <Foske> philbo: it isn't that easy maybe. has to be checked out.
[17:15] <skids> That database isn't exactly complete, but it does have some data well worth preserving.
[17:15] <philbo_> skids: ok. Let's make a script for those too then. (the crt driver has a parameter for specifying extra timings)
[17:15] <Foske> okay. please keep the database for later use on the command line, but remove everything else not crt-related
[17:15] <skids> Should the CRT driver have an option to build-in timings, top be used as a boot driver?
[17:15] <bughunter> fraggle: Which OS/hw-arch do you run?
[17:16] <cow> ohm and someone should document the module params thoroughly and in depth
[17:16] <Foske> cow: I will
[17:16] <Foske> next subject ?
[17:16] <ortalo> yes (if no one objects)
[17:16] <Foske> default keymap is broken
[17:17] <philbo_> skids: I suppose, yes. Let's leave that till we can actually use the drivers as boot drivers.
[17:17] <ortalo> What is this problem? (First time I hear of it I think.)
[17:17] <Foske> when you compile KGI from scratch, starting an app on ALT-F1 opens a graph that maps to ALTGR-F2
[17:17] <ortalo> With graphic minor at 0?
[17:17] <Foske> indeed
[17:17] <nsouch> Foske: is that keymap related?
[17:18] <Foske> nsouch: someone here said that, I assumed it was an off by one calculation somewhere
[17:18] <ortalo> That's a compiled-in keymap? (I usually need to use loadkeys myself before ALTGR works)
[17:18] <Foske> ortalo: yes, the .de keymap actually
[17:18] <philbo_> from my experiments, it is indeed keymap related. The default keymap has altgr mappings wrong
[17:18] <skids> philbo: I'm fine with waiting on bootable-crt, too.
[17:18] <bughunter> kgi still finds two keyboards - one AT and one PS/2
[17:19] <cow> is minor 0 trusted even on non-devfs systems, btw? if so we should reflect this in cvs....
[17:19] <Foske> cow: it is trusten completely now
[17:19] <skids> Is there an opensource "keymap editor"?
[17:19] <bughunter> though I have physically one AT keyboard connected to ps/2 via an at->ps/2 adapter.
[17:19] <philbo_> (just did a quick check and pressing altgr-f4 wants to go to console 66, one off)
[17:19] <nsouch> where one can find loadkeys by the way?
[17:19] <Foske> philbo: exactly, that is the issue
[17:20] <philbo_> nsouch: console-tools. Look for it on sourceforge
[17:20] <Foske> should be 67
[17:20] <philbo_> Foske: 65 actually
[17:20] <Foske> no, 64 + 4 - 1
[17:20] oxygene has joined #kgi
[17:20] <bughunter> oxygene: hi
[17:21] <oxygene> hey bughunter
[17:21] <philbo_> Foske: right. My bad.
[17:21] <Foske> whe need someone to look at this
[17:21] <Foske> we too
[17:21] <Foske> I'm lost in the keyboard code...
[17:21] <skids> philbo_: you and I just made the same thinko. Scary.
[17:21] <philbo_> I've done some keycode stuff lately, so I guess I can fix that.
[17:22] <Foske> philbo_: oh, you can add that to your list ?
[17:22] <philbo_> Foske: sure. It should be quite easy to fix anyways.
[17:22] <Foske> next subject then: snapshotting / releasing kgi.
[17:22] <cow> who will focus on satisfying loadkeys and fixing keymaps as soon as possible? that one really should be top priority, although it is unsexy to fix, granted
[17:22] <bughunter> Regarding "debian packages, snapshots. too early?":
[17:22] <bughunter> There are several possibilities:
[17:22] <philbo_> cow: you mean strings?
[17:22] <bughunter> a) we go the BSD way: Develop deep changes in a branch and merge it to -current, where -current is the main cvs tree (advantage: main CVS tree is always stable)
[17:22] <bughunter> b) we make a snapshot, break everything, stable everything, make another snapshot
[17:22] <bughunter> c) we make a snapshot and open a devel and a stable branch as we do for GGI
[17:22] <Foske> bughunter hold back a little...
[17:23] <philbo_> bughunter: that's awfuly involved. We just need something that woudl be easy for people to try. Right now just get a kgi enabled kernel is a pretty major pain.
[17:23] <nsouch> c)
[17:24] <ortalo> c)
[17:24] <Foske> I vote for c for now, and we should have a list what to do before we release a real version
[17:24] <skids> Debian users pretty much expect .debs to be drop-in and more or less production quality. At the very least, any .deb package set
[17:24] <skids> should create all the device files and deal with any init/config file conflicts like loadkeys. (Or we could just FIX the loadkeys thing :-)
[17:24] <cow> c)
[17:24] <cow> but what about loadkeys? i won't do it.. so any takers?
[17:24] <Foske> anyone feeling to take this one ? with sourceforge help it should be easy
[17:24] <skids> c) for me as well.
[17:25] <skids> Isn't it KGI, not loadkeys, that's broken?
[17:25] <nsouch> kgi-wip standing for -current, kgi for -stable?
[17:25] <philbo_> cow: I can look into it, but can't promis anything. Is it really that necessary?
[17:25] <skids> i.e. Linux VT emulation?
[17:25] <ortalo> It would be nice to have something like a kgi-kernel Debian package too. But maybe it is a pretty difficult task (that's the kernel).
[17:25] <Foske> nsouch: we have no control of kgi tree, but we can abuse the cvs of it as the stable tree, yes
[17:25] <cow> c) with "stable" and "HEAD" that is. anything else is unacceptable. string-nitpick, though ;)
[17:26] <skids> ortalo: It is, because to do it right your patch has to be reversable.
[17:26] <ortalo> skids: why?
[17:26] <cow> philbo, we really have to fix it asap, yes
[17:26] <njs> Shouldn't you be keeping both the stable and development trees in a single cvs repo, to make merges easier?
[17:26] <bughunter> nsouch: We can do so, once steffen is back (at least, when he gave us CVS write access)
[17:27] <skids> It has to work with make-kpkg utility, which allows you to choose the patch-set.
[17:27] <Foske> a few of us has write acces, don't they ?
[17:27] <nsouch> njs: you're right
[17:27] <Foske> well ok.. single cvs repo
[17:27] <skids> I could try write access again but last time I did I think my auths were stale or something.
[17:27] <Foske> kgi-0.9 tree and a kgi-current tree ?
[17:27] <philbo_> cow: ok. I'll put it higher on my list then.
[17:27] <ortalo> single cvs repo is probably much wiser...
[17:28] <cow> skids, i think it is KGI, yes. we need to \"satisfy loadkeys\" e.g. verify and write the fn_string stuff proper, somehow
[17:28] <cow> philbo, great
[17:28] <nsouch> Foske: no same repo, same trees
[17:29] <Foske> okay, volunteers for the cvs tree stuff ?
[17:29] <nsouch> just tags to maintain branches
[17:29] <cow> Foske, kgi-0.9 module, branch "stable" and our normal HEAD. i will tag the stable branch, soon, if nobody objects
[17:30] <Foske> okay. cvs "split" assigned to cow
[17:30] <cow> ack
[17:30] <skids> Shouldn't it BE stable first? :-)
[17:30] <nsouch> note that branch points are needed to track branches
[17:30] <philbo_> skids: didn't you hear? assigned to cow :-)
[17:30] <bughunter> For the branch tag we should use a clean namespace to not come into naming conflicts later with multiple branches.
[17:30] <cow> skids, indeed. that's the 'soon' part :)
[17:30] <Foske> skids: we should rework some of the core stuff, I don;'t want to do that while we're so close to something stable
[17:30] <ortalo> Probably... Cow, please, do a full committers roundtable before actually create the tag...
[17:31] <cow> philbo, heh!
[17:31] <cow> ortalo, ok
[17:31] <bughunter> I suggest to use the 'branch_' or 'branch_' scheme for branch tag names.
[17:31] <cow> bughunter, no
[17:31] <Foske> veto
[17:31] <Foske> :-P
[17:32] <Foske> details have to be worked out later (we got real issues later on, so I want to keep this short now)
[17:32] <ortalo> I' rather tag with "kgi_0_9" , "kgi_0_9_2", etc.
[17:32] <Foske> cow will be on it.
[17:32] <ortalo> Untill "kgi_1_0" of course...
[17:32] <nsouch> ortalo: yep
[17:32] <skids> OK, so we make it stable, and then cow tags it stable... next subject?
[17:32] <Foske> issues that need to be said about this now ?
[17:33] neiljp has joined #kgi
[17:33] <bughunter> neiljp: hi
[17:33] <Foske> libggi's kii target needs fixing
[17:33] <philbo_> the kii issue is kind of selfish, because I need it to have a working xggi on kgi ;-)
[17:33] <skids> When I added the auto-open of the KII target I found that it will
[17:33] <skids> open /dev/event twice if GGI_INPUT is also set. Got to figure out
[17:33] <skids> how to keep it from doing that...
[17:33] <neiljp> bughunter: hi
[17:33] <Foske> bughunter: is this something for you ?
[17:33] <neiljp> did I miss the entire meeting?
[17:33] <bughunter> foSke: libggi's ? You mean libgii's kii target.
[17:33] <njs> neiljp: ongoing
[17:33] <cow> bughunter, it already is -0.9; that is enough. fix it up for good, combined with a rewrite of hairy parts and we could argue about an kgi-0.10 module, if you really want
[17:33] <neiljp> cool :)
[17:33] <Foske> err of course
[17:33] <neiljp> njs: ta
[17:33] <Foske> filip made a typo :)
[17:33] <bughunter> neiljp: no, but you missed the first two topics... :)
[17:33] <skids> neiljp: We're not even through with the "quick and easy" topics yet! :-)
[17:34] <bughunter> s/two/three/
[17:34] <neiljp> skids: ah, damn, I knew I should have been here just for those topics ;)
[17:34] <Foske> okay, what is the issue with it ?
[17:34] <philbo_> the kii's target .label field on events is totally bogus
[17:34] <philbo_> the inspiration for fix should probably come from linux_kbd
[17:35] <skids> Is that why enter don't work in demo?
[17:35] <philbo_> skids: could be.
[17:35] <Foske> cow: oh, don't forget to make some snapshots too :)
[17:35] <Foske> anyone on the ggi site that wants to look at it ?
[17:36] <philbo_> It's a mess but it's the last part of making libggi/libgii fully useable on kgi
[17:36] <bughunter> philbo_: Or linux_evdev...
[17:36] <Foske> bughunters todo list is still empty ? :)
[17:36] <skids> sorry, random thought there.
[17:36] <philbo_> bughunter: say, you seem to know a lot about that :-)
[17:36] <Foske> He wisely became silent
[17:36] <bughunter> foSke: hehe - no. It is full.
[17:37] <Foske> bughunter: too full to take this one extra ?
[17:37] <nsouch> cow: and tags before huge changes
[17:37] <bughunter> foSke: I am working on targets for macosx/darwin, I am working on libgpf...
[17:37] <philbo_> well, lets move on. People know about the issue. If anyone has nothing to do at some point in the future, they can look a it.
[17:37] <Foske> oki
[17:37] <skids> philbo_: I'll take it.
[17:37] <nsouch> example from freebsd tree: RELENG_5_0_0_RELEASE: 1.26
[17:37] <nsouch> RELENG_5_0: 1.26.0.2
[17:37]
[17:37]
[17:37] <Foske> okay. asigned to skids
[17:38] <philbo_> skids: great
[17:38] <bughunter> philbo_: Today, I had a deeper look into linux_evdev for improving libgii's input driver for macosx/darwin. :)
[17:38] <Foske> next subject: restorint previous devices after closing one
[17:38] <Foske> restoring too
[17:39] <nsouch> bughunter: don't you have vgl under darwin?
[17:39] <Foske> after closing a graphical device, it remains displayed
[17:39] <philbo_> The proposed fix is to just go back to where the app was started from. But what if there is no such device (app started remotely) or it disappears in the meantime (higly unlikely)
[17:39] <bughunter> philbo_, skids: But I am there, when I get bitten by bugs by libgii's kii... :)
[17:39] <bughunter> nsouch: no.
[17:39] <bughunter> nsouch: There's no vgl under darwin.
[17:40] <skids> I liked the model where each console "slot" had a graphics and a text device associated with it, and when a graphics app terminated it would go back to the corresponding text vc,
[17:40] <ortalo> skids: I second this behavior.
[17:40] <skids> you could switch between graphics/text with another key (maybe ALT-ESC) and the system remembered with mode (graphics or text) each slot was in.
[17:40] <skids> s/with/which/
[17:40] <skids> However, as philbo pointed out, we need to think about how this would
[17:40] <skids> work in each of the various configurations multi-head can assume.
[17:40] <philbo_> skids: even if the graphics device opened doesn't correspond? I can open /dev/graphic4 from console 1. Would that thow me back to the login screen on console 4?
[17:41] <Foske> easy: opened from console 1, so return to console 1 ?
[17:41] <Foske> err
[17:41] <Foske> hmzz
[17:41] <philbo_> Foske: righ. But what about apps run remotely?
[17:41] <bughunter> skids: You mean, to display a (text) menu with ALT-ESC as like as Novell Netware does with CTRL+ESC?
[17:41] <Foske> well, I assume the login was displayed before on the display...
[17:42] <skids> I think the problem is that we haven't even considered the basics of multihead console switching, nevermind text vs graphics.
[17:42] <nsouch> skids: you don't have an xterm for every X appli...
[17:42] <skids> nsouch: true, but that's a UI decision. I think the above gives a natural "multiple DOS 6.2 boxes" feel.
[17:43] <skids> s/2/22/
[17:43] <Foske> I think, go back to whatever was displayed before, will do it
[17:43] <philbo_> How bout going back to where the app was started from and if there is no such device then just go back to the first device on the display (which would be the first console). Arbitrary choice seems better than no device being mapped whatsoever (especially since this cases is unlikely, who needs to run graphical applications remotely)
[17:43] <skids> bughunter: no, alt-escape would go to text from graphics, or from text to graphics if there was a graphics app running in that slot.
[17:44] <nsouch> what is text if no text mode support by the board?
[17:44] <skids> philbo: Well, if you're going to do it that way, you probably should just go back to the last text VC explicitly requested.
[17:44] <Foske> if whatever displayed before doesn;t exist, go to related console. if related console doesn;t exist, display last console mapped to that device. If no consoles mapped to the device display nothing or a KGI logo
[17:44] <cow> is that what i mean by (asummed there is vt, that is) how to trap openvt -s -- logout
[17:45] <skids> nsouch: if no text mode is supported by the board, then naturally the app must have not been started from a vc on the board so...
[17:46] <ortalo> ... KGI logo.
[17:46] <nsouch> ortalo: text or graphic? :p
[17:46] <philbo_> skids: you think so? For example currently when x crashes it throws you back to where it was started form no matter which vt you were on most recently. Seems pretty intuitive to me.
[17:46] <Foske> if a board supports no consoles, it switches back to the previous graphic mode set, if no such mode (no graphic consoles left open on that display), power management seems a good option :)
[17:47] <cow> we're hanging in the void for that case, currently as the kbd handler has no focus or the like
[17:47] <skids> philbo: Actually I find that more annoying than intuitive, like when I kill X from the command line and it chucks me to another VT.
[17:47] <philbo_> cow: I'm not quite sure about what would that do. I suppose I should experiment with that
[17:47] <Foske> skids: you forget X has no focus then !
[17:48] <skids> Foske: ?
[17:48] <Foske> you kill ANOTHER console, so nothing should happen if that maps to the same display
[17:48] <philbo_> skids: hrm good point.
[17:48] <Foske> another (graphical) console
[17:48] <cow> philbo, i experimented with that one a while ago and as long as we do not have a 'global' active kbd handler we probably should fallback to the last (whatever this might be) focus
[17:49] <ortalo> It seems to me there are pro and cons to every behavior. But, globablly, the thing that emerges, is to go back to the last known mode on the head.
[17:49] <Foske> if (has no focus(killed_display)) do nothing
[17:49] <Foske> or something
[17:49] <Foske> err if (not displayed())
[17:49] <skids> Shouldn't the console system be a loadable module itself anyway? Like so you can choose your flavor?
[17:49] <nsouch> maybe the strategy should be configurable
[17:50] <cow> philbo, i'd be interrested to help in handling that case, though. it's an interresting problem, or design problem if you like
[17:50] <philbo_> cow: well, I have no idea about the issues involved here (and I suspect neither has anyone else here besides you) so lets defer that till more of us gather some information about the problem
[17:50] <skids> There's no reason not to have it N ways.
[17:50] <nsouch> among static rules of course
[17:50] <cow> philbo, k
[17:50] <Foske> yeah ! have it N ways ! so noone can work on somebody elses computer !
[17:50] <Foske> :)
[17:51] <Foske> anyway, somebody wanting to volunteer to check this out ?
[17:51] <philbo_> ortalo: last known mode requires an arbitrarily large stack of 'previous' as they can disappear
[17:51] <nsouch> set -o vi and see what happens!
[17:51] <Foske> I guess the problem is clear
[17:51] <cow> so what about the logo thingy?
[17:51] <skids> What's the easiest one to implement in the short term?
[17:51] <Foske> cow: is nice, though DPMS power management is a nice one too.
[17:52] <philbo_> Foske: I can take it as I have pretty good idea where it would go
[17:52] <Foske> philbo: you are not overloading your todo list ?
[17:52] <cow> Foske, philbo? nah, he never would :P
[17:52] <Foske> :)
[17:52] <Foske> okay then
[17:52] <philbo_> Foske: no no, most of the things I volunteered for are simple fixes once agreed on. (except for the crt stuff that is)
[17:53] <Foske> oki
[17:53] <philbo_> cow: you want a new logo?
[17:53] <Foske> this one is easy too (except for the rare non-console cases)
[17:53] <cow> skids, what exactly were you thinking of (logo-wise, iiuc)
[17:53] <Foske> name noted.
[17:53] <cow> philbo, skids seems to
[17:53] <Foske> SMP issues and fast_ functions
[17:53] <Foske> my favourite :)
[17:53] <skids> cow: well, "The Right Thing To Do" is a bit preachy IMO, but mainly, s/GGI/KGI/
[17:54] <philbo_> skids: we might want to put a smiley there
[17:54] <philbo_> Foske: mine as well
[17:54] <Foske> okay. as you all might have read on the mailinglist, I fixed SMP related issues by removing our own code, and replacing it by official kernel code
[17:54] <cow> philbo, that'd be proper, yes
[17:54] <skids> I have always been in favor of a big orange "It is now safe to turn *ON* your computer"
[17:55] <Foske> not everything is set now, but basic SMP support should work.
[17:55] <skids> But that should wait until we have high security/stability.
[17:55] <Foske> It becomes very clear to me that we have always ignored the need of locking
[17:55] <philbo_> I propose removing the fast_ functions. They are old hard to maintain and we don't really get much benefit from them
[17:55] <nsouch> shouldn't we start with a giant lock?
[17:56] <nsouch> then reduce the grain
[17:56] <Foske> philbo: I agree, though we shouldn;t ignore ortalos remarks regarding the accel
[17:56] <cow> skids, so.. want to remove the kernel-config option for now until we settle on a new logo as it is likely that no new users will be interrested to debug eraly boot?
[17:56] <bughunter> nsouch: like (re)introducing the "Big Kernel Lock" ?
[17:56] <philbo_> Foske: the source code for remap_page_range clearly shows that it is safe to use them no matter what the book says
[17:56] <nsouch> philbo: yes and have arch abstraction in VM management
[17:56] <Foske> nsouch: we should lock every bit of code that accesses registers
[17:57] <philbo_> Foske: safe in the sense that they do the same thing as the fast_ version
[17:57] <Foske> philbo: ok, but it doesn't explain the memory leak
[17:57] <nsouch> somehow
[17:57] <skids> cow: Yeah the real reason for the logo was to slow down to read boot messages. Since the boot driver no longer seems to need debugging, it could probably just be removed and later we'll do some sort of logo like the fbdev pengiun.
[17:58] <njs> having a logo is useful if only so it's immediately obvious that your kernel patch has succeeded...
[17:58] <Foske> I will start to work out locking abstraction
[17:58] <cow> skids, k. i'll simply drop the menuconfig option for now
[17:58] <nsouch> skids: thanks for the info, I love historical reasons
[17:58] <philbo_> nsouch: I was meaning to have a talk with you about what exactly is needed now that I'm toying with splitting /dev/graphic but I suppose that should probably be done outside this meeting
[17:58] <Foske> please keep things together guys
[17:59] <ortalo> I think we should really do more attempts to use the native remap_page_range() functions.
[17:59] <Foske> ortalo: sorry ? we do it already now ?
[17:59] <nsouch> hard, I think. graphic is *very* OS dependent, first because of the unix API (open, ioctl, mmap...)
[17:59] <philbo_> Foske, ortalo, philbo agree on removal, cow doesn't care either way.
[17:59] <ortalo> But (changing the way we) playing with the VM is always touchy.
[18:00] <skids> We should kill them for now, and concentrate any effort along these lines, if any is needed, on the BSD and Linux 2.5 VM.
[18:00] <nsouch> Arch independency and OS independency shall be addresses in parallel
[18:00] <cow> .... fast_ .. fwiw, as said before ok with me to drop, although i do not see an advantage. otoh it probably would be well received to reuse existing (but sometimes suboptimal) infrastruc
[18:00] <Foske> I'm willing to look on the locking, but if someone else could track the leaks ?
[18:00] <philbo_> nsouch: right. Well /dev/graphic is just one of possible mappers. But anyways. I'll email you about all my ideas so that you can tell me what would help the FreeBSD port.
[18:00] <ortalo> I can try to locate these leaks. (As soon as I can reproduce the thing.)
[18:00] <Foske> might be Gx00 related
[18:01] <Foske> oki
[18:01] <nsouch> Foske: once my Tyan bi-AMD has CPU and memory ;)
[18:01] <cow> Foske, can you quickly descibe an easy way to reproduce/observe 'em?
[18:01] <nsouch> philbo: ok
[18:01] <Foske> nsouch: thanks, will assign it to ortalo for now
[18:02] <philbo_> So I take it we are agreed on removing fast_ functions.
[18:02] <ortalo> At least we should try to remove them.
[18:02] <cow> philbo, well, looks like
[18:02] <Foske> cow: my setup : SMP kernel, Gx00 (G400 AGP) display=1, top on a console on display=0, accel demo running full speed on ALTGR-F5
[18:02] <Foske> and see the memory counter growing
[18:02] <cow> Foske, k
[18:03] <philbo_> Foske: for kernel or for the accel demo?
[18:03] <Foske> not tested wheter it is SMP or Gx00 specific
[18:03] <Foske> for the kernel mem, accel stays fine
[18:03] <Foske> accel demo
[18:04] <ortalo> Can you send me the offending program (unless it is one of the LibGGI programs)?
[18:05] <Foske> ortalo: abused libggi/programs/demos/demo
[18:05] <bughunter> foSke: I thought, you used the stars demo?
[18:05] <Foske> removed the 3 seconds check on the random box drawing
[18:05] <Foske> bughunter: wasn't sure that one was accellerated
[18:05] <Foske> okay...
[18:05] <cow> fine. next proposed point or point in agenda is ?
[18:06] <Foske> CONFIG_INPUT
[18:06] <Foske> philbo ?
[18:06] <Foske> what about it ?
[18:06] <bughunter> foSke: Just guessed, because you said again and again: "I saw the stars" :)
[18:06] <philbo_> I have a fix that makes sure kgi doesn't use kii/keysyms.h (leaves them for userspace0
[18:06] <philbo_> Do people think this is a good way to go?
[18:06] <cow> something we should put in HEAD right after the having tagged?
[18:07] <philbo_> I suppose use of all the K_ stuff is very specific
[18:07] <skids> Every time I look at KII I get depressed, so don't look to me for solutions.
[18:07] <philbo_> nsouch: do you have any opinions about how linux specific kii is?
[18:07] <skids> We need K_ syms as long as we have our own console implementation, and as a result, we have this huge set of #defines that varies from OS to OS.
[18:08] <cow> skids, :) disgusting it really is indeed
[18:08] <nsouch> bughunter: ah! smoking while hacking... :)
[18:08] <nsouch> philbo: it's not
[18:09] <Foske> so, removing it is not an option ?
[18:09] <nsouch> I've ported KII + written input drivers and a device for FreeBSD console
[18:09] <skids> bughunter: militant?
[18:09] <nsouch> starts working except that console switching is not yet managed by KII
[18:10] <Foske> i.e this entire thing is a non-issue, besides that KII needs a cleanup :)
[18:10] <cow> Foske, yes, i think it's not. we should rather look at something like a "console-stackker" mid- or rather long-term, imho
[18:10] <philbo_> ok. let's move on then.
[18:10] <Foske> great...
[18:10] <Foske> one issue not on the agenda:
[18:11] <nsouch> skids: why so? KII is not that bad.
[18:11] <bughunter> skids: s/militant/unyieldingly/ :)
[18:11] <Foske> VT switching causes Accel deadlock. At least on SMP systems with the Gx00 accellerator, though I think it is a design flaw
[18:11] <skids> bughunter: As long as you keep your militant tendencies to yourself I guess that's OK.
[18:11] <philbo_> Foske: do you know the cause?
[18:12] <Foske> seems not to be solved with locking, is a race: cpu 1 assumes something still to come while CPU 2 has passed it
[18:13] <Foske> wait_idle in the graph_accel_nomap (iirc) waits forever
[18:13] <skids> nsouch: I think we are trying to do too much with KII. I'd prefer to see the OS mainstream decide on their console system, and if they pick a lame one, they suffer.
[18:13] <ortalo> So the "wake_up()" does not go though.
[18:13] <Foske> ortalo: maybe an issue for you ? you got SMP and are known with the accel code ?
[18:13] <ortalo> Are you sure that the buffer was indeed executed and that you got the SOFTRAP end-of-buffer IRQ?
[18:14] <nsouch> but KGI must know about special keys (switching at least)
[18:14] scanlime has joined #kgi
[18:14] <ortalo> The problem is that I do not have SMP hardware, so maybe I will not reproduce the bug.
[18:14] <ortalo> But if I can reproduce it, yes I can try to track it down.
[18:14] <Foske> it is perfectly reproducable for me, just switch away and back
[18:14] scanlime has quit (Client Quit)
[18:14] <Foske> it might occur on single CPU too
[18:15] <Foske> never checked it though
[18:15] scanlime has joined #kgi
[18:15] <Foske> ok. please let me know if you need help
[18:15] <Foske> now...
[18:15] <Foske> the big issues
[18:15] <Foske> AGP support
[18:16] <skids> nsouch: If we ship it as is. We could also just ship a KGI that has an in-kernel API, and then as a separate project console systems could be hooked in to use as much of the KGI API as their design limits them to.
[18:16] <skids> I think most people view AGP-GART, PCI-GART and other DMA stuff as
[18:16] <skids> being "for accel". There are more uses, and I consider accel FIFO
[18:16] <skids> itself to be perhaps the least important: My list:
[18:16] <skids> 1) Textures
[18:16] <skids> 2) Vector lists
[18:16] <skids> 3) various LUTs
[18:16] <skids> 4) Accel FIFO
[18:17] <ortalo> skids: agreed
[18:17] <Foske> Okay, what is new with AGP-GART ? or is it just yet another bus system ?
[18:17] philbo has quit (Ping timeout: 14400 seconds)
[18:17] <nsouch> skids: right. But do OSes have better console than KII? NetBSD is supposed to AFAIK.
[18:17] philbo_ changes name to philbo
[18:17] <skids> Note that 1) and 3) never need to be mapped out (except for focus
[18:17] <skids> changes) even when they are committed, and with proper driver coding we
[18:17] <skids> can make it so that 2) never needs to be mapped out.
[18:18] <philbo> indeed. There are two separate issues here. How to use it in kernel and how to expose it to userspace. I suggest we start by discussing how to use it in kernel.
[18:18] <Foske> are we there with bus abstraction ?
[18:18] <skids> nsouch: whether theirs is better or not is not the point. The point is that KGI has a boundary, and it's the mainstream developers (or sidestream devels) that are responsible for taking advatage of what KGI has to offer.
[18:18] <ortalo> 0) Pictures (putbox)
[18:18] <bughunter> nsouch: and openbsd, too...
[18:19] <philbo> skids: wrt kii, how about we strive to make kii just another one of the possible console layers?
[18:19] <ortalo> Foske: AGP also has another specific translation table...
[18:19] <skids> philbo: works for me.
[18:19] <Foske> guys, can we leave KII now please ?
[18:19] <nsouch> of course, they share lot of code.
[18:19] <skids> ortalo: I was considering putbox to be texture
[18:19] <philbo> Foske: done.
[18:20] <ortalo> IMO, in-kernel, AGP raises the problem of "graphic-capable" buffers.
[18:20] <bughunter> ... because there are two cases to take over:
[18:20] <bughunter> a) the driver finds the card by searching through the bus
[18:21] <bughunter> b) the bus driver finds the card and loads the driver
[18:21] <bughunter> AFAIK, b) is the *BSD way.
[18:21] <philbo> bughunter: that's not very relevant to agp
[18:21] <Foske> a) is no case, it is on top of b)
[18:21] <cow> bughunter, non-issue. is (will be) abstracted in drv/display/system/whatever/system
[18:22] <bughunter> cow: ok.
[18:22] <nsouch> but that's relevent to arch/OS independency (which is everywhere :)
[18:22] <philbo> what we need to figure out is where/what sets up the gart, how is the driver notified about it and how is this memory managed (be it for accel buffers or to expose for userspace)
[18:22] <nsouch> We can't support a new bus with addressing arch issues.
[18:22] <Foske> -the detection system should be removed from the chipset driver, wich is a part of the bus abstraction issue, which might solve some AGP issues as well
[18:22] <skids> I would say that AGP buffers should be mmapped above the VRAM on /dev/accel, even if they are textures. When the mmap happens, OS facilities for allocating the space are invoked, and if successful, the mmap is successful... is that simple enough?
[18:22] <ortalo> We need some management functions in-kernel so that a driver can check that some memory area referenced in the accel FIFO refers really to some "KGI graphic buffer" and extract the characteristic of the area (AGP capable or not, DMA, etc.)
[18:22] <cow> real question is about the silly impl details involved with it or rather policy
[18:23] <nsouch> Foske: Ack.
[18:23] <bughunter> nsouch: I like NetBSD's bus and DMA abstraction layer.
[18:23] <Foske> so maybe buggyhunter wasn't so wrong at all
[18:24] <Foske> maybe we should implement bus abstraction first before we deal with AGP issues
[18:24] <ortalo> Foske: AGP is not the only issue there!
[18:24] <cow> skids, too fast for me but does sound simple enough for me at a first read
[18:24] <Foske> and as buggyhunt likes it, I also declare him the volunteer to do that
[18:24] <cow> hm
[18:25] <ortalo> Foske: currently, even via regular PCI accesses, we do not know in KGI how to use in-host textures...
[18:25] <skids> Maybe we should just start with a kgi_agp_* set of functions which implement the least common denominator of the immediately available OS facilities. Then, someday when we are sprucing things up, we can change that API to be a bus abstraction layer.
[18:25] <Foske> ortalo: so true, this sounds more and more as a need of an abstraction layer
[18:26] <bughunter> links to NetBSD's bus/dma abstraction layer are available at http://kgi-wip.sourceforge.net/documentation.html
[18:26] <bughunter> Does everyone agree, when we use this API as is?
[18:26] <Foske> skids: you the agp code, buggyhunt the bus abstraction ? :)
[18:26] <nsouch> bughunter: Anyway, prototyping AGP does not need full x86 independency
[18:26] <nsouch> bughunter: I expect a lot from a future NetBSD port for Arch issues...
[18:26] <cow> philbo, a gart resource is nothing more than a resource. a drv does not (?) need to be aware of type, shuold it?
[18:27] <Foske> bughunter: might be nice to use it, saves a lot of efford on bsd systems
[18:27] <skids> If we do go for a bus abstraction during the first pass, then we should not try to make it work for anything but AGP. Once it works for AGP, we let it be. I don't want to see us side-tracked into become also the "KBI Project"
[18:27] <bughunter> nsouch: How much does NetBSD's API differ from FreeBSD's one?
[18:28] <philbo> cow: a driver's resrouce? Is it the card driver that sets up the gart?
[18:28] <nsouch> bughunter: not much USB, ISDN, sound systems are shared with compile conditions.
[18:28] <skids> The card driver should only need to request GART regions from the kernel and poke a register or two.
[18:28] <cow> skids, a bus abstraction naturally has to be bus agnostic, so i don't see your point in KBI at all? please explain
[18:29] <bughunter> skids: Once a guy comes up, who wanna port KGI to the sparc architecture.... On sparc, there's no AGP nor PCI.
[18:29] <skids> Suppose we decide we want a "bus abstraction", and we go implement KGI for an OS that doesn't have one. We should NOT spend time making the back end of buses we won;t ever use.
[18:29] <bughunter> skids: sparc has its own bus: SBUS. And UPA for the graphic board.
[18:30] <philbo> skids: so the driver would during init setup the gart using kgi_apg_ functions, setup its own registers and then export the agp memory as another mmio region?
[18:30] <nsouch> Actually, I started with FreeBSD because I know it quite well, but NetBSD is the best target for lots of reasons
[18:30] <cow> philbo, well right, not a driver resource but a resource used by the driver. still a bus abstracted resource used by the driver
[18:30] <skids> philbo: More like during mmap than during init.
[18:30] <philbo> skids: you can mmap only already available resources
[18:30] <skids> philbo: and during vc switch.
[18:31] <ortalo> I think the driver does not need to be involved into the mmap and export to userspace.
[18:31] <nsouch> NetBSD VM has numerous improvements over Mach, valuable for KGI.
[18:31] <ortalo> KGI can do this directly per-se, without driver intervention.
[18:31] <skids> philbo: what consititutes an "available" resource? Doing anything other than on-demand allocation of AGP RAM won't fly.
[18:31] <nsouch> ortalo: should the GART be handled has an other tlb?
[18:31] <bughunter> nsouch: OpenBSD implements NetBSD's UVM, btw.
[18:32] <ortalo> Afterwards, when the AGP (or regular PCI) memory areas get used. The driver will need some info about them.
[18:32] <cow> philbo, /mmio region/resource/ yes, no?
[18:32] <ortalo> nsouch: I don't know in fact.
[18:32] <philbo> cow: mmio resource yes
[18:32] <bughunter> nsouch: Does FreeBSD also implements NetBSD's UVM? Or is it still based on 4.4BSD/Mach VM?
[18:32] <philbo> ortalo: can you use agp witout ever telling the driver about it?
[18:33] <skids> bughunter: OK, so we change the prefix for kgi_agp_* to kgi_somethingelse_* Still, I don't want to become the KBI Project.
[18:33] <ortalo> philbo: no, but the driver only wants to know if ONE bit should be set or not set.
[18:33] <Foske> maybe some discussion on the mailinglist should be involved in this before we can settle it. we're mow comparing this os to that os, and my conclusion is simply that the differences are big enough to show the need for some abstraction
[18:33] <nsouch> bughunter: no, unfortunately. FreeBSD chose the stability.
[18:33] <bughunter> nsouch: NetBSD, too. :)
[18:34] <philbo> ortalo: doesn't it need to know about where and how much of agp memory there is?
[18:34] <ortalo> Foske: agreed.
[18:34] <nsouch> bughunter: I did not mean the opposite :)
[18:34] <Foske> maybe bughunter can show us a little what the implications are
[18:34] <Foske> by mail
[18:35] <Foske> and I guess not everyone has read the docs well, for they were mostly just dumped on the website without comment
[18:35] <ortalo> philbo: that's the other way round: the driver sees a request to tranfer some memory area. He wants to check if this is AGP or "correct" memory, to setup the hardware transfer.
[18:35] <cow> philbo, i think it doesn't. if it is else it isn't
[18:35] <philbo> ok. Let's leave it for an email discussion as it isn't pressing and it would be beneficial to have long pauses to think about issues involved
[18:36] <skids> OK, onto how AGP looks in userspace?
[18:36] <philbo> cow: the Radeons for example have AGP_BASE and AGP_TOP registers for specifying region in the internal Radeon address space that should generate agp requests
[18:36] <Foske> bughunter: could you please pull this heavy wagon ? At least initiate the discussion with some practical talking instead of "we should do bus abstraction" ?
[18:37] <bughunter> foSke: I can give it a try.
[18:37] <Foske> thanks
[18:37] <Foske> any comments one cannot keep for himself now ? :)
[18:38] <ortalo> I hate AGP.
[18:38] <bughunter> foSke: First I must get the mach64/crt driver combination get to work in order to have a stable base to work on.
[18:38] <skids> lol.
[18:38] <bughunter> ortalo: :)
[18:38] <cow> philbo, so it is using a resource which happens to call a callback in the worst (but common) case. i still do not grok it rightly, i guess
[18:38] <cow> Foske, none. move on :P
[18:38] <bughunter> foSke: Though, my PC has no AGP. So for AGP support, I need assistance.
[18:39] <Foske> okay. someone else that starts the agp code in the mean time ?
[18:39] <philbo> cow: I suppose it's all just anoying implementation issues....
[18:39] <skids> bunhunter: ATI cards have a GART for PCI built in.
[18:39] <ortalo> I really think we should focuss on ggiPutBox() before trying to do it via AGP.
[18:39] <Foske> I assume buggyhunt can use assistance on the bus stuff
[18:39] <Foske> oki
[18:39] <cow> philbo, probably. real world always sucks :P
[18:39] <skids> ortalo: what do you mean?
[18:39] <Foske> agp skipped till the bus abstraction basics are there
[18:39] <Foske> next subject
[18:40] <Foske> ggiPutBox ?
[18:40] <ortalo> I mean: sending data from host memory to the framebuffer using the accel engine.
[18:40] <skids> Uhuh, not that easy, userspace buffers were deemed to be a different subject, so now I want to talk about those.
[18:40] <Foske> ah, ok
[18:40] <Foske> 10 minute pee break ?
[18:41] <Foske> ok
[18:41] <skids> ortalo: Versus what, I thought that was what we were talkinga bout/
[18:41] <cow> Foske, if you feel like, yes :)
[18:41] <skids> peeeeeesa 10
[18:41] <Foske> XX:55 we will continue
[18:41] <bughunter> !sleep 5
[18:41] <bughunter> :)
[18:42] <bughunter> !time
[18:42] <ortalo> OK for the break.
[18:42] <bughunter> It is 0:49 CET :)
[18:42] <ortalo> Yes. Me too.
[18:42] <nsouch> :)
[18:43] <Foske> my freenode server says 02:46 am
[18:45] <nsouch> ...
[18:45] <nsouch> still have lot of dip (debug in progress) :)
[18:46] <bughunter> foSke: testuser_'s, anaki's, ekix's and golbez's todo lists are also empty... :)
[18:46] <bughunter> foSke: same for njs, neiljp, mitchell_, fraggle, oxygene, popel and scanlime :)
[18:46] <Foske> yeah, but for the three first we should be happy now if they are willing to test kgi :)
[18:47] <bughunter> foSke: yes... :)
[18:47] <njs> At this level of abstraciton I'm just a spectator :-)
[18:47] <Foske> we never were so crowded here :)
[18:48] <bughunter> 18 users here.
[18:48] <bughunter> the record on #ggi was 14 or 15...
[18:48] <neiljp> bughunter: ho ho ho :)
[18:48] <Foske> njs: that's ok :) what OS/Hardware do you use ?
[18:48] <nsouch> bus-abstraction is not a subject anymore, or bunghunter want's to continue the demonstration? :)
[18:48] <njs> Foske: linux, dual x86, G400
[18:48] <Foske> oh great !
[18:49] <njs> Foske: but I'm not sure I can actually do much testing; my kernel setup is a bit touchy right now.
[18:49] <Foske> njs: that must be the best supported platform at the moment (besides the SMP issues we discussed earlier)
[18:50] <bughunter> neiljp: you wanna have the docs for the rage128 cards?
[18:50] <Foske> 2 minutes before meeting time
[18:51] <neiljp> bughunter: the docs are available? not that I'd understand a word of them, but...
[18:51] <bughunter> neiljp: philbo, golbez and I have them.
[18:51] <Foske> buggy: I can donate you a Rage 128 :-P
[18:51] <bughunter> neiljp: I have the docs on a CD, which is at home... so I haven't it at hand right now.
[18:51] <nsouch> a new item for philbo's TODO list then.
[18:52] <bughunter> foSke: Is it PCI?
[18:52] <Foske> yup
[18:52] <bughunter> foSke: great.
[18:52] <skids> Your pee is ready (to be flushed)
[18:52] <Foske> hunty: mail me your address
[18:52] <Foske> oki... ortalo ?
[18:53] <neiljp> philbo: cool :) apart from the lack of time ;)
[18:53] <bughunter> foSke: ok
[18:54] <Foske> next subject: vt_switching is based on kii_devices... i.e. if you open the wrong (or no) /dev/event, things go wrong
[18:54] <cow> ------------------------------------------------------------
[18:54] <Foske> =S
[18:54] <skids> Uhuh, next subject is userspace accel buffers.
[18:54] <Foske> oh ?
[18:55] <njs> what are userspace accel buffers?
[18:55] <cow> Foske, indeed
[18:55] <skids> The second half of the AGP discussion.
[18:55] <Foske> sorry, missed that one
[18:55] <cow> Foske we urgently have to settle those
[18:56] <Foske> njs: the possability for an outside-kernel piece of code to accellerate graphics full speed by having access to the accellerator unit
[18:56] <cow> thought / quick intros?
[18:56] <skids> cow: of people, or topic?
[18:56] <philbo> skids: could we move that to the mailing list as well? I think the same applies (not as pressing and people need to make themselves a good idea of what the issues are)
[18:56] <Foske> ok:) skipped !
[18:56] <cow> skids, people always are void. only topic is real
[18:56] <skids> Hrm, well I can reduce the discussion to this point and continue on the mailing list:
[18:57] <skids> I'd really like to see an mmap control page set for controlling
[18:57] <skids> the accel so the other CPU can grab a finished buffer on SMP systems
[18:57] <skids> w/o the context switch. Also this pertains to certain types of vsync stuff,
[18:57] <skids> but I'll wait till that topic for that part.
[18:57] <Foske> skids will introduce this to the mailing list
[18:57] <bughunter> nsouch: AFAIK, you said, FreeBSD has addressed the VM issues to allow access to hw resources from userspace. Is that right? If yes, can you elaborate on them, please?
[18:58] <Foske> now, next subject ?
[18:58] <cow> foske, useles. just paste a strip to the list with names omitted if you feel the list to be involved
[18:58] <Foske> ?
[18:59] <skids> Re: vt switching then... what gets restored?
[18:59] <philbo> skids: wait, that's the next one
[18:59] <skids> Oh, sorry.
[19:00] <skids> RIght, /dev/event.
[19:00] <cow> so how does that one look like at a glance. write only ping read only pong i guess? sane counter-example?
[19:00] <nsouch> bughunter: yes... trying to find a starting point.
[19:00] <Foske> err
[19:00] <Foske> ELOST
[19:01] ortalo has quit (Read error: 110 (Connection timed out))
[19:01] <skids> I won't be annoying and point out that this problem is just another result of KII. Oops. I guess I just did.
[19:01] <philbo> Basically, I can't think of a good solution to the /dev/event+vt swithing problem. Suggestions are welcome.
[19:01] <nsouch> bunghunter: in terms of differences with Linux graphic mapper implementation?
[19:01] <Foske> okay, skids volunteers to rewrite KII :) NEXT :-P
[19:01] <bughunter> nsouch: yes.
[19:02] <bughunter> foSke: shouldn't we wait until ortalo is back? :)
[19:02] <nsouch> Foske: skids is willing to rip KII, not rewrite it.
[19:02] <Foske> oh
[19:02] <philbo> ok, well I suppose people aren't very familiar with the issue. Moving to mailing list with ample background information.
[19:02] <skids> ortalo must have prostate problems, to pee so long :-)
[19:02] <Foske> almost the same
[19:02] <Foske> good idea
[19:02] <bughunter> skids: maybe his baby makes some noices now... :)
[19:03] <Foske> think the next subject is actually discussable... :)
[19:03] <nsouch> s/baby/babies
[19:03] <philbo> next topic: can libggi solve all of our vt swithchin/restoring issues?
[19:03] <cow> a shared one sounds dangerous to me, personally. urgently needed but odd to my untrained mind
[19:03] <bughunter> philbo: IMO, this is a target issue of libggi.
[19:04] <skids> Umm, I think there are some things that KGI should restore beyond mode...
[19:04] <philbo> bughunter: does libggi have a way of telling the app that something happened and it should probably redraw?
[19:04] <nsouch> bughunter: most of the differences stand in the fact that there's no per process data in the vnode system and
[19:04] <skids> philbo: GII has expose events.
[19:04] <skids> philbo: and UNIX has sigwinch.
[19:04] <philbo> skids: ok. Is that enough?
[19:05] <Foske> if kgi sends sigwinch, we're there :)
[19:05] <bughunter> philbo: Have you read the last mails from the GGI ML (the ones from the heating discussion)
[19:05] <nsouch> bughunter: for a given vnode, the VM management is centralized by pagers.
[19:05] <cow> nsouch, and?
[19:05] <Foske> the "I hate amiga kiddies by default" one :)
[19:05] ortalo has joined #kgi
[19:05] <Foske> wb ortalo
[19:06] <skids> Can we get agreement that any data in VRAM is definitely NOT preserved by KGI?
[19:06] <Foske> ortalo: vt switching based on event: moved to mailng list. topic: what to restore on vt switch
[19:06] <philbo> bughunter: well, that one wasn't all that constructive. I think people here have a better understanding of kgi and the complexity of implementation details
[19:06] <nsouch> bughunter: thus difficult to distinguinsh two different mappings of different processes when time comes to handle faults.
[19:06] <philbo> skids: Sounds reasonable to me
[19:06] <Foske> skids: I agree there, if an app is slow it should draw in RAM instead of vram
[19:07] <Foske> then it can continue to draw when moved to the background
[19:07] <ortalo> skids: sounds ok to me too. except maybe some very special cases (like cursor shape if stored in VRAM).
[19:07] <cow> skids, in my simple-minded mind it is not, right.
[19:08] <skids> ortalo: I think the text vc system should maybe have a cursor shape stored, but I'm not too sure about graphics apps.
[19:08] <philbo> ortalo: sounds hard. I don't think it's unreasonable to ask the app to restore it. Console does it.
[19:08] <Foske> mwaah.. graphic apps just should restore everything
[19:08] <skids> It makes it a lot simpler for our first few releases if we know we never have to protect anything in VRAM from another process.
[19:08] <bughunter> nsouch: I think, you told that on the KGI ML... Am I right?
[19:09] <nsouch> bughunter: I did.
[19:09] <bughunter> nsouch: ok
[19:10] <Foske> ok. so kgi should send a signal when a app should redraw (App gets sigcont already, by the way)
[19:10] <philbo> so: everything is assumed lost on a vt switch. libggi provides a good interface for apps to react to such event. Anything to add?
[19:10] <Foske> I will take care of the signalling
[19:10] <skids> Well, I'm not so sure about graphics context.
[19:11] <philbo> skids: you mean the accelerator context? That one is per mapping and is preserved.
[19:11] <skids> Including things like texture LUTs?
[19:11] <cow> that one is tricky and furthermore dangerous, yeah.
[19:12] <philbo> skids: but I guess you're getting to the question of what happens if your accel buffers are in agp space...
[19:12] <skids> philbo: No I was saving that one to whollop people over the head later :-)
[19:12] <Foske> philbo: that requires decent handling of the signals...
[19:12] <Foske> won't be easy, but must be done
[19:12] <skids> The problem is, GPU contexts are getting bigger and bigger.
[19:13] <Foske> so less and less reasons to keep things in back buffers ;)
[19:13] <skids> (as in, non-VRAM register values).
[19:14] <skids> OK, so we are then agreed that the app needs to restore GPU context?
[19:14] <Foske> don't forget: switching away an applicatin that utilizes 128 MB video mem is not a MUST for the user, it is a CAN DO
[19:14] <Foske> from KGI
[19:14] <bughunter> skids: GPU context switching is not a problem on highend cards.
[19:14] <philbo> skids: right, though I don't think I have a good idea about the exact scale of the problem
[19:15] <skids> Well, yes, I am kinda hiding the "but then"... here goes "but then the accel pipe cannot resume execution until the app's GPU reload is done."
[19:15] <philbo> skids: yes, I think gpu context is preserved. KGI was built around that assumption and it is just too hard otherwise. We'll deal with practical problems when we encounter them.
[19:15] <skids> And since the app may be reloading the GPU using the accel pipe....
[19:15] <Foske> skids: hey, how many times a sec do you swap away heavy graphic apps ?
[19:16] <Foske> anyway
[19:16] <skids> Foske: It's not the performance, it's the amount of kernel-side code to maintain/debug.
[19:16] <Foske> I'll take care of the signals, and it's up to the ggi guys to deal with it. (volunteers ?)
[19:17] <Foske> I'll take care of sending the signals that is
[19:17] <skids> Foske: luckily, the trend is *away* from write-only registers, aliased registers and such, but the register load/reload can end up being a pretty big (and thus bug-infested) section of code.
[19:18] <Foske> skids: I never said supporting swapping away accellerators was going to be easy :)
[19:18] <Foske> next subject....
[19:18] <skids> Foske: I'd prefer we do, I just want to make sure everyone knows the implications before agreeing to it.
[19:19] <Foske> synchronisation of accelleration: is polling /dev/kgi/device0/accel the best ?
[19:19] <skids> Foske: I'll take care of GII issuing an expose event.
[19:20] <Foske> skids: good, though you should also catch the sigttou and sigttin
[19:20] <philbo> we *need* synchronization. As far as I understand things, that's the best solution so far. Any suggestions?
[19:20] <Foske> everyone still here ???
[19:20] <ortalo> yes
[19:20] <bughunter> yes
[19:21] <ortalo> though sleeping a little... :-)
[19:21] <skids> philbo: Mostly we *need* to be able to queue certain commands for execution during vsync.
[19:21] <Foske> huh :)
[19:21] <skids> The rest is gravy.
[19:21] <philbo> skids: ugh. That a whole other can of worms
[19:21] <Foske> mjammy, worms...
[19:22] <skids> I volunteer to add the API to LibGGIMISC for issuing flip-on-retrace and such.
[19:22] <Foske> ok
[19:22] <Foske> noted:)
[19:22] <Foske> back to the isse
[19:22] <Foske> issue
[19:22] <philbo> well, before people start falling asleep on the old continent, lets move to splitting /dev/graphic
[19:23] <ortalo> Apparently, FreeBSD needs this (IIUC).
[19:23] <Foske> :)
[19:23] <Foske> oki
[19:23] <philbo> Are people opposed to the idea? Anybody feels it is useless waste of major numbers?
[19:24] <ortalo> Maybe it is not so urgent under Linux?
[19:24] <skids> I'm getting the impression that we are too tied to the fd's somehow, and we need (don't say it, no!!!) and abstraction layer.
[19:24] <bughunter> philbo: I guess, Linus thinks so.
[19:24] <Foske> wasting majors will be a reason to decline KGI once mores
[19:24] <nsouch> ortalo: yes, this was the conclusion on the ML
[19:24] <ortalo> It's not the major numbers that worry me, it is more the additional code for new device types in Linux.
[19:24] <Foske> this works for Linux, that works for BSD....
[19:24] <njs> does devfs make matters better or worse?
[19:25] <bughunter> skids: good point. :)
[19:25] <Foske> njs: neighter
[19:25] <philbo> ortalo: it is hard to wait for an accel to go idle if you don't have a fd for each accel to wait on
[19:25] <Foske> njs: it prevents you from wasting minors, though not majors
[19:25] <skids> I think we should use devfs when available but not require it.
[19:25] <nsouch> I progressed on the FreeBSD side and a new mapper command is used for accessing a particular device from a /dev/graphic
[19:25] <Foske> 16 bit majors will solve the issue for us
[19:26] <nsouch> An attach command that differenciate the graphic minor from the device number.
[19:26] <Foske> iirc that is linux 2.5 code
[19:26] <skids> We should be concentrating on 2.5 and on as far as Linux is concerned IMO.
[19:26] <nsouch> KGIC_MAPPER_ATTACH, with a device_id as parameter
[19:27] <Foske> skids: for the wip branch yes, for the stable branch no
[19:27] <cow> i'm not sure we need (additional) majors. since we (seem to be freed) from pressure by minors we could push one level and do away with only one (or two for conveniance) majors and a shifted minor for non-accel, acce.
[19:27] <nsouch> This trick avoids the /dev/graphic breakage for now.
[19:27] <skids> Foske: sure, but for the stable branch any kludge that works is fair game IMO.
[19:27] <Foske> cow: I think this issue doesn't count for linux right now. it works there, so please keep the stable tree this way
[19:28] <bughunter> nsouch: For completeness, is there a KGIC_MAPPER_DETACH, too ?
[19:28] <philbo> so there are at least two solutions for the major number contention. Hence splitting /dev/graphic is a good idea?
[19:28] <cow> Foske, the stable is out of discussion fro my POV
[19:28] <cow> mmmmmmmmm
[19:28] <nsouch> bughunter: no, the close is responsible for the detach.
[19:28] <Foske> into how many mayors ?
[19:29] <philbo> graphic, accel, fb
[19:29] <cow> /me's keyboard has a wackelkontakt :-/
[19:29] <skids> philbo: I'd just cuation to try to keep the code that figures out what "thing" is being accessed from becoming completely entangled to the extent possible -- it may become an issue later.
[19:30] <philbo> skids: very true. I'm trying to mirror the kgi interface there (only a single attach/detach pair, should be very clean)
[19:30] <cow> skids, may but should not. yea
[19:31] <cow> .....next?
[19:31] <philbo> I got nothing. Anyone?
[19:31] <skids> My brain is fried.
[19:31] <nsouch> VGA driver?
[19:31] <Foske> mine too
[19:31] <Foske> ?
[19:31] <Foske> what about it ?
[19:32] <nsouch> It's still broken, no?
[19:32] <ortalo> Maybe we should refrain from splitting /dev/graphic too early then, no?
[19:32] <nsouch> yes.
[19:32] <ortalo> Who works on the VGA driver?
[19:32] <philbo> ortalo: I'm working on a sample implementation. If people disagree, I'm perfectly willing to throw it away.
[19:32] <bughunter> anyone feeling able to make a (pre-) summary of what we have discussed?
[19:32] <cow> nsouch vga-text is in cvs. pülease try it out and get back to me or the list iff problems arise (apart from absent features which you ought to implenment()
[19:33] <Foske> bughunter: i'm about to sleep now, gf is waiting
[19:33] <nsouch> cow: ok
[19:33] <philbo> Foske: are you going to write up a summary? (later)
[19:33] <Foske> tomorrow
[19:33] <ortalo> philbo: I guess it will be useful. Maybe it's something that will re-appear soon. But it changes the way we were used to look at KGI devices...
[19:34] <Foske> it might appear in FreeBSD soon, and in Linux later
[19:34] <nsouch> If no other solution found in the middle.
[19:34] <philbo> ortalo: yeah, I know. I think it is worthwhile to have something working so that people can see what it does to the code and make a better judgement of whether it is a good idea or not
[19:35] <philbo> ortalo: I'm not fully convinced myself, hence my willingness to throw it away when I'm done and it doesn't satisfy my desires
[19:35] <cow> nsouch, i did not forget about the FreeBSD integration, but that one may take some time. i don't have it locally, so playing with it is cumbersome, thus time-intensive. i'm sure you see my point.
[19:35] <Foske> okay..
[19:36] <Foske> I'm off to sleep now, log will continue to run, don't talk too much, only got 223 MB left :)
[19:36] <philbo> good night Foske
[19:36] <nsouch> cow: I do.
[19:36] <Foske> summary will follow soon
[19:37] <ortalo> I guess I need some sleep too now.
[19:37] <cow> i do too
[19:37] <ortalo> If you don't mind, I'd rather say you good bye now... :-)

Participants

NickFirst occurence atNumber of messages
Foske17:01:237
bughunter17:03:85
cow17:05:74
fraggle17:14:1
golbez17:02:2
neiljp17:33:8
njs17:26:8
nsouch17:17:72
ortalo17:02:57
oxygene17:20:1
philbo18:17:43
philbo_17:04:58
scanlime18:14:0
skids17:03:131