[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: 188.8.131.52
[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.