[23:01] <bughunter> philbo: I know that, because I prepare the "reboot" command on a different console than I insmod the Rage.o module. :)
[23:01] <skids> Should we start with current state, or immediate future plans?
[23:01] <philbo> bughunter: hehe. good strategy. We still should fix it ASAP.
[23:01] <Foske> current state I guess...
[23:02] <Foske> where are we now ?
[23:02] <cow> philbo, np
[23:03] <Foske> and... what is wrong at the moment
[23:04] <Foske> guess not
[23:04] <skids> WRT to basic framework/modesetting the open issues I remeber are these:
[23:04] <cow> current state: console handling (focus et al) needs brushing
[23:04] <skids> 1) display vs. image for multi-port cards.
[23:05] <skids> 2) Any needed meta-language/core system enhancements for DDC
[23:05] <skids> 3) Unifying the monitor drivers
[23:06] <Foske> the most important imho is 1).. or : the possible need to reconstruct the kgi core
[23:06] <skids> and 4) replacing MMAP offset with IOCTL/MMAP combo.
[23:06] <philbo> skids: 4 is done.
[23:07] <skids> philbo: cool!
[23:07] <bughunter> philbo: In CVS or in your working tree?
[23:07] <Foske> in cvs already ?
[23:07] <philbo> I would add 5) handle VT switching between console and graphics
[23:08] <philbo> bughunter, Foske: in CVS, the kgi target for libggi uses it too.
[23:08] <Foske> isn't 5 supposed to work already for a long time ?
[23:09] <skids> golbez: could you elaborate?
[23:09] <skids> (and philbo)
[23:09] <philbo> Foske: nope. The map/unmap callbacks in graphic.c are currently NULL. Nobody really notices it because the keys for switching into graphic consoles aren't actually mapped anywhere in the current keymaps :-)
[23:10] <golbez> I think the focus should be stabalizing a single head setup so that a KGI kernel can be used for daily use. Being able to switch between graphic and console vt is key to this.
[23:10] <Foske> ah ok
[23:10] <Foske> golbez: true, but multihead is getting more and more common, but it's okay with me if we drop that issue now
[23:11] <skids> So mode set/restore is still working, we just need to implement unmap/map?
[23:11] <bughunter> golbez: For daily use, fixing bug #14 has priority #2 FOR ME (priority #1 is 5))
[23:11] <philbo> The big question is what should be done? /dev/graphic will currently simply send a SIGBUG to unfocused devices. There's potential for fancy handling/virtualization there, but just putting the process to sleep is an adequate first attempt at a solution. XiGraphics server actually does this.
[23:11] <curtisv> Will kgi have to support keyboard1+mouse1 --> display1 k2+m2-->d2 types of setup console wise?
[23:12] <Foske> imho, yes, curtis
[23:12] <Foske> but then again...
[23:12] <philbo> curtisv: yes this kind of assignments of keyboards and mice is already in there and working.
[23:12] <Foske> kgi must be up and running first
[23:13] <skids> curtisv: eventually, but I agree we should not divert our attention to this sort of thing as it distracts us from GPU issues which is kind of the whole point of KGI.
[23:13] <curtisv> yes to all thx
[23:13] <Foske> so...
[23:14] <Foske> what is needed before we can say kgi is really usable...
[23:14] <Foske> bug #14 and 5)
[23:14] <philbo> Foske: and get rid of the red screen.
[23:14] <Foske> indeed
[23:14] <Foske> mode initialisation
[23:14] <golbez> yes, figure out what the hell the vga driver is doing to cause the red screen of death!
[23:15] <Foske> golbez: don't bother: if the vga driver behaves the same as the matrox driver, modesetting fixes everything
[23:15] <Foske> if not... DO bother
[23:16] <golbez> Foske: well, the matrox driver uses the vga driver for text (or I assume it does)
[23:16] <bughunter> nsouch: hi!
[23:16] <bughunter> nsouch: status of FreeBSD port?
[23:16] <nsouch> hi there
[23:16] <nsouch> slow progression :(, but effort maintained!
[23:17] <philbo> Foske: There's something definitely wrong with the vga-text driver. The red screen happens on *every* card. Across chipsets, everywhere. So I'm pretty sure it is a bug.
[23:17] <Foske> golbez: okay, but I don't see it as a major issue: kgi should set into an usable mode when initialized
[23:17] <philbo> Foske: the weird thing is that the only thing vga-text does is it read the contents of all vga registers. *read* only.
[23:17] <bughunter> nsouch: We just started to talk about how to fix the red screen of death caused by the VGA driver.
[23:17] <Foske> philbo: there are vgaregisters affected when reading others
[23:17] <skids> Oh. That sounds like a VGA DAC thing.
[23:17] <bughunter> nsouch: Do you get it under FreeBSD as well?
[23:18] <Foske> for example the ATC registers
[23:18] <philbo> Foske: hrm. that might be it then.
[23:18] <skids> The DAC has a funky register that rotates addresses when you read it.
[23:19] <cow> note to monitor drivers: make monitor driver replaceable; refine .._timings and factor out type specific calcs; (collect common code in parts run through preprocessor -- perhaps not pretty but avoids loads of dup'ed code)
[23:19] <Foske> take a look at the flipflops reset by a read...
[23:20] <philbo> Foske: and unfortunately, mode setting doesn't quite fix it. Mode on a console is set only when the console is opened so if you replace a driver that is already driving a console kgi will check if the new driver can do console, but it won't exactly set it. (I think, I'll go look at the code again)
[23:20] <skids> Anyway the proper code should be in a DAC_ins/DAC_outs function set somewhere, if it still exists.
[23:20] <skids> HI rodolphe!
[23:20] <bughunter> ortalo: hi rodolphe!
[23:21] <nsouch> hi rodolphe
[23:21] <ortalo> Hello everybody.
[23:21] <philbo> cow: yes I agree. If the code is the same for all monitor drivers, replacing only the limits will be much easier.
[23:21] <cow> there's a difference between initial DAC settings between vga-driver and and vga-text.. is somebody aware of the meanings of the bits which are changed?
[23:22] <skids> Anyway we know a probable cuase for the red screen or death, so we should move to another topic and bang it out later.
[23:22] <curtisv> could I suggest that we make an online table of issues by priority in one axis and HW tested with in the other axis to cover the various issues as we fix em. I can (eventually) test fixes on a number of systems. This would be a good resource to keep me directed.
[23:22] <Foske> okay.. one last question: who is after this ?
[23:23] <curtisv> (Be nice to have scripted tests for each issue as well)
[23:23] <golbez> Foske: you mean who will try to fix the red screen of death?
[23:23] <skids> Well, cow's been doing the text console work lately, so he can pick my brain later.
[23:23] <Foske> yupz
[23:24] <Foske> ok. cow, skids, you are the red screen guys ?
[23:24] <skids> OK.
[23:24] <Foske> okay.. the monitor issues
[23:24] <cow> i'll try
[23:24] <Foske> I got DDC 1 working, there is code for both the matrox and the mach32 drivers (where is the mach32 in cvs, by the way)
[23:25] <philbo> Mach32?
[23:25] <golbez> mach8 too!
[23:25] <Foske> eh those ati cards ?
[23:25] <Foske> or am I wrong now ?
[23:26] <philbo> skids: wow. that's old.
[23:26] <Foske> anyway...
[23:26] <bughunter> skids: Do you have the docs for them as well?
[23:26] <philbo> Foske: I have DDC for mach64.
[23:26] <skids> Well VGADOC4b works fine for them up until about mach64 where it starts to miss details.
[23:26] <Foske> the principle of ddc1 works, all I need is a decent glue between the chipsets ddc io and the monitor driver
[23:26] <Foske> oh, mach64.. I was wrong there ;)
[23:27] <philbo> Foske: I didn't put it in cvs though because of the missing glue
[23:27] <bughunter> philbo: Ah - modesetting with the DDC information is possible now?
[23:27] <Foske> not really
[23:27] <ortalo> Do you know if latest ATI chipsets (like Rage128 or Radeon) are compatible with the Mach & co.?
[23:27] <golbez> ortalo: don't think so
[23:27] <Foske> DDC returns timelists and ranges... philbo wrote a range--mode-setting (the multisync driver
[23:28] <Foske> but.. now everything has to be glued together
[23:28] <philbo> ortalo: no they are not. mach8-32-64 were kind of incremental (even though the switch from io to mem based communication broke a lot of stuff) rage128 is the new generation and radeon and so on a very similar.
[23:28] <Foske> I proposed already that the timing formula calculation should be in an include file or general file, so all drivers can use those
[23:29] <skids> Foske: a macro .h for timing formulas sounds like a very good thing (tm).
[23:29] <ortalo> What do you mean by the timing formula?
[23:29] <Foske> philbo: can you continue glueing the monitor driver mess ?
[23:30] <Foske> ortalo: you got a resolution, and the range a monitor can handle. now make timings out of that :)
[23:30] <philbo> Foske: OTOH if we just merged all the driver there's no need for include file, there would be only that file.
[23:30] <Foske> yupz.. but the DDC driver will be HUGE
[23:30] <philbo> Foske: the code would be the same for all drivers, the only thing that would change would be the limits, and the way they are obtained (hardcoded in the driver or implementation of DCC)
[23:30] <Foske> (now only DDC1 is implemented, and not even completely)
[23:31] <Foske> philbo: true, thus the calculation code should take a set of ranges as input value
[23:32] <skids> philbo: well, timelist is slightly different, in that the limits are more strict/specific than mono/multisync
[23:32] <Foske> I got a huge problem with DDC2, but first let's tackle the generic problems
[23:32] <philbo> skids: hrm. Maybe that could be part of the limits: tolerance.
[23:32] <nsouch> Foske: what kind of pb?
[23:33] <skids> philbo: right, besides in the case of LCD's with external monitor ports, the functionality kinda needs to be integrated anyway, so I'd say rolling timelist in with mono/multi would be good.
[23:33] <Foske> timelist means: this monitor can do this mode, that mode and that mode. range means: 30-70 KHz, 50-120 Hz Vsync , 0-120 MHz pixclock
[23:34] <cow> philbo, one file per calc-type which impls some let's say calculate_*(), or did you mean one monitor/calcs.c containing GTF down to timelist?
[23:34] <Foske> nsouch: I need to implement / interface a complete I2C driver
[23:34] <philbo> cow: I meant one implementation of the monitor meta language.
[23:34] <Foske> nsouch : implement = HUGE code, interface = very OS dependant, and might not work on all platforms
[23:34] <philbo> cow: replacing the metalanguage on the fly is nasty. Just changing the monitor limits might be better.
[23:35] <skids> Sidenote: the monitor driver should export an informational element to user-space.
[23:35] <nsouch> Foske: not at all, you just have to connect the chipset driver to linux / freebsd I2C framework
[23:35] <cow> philbo, wouldn't the calcs be hooked up somewhere below the meta-lang (wouldn't that be cleaner?)
[23:35] <Foske> nsouch: true, but the BSD framework differs from the Linux framework
[23:36] <Foske> cow, philbo: imho, the data is much too static at the moment
[23:36] <Foske> the metalanguage shouldn't be affected
[23:37] <philbo> cow: well I don't know. Either the calcs are totally static and the limits are obtained dynamically, or the whole calculation can be changed on the fly. I don't know if it is really necessary though.
[23:37] <nsouch> Foske: yes, and I2C control of the board seems really chipset dependent at least the initialisation
[23:38] <cow> philbo, hm. i did think that it was necessary, no?
[23:38] <philbo> Foske: that's right the data is too static. We'd need some sort of callback to get the data and this would be driver specific. DDC would get them from a monitor, other drivers would just return static data.
[23:38] <Foske> nsouch: and that initialisation can't be done when I hook up to the Linux I2c driver (doesn't know a I2C_init call)
[23:39] <Foske> maybe... we can generate one generic driver, that examines the data returned by the monitor specific part...
[23:39] <Foske> philbo: your ideas sound good
[23:40] <ortalo> Am I wrong or dynamic timing calculation is only useful if one unplugs a DDC monitor and plugs another one instead?
[23:40] <philbo> cow: maybe, but I'm not sure. For things like monosync and timelist there is no real calculation needed. For anything else, there is really no standard the best the whole industry could come up with is GTF. I guess the only thing that isn't covered is a multisync monitor with precisely defined formula that isn't compatible with GTF. Is there such a thing?
[23:40] <skids> IMO we need a diagram of the various subsystems and what metalanguages/structures they provide to each other.
[23:40] <skids> Which we keep up to date and can be used to propose changes.
[23:40] <Foske> ortalo: not really....
[23:40] <ortalo> skids: I agree.
[23:41] <Foske> ortalo: what I miss at the moment is the option to set vsync rates together with the mode, but okay
[23:41] <philbo> skids: yes yes
[23:41] <cow> i want to be able to change on the fly -while running an app- between monosync to timelist and vesa. if this doesn't work it's imho a bug
[23:41] <Foske> ah
[23:41] <Foske> welcome hunger !
[23:41] <hunger> Hi
[23:41] <philbo> cow: this will require re-setting mode.
[23:41] <hunger> I hope you don't discuse secrets here;-)
[23:42] <Foske> hiunger: a log of all said before will be available after the meeting
[23:42] <philbo> skids: I'll take care of that. I like pretty pictures :-)
[23:42] <cow> philbo, yes. that's what makes it not too appealing
[23:43] <nsouch> Foske: I2C should not be so much code, you just have to read / write few registers. But yes, many OS dependent interfaces does not fit with the chipset driver API which is autonomous
[23:43] <Foske> ortalo: that replugging a monitor is a nice feature you get for free when using dynamic data for mode calculations
[23:43] <bughunter> curtisv: Some days ago, you mentioned, you can make KGI working on a plasma display. Does it DDC, too?
[23:44] <bughunter> s/Does it DDC/Does it support DDC/
[23:44] <Foske> ortalo: besides, the DDC driver doesn't know what monitor is connected till the data is there... so the ddc driver will have to adapt the data
[23:44] <Foske> and thus need dynamic data structs
[23:44] <philbo> at any rate, is there a reason for making the *calculation code* changeable as opposed to changing only the *limits* (along with a method for obtaining them) ?
[23:44] <Foske> nsouch: I need to copy / pase most of i2c_algo_bit.c from the linux kernel
[23:44] <ortalo> Yes. But it's rare enough to wonder if dynamic calculations are really needed. (Especially if the user can do them via rmmod/insmod.)
[23:45] <Foske> eh ?
[23:45] <nsouch> ortalo: are monitors really unpluggable? From HW spec point of view?
[23:45] <Foske> the calculation code isn't changable, only uses dynamic data !
[23:45] <Foske> nsouch : yes
[23:45] <Foske> nsouch: there is a PND Plug and Display standard
[23:45] <philbo> Foske: ok. then we agree.
[23:46] <skids> philbo: Let's answer that question in the context of providing standard kernel console services only, as a user-space app with chipset specific knowlege can propose specific timings.
[23:46] <Foske> and... if the data doesn;t countain ranges, the mode calculation should use the timelist modes provided
[23:46] <Foske> this way, the monitor driver can handle any type of monitor
[23:47] <ortalo> Anyway, it seems to me that something more dynamic is needed (we see it via DDC), but maybe a totally dynamic driver (supporting hot-swapping etc.) is not so useful.
[23:47] <Foske> ortalo: well... it is only a little step forward, but okay
[23:47] <Foske> that is for kgi 2.0
[23:48] <nsouch> Foske: I wanted to give it a try with FBSD but could figure how to init I2C without kgi chipset init. I don't have KGI working yet...
[23:48] <ortalo> Well, if it is available, I will use it. (I tend to swap monitors a lot even if I know I shouldn't.)
[23:48] <philbo> skids: hm. I don't think a user-space app should propose timings. Possibly a general hint about the refresh rate, but it should be the kernel that actually decides what gets set.
[23:48] <Foske> first get a monitor driver that acts like described
[23:49] <skids> philbo: I think the app should be able to propose, and the in-kernel code then only has to validate so it is simpler.
[23:49] <Foske> philbo: user apps definitely should be able to propose a vsync, but thats all
[23:49] <ortalo> skids: each subsystem or just chipset and monitor?
[23:49] <skids> ortalo: might as well make it a non-specific meta language element... if a subsystem has nothing to offer it just hands nothing back.
[23:50] <Foske> philbo: you got my ideas about the generalized driver ?
[23:51] <Foske> bughunter: not at the moment :) the chipset driver generates a " monitor switched" event, and after that, the monitor driver has to redo ddc, and modesettiong has to start all over... KGI can't do that atm
[23:51] <philbo> To get back to the main issue: what kind of an interface do we need for the dynamic obtaining of limits? Requirements are: it needs to be replaceable after the driver is loaded. It needs to be per monitor. It has to be able to hook it up to the chipset.
[23:51] <skids> It simplifies the kernel driver's job.
[23:51] <Foske> philbo: answer:
[23:51] <Foske> a list of ranges and a list of timings
[23:52] <Foske> provided by the "specific" driver
[23:52] <skids> philbo: how about a timing loop event that says "new limits have been found" followed by a top-down mode-rework.
[23:52] <philbo> Foske: Right that's the ultimate result. But what kind of interface would we need for actually getting them? GetLimits callback?
[23:53] <nsouch> user-land app is not stupid, pcmcia is managed outside the kernel, the kernel driver only allow access to HW
[23:53] <cow> skids, i did something like this locally and it looks good to me
[23:53] <philbo> skids: good thinking, integrating it into the timing loop would definitely be good.
[23:53] <Foske> sound good, but then (thinking about multihead) we would need: GetLimits (int head,...);
[23:54] <philbo> Foske: I was thinking of a function pointer for each monitor. (So that we can have a DDC monitor as well as a non DDC one at the same time -- a very likely situation)
[23:54] <Foske> sounds good...
[23:55] <skids> Basically we just need to store the requested mode (not the eventually programmed mode) which I believe we already do (?) and then a mechanism for the subsystem to restart the timing loop.
[23:56] <skids> (Plus we also probably need to freeze access to the hw accel/fb during the reporgram.)
[23:56] <Foske> that lock is definitely something we need
[23:56] <Foske> I need it for DDC1 too
[23:57] <cow> skids, yes. only one TC_RE per display at a time
[23:57] <skids> Which brings us back to VC unmap... maybe a monitor switch should be essentially a vc switch from vc X TO vc X :-)
[23:57] <cow> s/TC_RE/TC_REINSTATE or RECHECK or whatever
[23:58] <Foske> skids: is an option
[23:58] <philbo> cow: recheck sounds pretty good.
[23:58] <skids> (Plus a double CTRL-ALT-FN will cause a mode reset, a feature I've always wanted :)
[23:59] <cow> (a nonstatic suicide(). well :)
[00:00] <skids> OK, it sounds like locking up the accel/fb for VC switch and for modeset is a high priority item, to me.
[00:00] <philbo> skids: I suppose it would be similar. From KGI point of view (as opposed to KGIM) the display has one big chunk of data for the mode which contains everything about it. So a recheck would just adjust this chunk of data (change the timings) and KGI could just reset the mode (just what happens during a vt switch)
[00:01] <ortalo> skids: accel/fb are mode resources. If the mode is not yet set, they are not available. So why this locking at modeset? Do you mean mode-re-set?
[00:01] <philbo> skids: I don't really think we need a lock or anything, just implementing the map/unmap functions.
[00:01] <skids> Cool, if it's already there, more power to steffen :-)
[00:02] <Foske> philbo: don't forget that kernel drivers are multientrant !
[00:02] <skids> But we wouldn't want the conents of accel pipes or fb damaged if the new mode is not different...
[00:02] <bughunter> ortalo: A mode is always set. If it is not a graphic mode, then it is a text mode. :)
[00:02] <nsouch> philbo: how would KGI decide to reset the mode? If limits are overan? If a better mode is available?
[00:03] <ortalo> nsouch: if asked to by an authorized user app.
[00:03] <Foske> before you set a mode, accel must be idle, but in the meanwhile, the accel buffer can be filled and filled again
[00:03] <philbo> nsouch: I don't know. Maybe DDC can tell you when the monitor changes?
[00:03] <ortalo> NB: the driver must take care that the accel buffers get flushed correctly before changing the mode.
[00:04] <Foske> DDC can't... your chipset driver must detect a ramdac output error or something familiar
[00:04] <nsouch> philbo: Everyone would expect mode downgrading if current mode is not supported by the newly plugged monitor
[00:04] <skids> OK, someone needs to volunteer to make a step by step list of what needs to be done on VC switch/monitor change.
[00:04] <Foske> you can only detect monitor changing by polling on vsync
[00:05] <Foske> a job for me and philbo ?
[00:05] <philbo> nsouch: that's ok for the user, but I wouldn't want the application to have to respond to mode changes it didn't initiate. Even if the newly rechecked mode is not the same the chipset should behave the same.
[00:05] <nsouch> polling inside the kernel does not seem good to me :(
[00:05] <philbo> Foske: sounds good.
[00:06] <skids> "polling" is fine if it is IRQ or tasklet driven.
[00:06] <skids> How often do we need to poll to catch monitor switch, say, if a KVM is used?
[00:06] <philbo> skids: right. I have a feeling some chipsets actually generate a special IRQ if the monitor is unplugged.
[00:06] <nsouch> philbo: that's true
[00:06] <Foske> skids: every vsync is recommended by VESA
[00:07] <nsouch> skids: I have currently W$ polling my CDROM and that irritates me :)
[00:07] <Foske> philbo: can be, though that isn't mandatory for P&D aware chipsets
[00:07] <skids> OK, that makes retrace IRQ mandatory for guaranteed hotplug safety... a note for the tech docs.
[00:08] <Foske> skids: that note is a remark in the VESA DOCS already
[00:08] <nsouch> philbo: at least then KGI should off the monitor as the monitor generally do when the card exceed their limits
[00:09] <skids> Well, this is a good thing IMO, because it forces us to get those IRQ handlers written :-)
[00:09] <cow> speaking of tasklets.. currently console and keyboard is run through bottomhalves, which should be fixed. afaics a usable solution (for the lniux part) is not to be expected before 2.7 (spring/summer 2003, probably). what should we do about this?
[00:09] <philbo> a quick scan of documentation for certain, further unspecified ATI chipsets, reveals that they do support IRQ on hotplug.
[00:09] <cow> linux, of course
[00:10] <ortalo> Concerning VC switch. What states should be saved by the driver? IMHO, VGA-text state should be saved nearly entirely (that's ~64ko, big, but well). In a graphics mode, I guess the accel engine internal state must be preserved but anything more is probably much bigger (well cursor shape excepted).
[00:10] <nsouch> cow: of course
[00:10] <philbo> cow: what exactly that useable solution is?
[00:10] <cow> ortalo, i don't think it's neccesary to save the font part, so it is 32k at worst, imo
[00:11] <nsouch> cow: in FreeBSD you could have a dedicated kernel thread
[00:11] <cow> philbo, tasklets and queues
[00:11] <philbo> cow: doesn't 2.4 have tasklets?
[00:11] <skids> ortalo: I think saving of the fb should be an optional feature that must be enabled by an app, if allowed by the sysadmin. fb's are big these days but so is core RAM.
[00:11] <ortalo> cow: I the font gets scrambled, the text head is unusable on restore! I'd rather loose the content of the screen than the font.
[00:12] <ortalo> skids: fbs are not as big as VRAM. Whatabout textures?
[00:12] <Foske> well.. more important to the question what you want saved is, what can the user level restore ?
[00:12] <skids> WHich is why apps shouldn't ask KGI for more of the VRAM than they actually intend to use :-)
[00:12] <cow> philbo, yes. but i didn't want to fill in those bits for >=2.4.17 as it's supposed to be stable, and i can't guarantee that it will be right from the start
[00:13] <ortalo> Even if it sounds feasible nowadays to save the entire fb (or even the entire VRAM), I would not really go that way. Maybe fb(screen only) saving is feasible.
[00:13] <Foske> Unreal Tournament takes 2/3 seconds preloading all textures... donnow if that is what you want every time...
[00:13] <skids> Well, that's why the app must request it; it would not be a default setting.
[00:13] <ortalo> Foske: Well, if the user VC-switched off, maybe he wanted that 2/3 seconds...
[00:14] <cow> ortalo, if font's get scrambled, userspace/ram-location is supposed to provide sane state, i guess
[00:14] <Foske> also true
[00:14] <Foske> and you shouldn't console switch when playing games ;)
[00:14] <ortalo> cow: text-based app tends to be simple.
[00:14] <skids> We also have the option of not saving the part of the fb that isn't used by text/fonts untilk a second graphical terminal is switched to.
[00:15] <Foske> naah
[00:15] <ortalo> skids: that's an optimization.
[00:15] <ortalo> So what do we want to guarantee to applications.
[00:15] <nsouch> Foske: Except at the Office when your boss enters the room :)
[00:15] <Foske> you can never know that you'll come back
[00:15] <skids> And if we engineer things right, when a second app asks /dev/graphic for space it allocates portions of space that are unused in VRAM first.
[00:15] <Foske> immediately
[00:15] <ortalo> Personnally, I'd guarantee full state for VGA-text. First. What do you think?
[00:15] <skids> I think that the "mandatory" KGI driver spec should not specify saving accel/fb content.
[00:15] <Foske> you switch to textmode: save only the part overwritten in texmode... switch on to ANOTHER graph mode... and then ?
[00:16] <ortalo> skids: I meant *internal* accel state. That one is probably mandatory to virtualize the accel engine.
[00:16] <philbo> skids: but we don't really have a way of asking for room. And if we did have such a thing then saving is no real issue anymore as it would be handled automagically by the system for requesting room.
[00:16] <skids> Then you take the 2/3rd second hit, but if you switch to text and back to same console, no 2/3rd second hit.
[00:17] <Foske> hmzz
[00:17] <skids> philbo: we do have a way to ask for room, we just need to enhance it probably -- easier now with the ICOTL.
[00:18] <Foske> okay, requires communication with user level, but ok
[00:18] <nsouch> * Why bother about saving fb if the application doesn't stop when it looses focus, no?
[00:18] <ortalo> If VRAM room reservation is granted to userspace, then userspace should manage state saving...
[00:18] <skids> nsouch: the app will have to stop, or it will get blocked.
[00:19] <bughunter> ... by libkgi...
[00:19] <skids> ortalo: IMO we MUST avoid relying on userspace scheduling to accomplish the state saving task during VC switch.
[00:19] <ortalo> nsouch: saving the fb may be provided for convenience.
[00:19] <nsouch> bughunter: at the next graphic access?
[00:20] <philbo> skids: well, we could remap the mapped fb to the saved buffer and let the app continue drawing, only it would be to system memory.
[00:20] <ortalo> skids: yep. I agree. But userspace can use VRAM-room as a cache (keeping original content in main RAM). So it can provide state-saving without needing synchronisation with the kernel driver.
[00:20] <skids> nsouch: right, the unmap() we were referring to that needs to be implemented causes a page fault when the app tries to use /dev/graphic when it has lost focus.
[00:21] <skids> ANyway I think most of this is "for the future" talk and we should concentrate on madatory base KGI driver specs -- what should the mandatory base driver save?
[00:21] <philbo> skids: I'd say only vga-text saving should be mandatory.
[00:21] <Foske> true skids...
[00:21] <skids> IMO basically just the video mode, and some info to tell the app how much accel fifo content was destroyed.
[00:21] <nsouch> skids: so even if the application executes, you can redirect it to the saved area.
[00:21] <Foske> ok
[00:21] <Foske> for KGI 1.0 :)
[00:22] <ortalo> skids: If userspace does not want to comply to such constraints, IMHO, it should not be allowed to reserve arbitrary VRAM space. (It has already got a fb. And I'd agree to save that in the kernel.)
[00:23] <skids> nsouch: Yes, that's an option, but SW fallback would then have to be relinked by the app because in a lot of cases the chipset cannot support a text mode and have the GPU run, as the GPU draws some values from the registers shared by the CRTC/etc.
[00:23] <Foske> you know you run on a multitasking / multiterminal OS, so write decent software... :)
[00:23] <bughunter> skids: The driver should also provide some information to userspace (concerned to libgalloc)
[00:24] <ortalo> skids: when you mean saving the video mode, you mean the fb or only the mode parms?
[00:24] <skids> bughunter: yeah, we'll cross that bridge when we actually get to that continent :-)
[00:24] <bughunter> skids: ok
[00:25] <Foske> to provide info, you first need info to provide
[00:25] <skids> ortalo: just the mode parms and palette. Of course, I am not considering kernel vc's as merely an APP -- they get content and font, too.
[00:25] <bughunter> skids: I hope, libgalloc's X-target is ready then to be used as a reference target for the libkgi one.
[00:26] <ortalo> skids: ok. (add the cursor shape btw)
[00:26] <skids> I am finding X more and more frustrating to work with and am wondering whether that was a good choice.
[00:26] <skids> ortalo: but of course! :-)
[00:26] <cow> how should userspace parts for ggi be provided? would it be possible to generate them, cleanly? or are those ment to be 'written'?
[00:27] <skids> OK, so we need a list of what gets done 1) on VC switch from text to graph app, 2) on vc switch from graph app to text, and 3) graph-app to graph-app.
[00:27] <ortalo> cow: what do you mean by "generate"?
[00:27] <bughunter> cow: The clean way to do that through libkgi.
[00:27] <ortalo> bughunter, skids: we also need a list of the information userspace wants from the driver.
[00:28] <skids> Oh, and 4) on monitor swap/mode reporgram.
[00:28] <cow> ortalo, generate them out of the kernel drivers
[00:28] <skids> ortalo: That's pretty much model-specific, so I's say we make it a free-form string.
[00:28] <Foske> skids: on monitor reprogram / modechange, you try not to change the virtual image size, even if the new monitor enforces a BIGGER image
[00:28] <skids> ortalo: except for the monitor part which we can standardize.
[00:29] <Foske> skids: so, nothing happens with your framebuffer then
[00:29] <bughunter> ortalo: GGI (libgalloc in particular) needs the information what the app must do to use a certain feature at all and what it can do else.
[00:29] <ortalo> cow: userspace part and kernel part have pretty different functions, they are not so related. They probably only share the main hw-specific header file.
[00:29] <nsouch> skids: which is close to vc switching finally
[00:29] <cow> ortalo, yes. ok
[00:29] <ortalo> skids: fully free-form? It means only hw-specific userspace can parse it?
[00:30] <skids> Foske: right, even if the new monitor cannot do a mode "that small", it is easy enough to tweak the blanking settings to make a smaller mode with a big bloack border.
[00:30] <skids> ortalo: I would say yes, for now.
[00:31] <skids> ortalo: This makes things easier for fast development, and as standard forms become evident we can decide to standardize them to reduce the userspace code.
[00:31] <Foske> well... easy... easy........
[00:31] <ortalo> bughunter: don't you want to lobby with me to convince skids to build a small standard info struct?
[00:32] <skids> OK, not as easy from the userspace perspective, but which would you rather have an easy time at -- kernel programming or userspace programming :-)
[00:32] <ortalo> (I'll really have to write that userspace code...)
[00:32] <bughunter> ortalo: In libkgi's API?
[00:32] <philbo> skids: actually, that's what I used for the kgi target for libggi. Currently, every resource has a description string. So the name of the accelerator is assumed to be " " that way the name of the sublib loaded is given by the first word and the rest of the string can be parsed by the sublib
[00:32] <ortalo> skids: ok, true. But well...
[00:32] <skids> Actually I'm a regular font of abstraction :-)
[00:33] <skids> philbo: my thoughts exactly :-)
[00:33] <bughunter> ortalo: A _complete_ KGI driver consists of two parts: The kernel part and the userspace part (which is in libkgi like a libggi target)
[00:33] <ortalo> bughunter: More precisely, for KGI kernel API.
[00:33] <Foske> yeah : abstraction is nice... the first hings that usually disappear when abstracting are the problems :)
[00:33] <nsouch> ortalo, skids: no, in kernel, you don't have to know POSIX
[00:33] <skids> I just don't think abstracting RIGHT NOW is appropriate.
[00:34] <philbo> ortalo: if you feel like writing userspace code you might want to consider adding a matrox sublib to libggi.
[00:35] <ortalo> philbo: I intend to. As soon as Matrox stop producing chipsets that do not work with my software...
[00:35] <philbo> bughunter: why keep the libkgi part in there? libggi has all we need.
[00:35] <nsouch> ortalo: or you get your soft working with their hw ;)
[00:35] <bughunter> philbo: KGI is NOT intended to be only and only used by GGI.
[00:35] <Foske> ortalo: maybe you should skip trying to get every chipset to work now, and focus on making the chipsets that DO work, work perfectly
[00:35] <bughunter> philbo: Otherwise, each KGI user has to write its own userspace KGI driver...
[00:36] <ortalo> It seems to me that libkgi really has a reole to play to avoid that driver writers produce similar code for handling common issues (such as mode-setting, info gathering, or for standard resources like cursor, etc.)
[00:36] <philbo> bughunter: but then you have to create an interface for libkgi and I would not be surprised if you ended up creating a second libggi.
[00:36] <ortalo> Foske: Yep. But I'd like to do that on a widely available chipset and... first they deprecated the G200, then the G400, then the G450, then the G500...!
[00:37] <Foske> libkgi surely must adapt the API GGI can use easily IMHO
[00:37] <bughunter> philbo: No, because libggi will have a libkgi target, which simply relies on libkgi.
[00:38] <bughunter> philbo: The libkgi target replaces libggi's kgi-target finally.
[00:38] <Foske> ortalo: my opinion: stick to the G200, G400 and G450 till it works...
[00:38] <bughunter> Foske: right.
[00:38] <ortalo> Foske: That's what I try to do in fact. Only the 50 needs some more work.
[00:39] <philbo> I really don't see the need for libkgi. LibGGI was designed to be perfectly minimalistic and has a fabulous sublib loading system for providing chipset specific drivers and extensions for possible other interfaces which integrates well with the sublib system. That's exactly what the user-space of kgi should look like and adding another layer in between makes no sense to me.
[00:39] <Foske> imho, libKGI as a standalone project wa snonsense too
[00:39] <ortalo> philbo: maybe that's just a problem with the name. As bughunter says, I speak most of the "kgi-target" in fact.
[00:39] <Foske> and PhoeniX should never have existed...
[00:39] <golbez> bughunter: I don't understand. If we're going to have a userspace library for kgi, why not use ggi? Wasn't that the initial intention of ggi.. to be the userspace side of kgi? I realise ggi have evolved since then but ...
[00:41] <ortalo> golbez: Steffen Seeger want an additional intermediate layer between the libggi kgi-target and the KGI kernel drivers. This intermediate layer could have had several implementations.
[00:41] <ortalo> golbez: s/want/wanted/
[00:41] <skids> Let's work on GGI for now, and then decide later id we want KGI -- the work on LibGGI KGI target will be easy to reuse in LibKGI.
[00:41] <ortalo> golbez: for me, the important thing is the "kgi-target" of libggi.
[00:41] <ortalo> skids: I fully agree.
[00:43] <ortalo> That's mainly a naming problem, KGI target is clearer it seems.
[00:43] <nsouch> Didn't directfb take the role of kgi in ggi?
[00:43] <skids> OK, I have a topic I want addressed before anyone scoots :-)
[00:43] <nsouch> s/didn't/isn't
[00:44] <Foske> okay...
[00:45] <nsouch> msg cow 'grins' means?
[00:45] <bughunter> nsouch: no. And directfb never will be.
[00:45] <Foske> so libKGI will be dropped for now as a separate target, and all focus will be on the GGI - KGI target
[00:45] <Foske> eh
[00:45] <Foske> as a separate project
[00:46] <cow> nsouch, i was referring to skids' ammunition consideration. anyway
[00:46] <Foske> who will work on the KGI target for GGI ?
[00:46] <Foske> I won't for sure :)
[00:46] <golbez> Foske: that's gone
[00:46] <skids> me for one.
[00:46] <ortalo> Foske: why do you say as a separate project?
[00:46] <bughunter> philbo: You're thinking about libkgi goes not far enough. You must think further to understand better.
[00:47] <Foske> I thought we just agreed we'll use ggi for the userlevel part
[00:47] <nsouch> Won't we loose Phoenix without libkgi maintained?
[00:47] <Foske> what is the use of PhoeniX ?
[00:47] <Foske> what does it provide XGGI doesn't ?
[00:47] <ortalo> nsouch: IMO Phoenix can be made to work with libggi.
[00:47] <cow> nsouch, phoenix is dead. long live xggi
[00:48] <nsouch> acceleration?
[00:48] <ortalo> Foske: different code base.
[00:48] <Foske> XGGI will do 3D accelleration in future
[00:48] <golbez> Foske: there is an updated kgi target in ggi cvs. It should work with any kgi driver (needs the wip tree).
[00:49] <Foske> I hope, if not, GGI is doomed anyway
[00:49] <nsouch> ortalo: a shame to kill it then
[00:49] <Foske> sure, but I told Steffen years ago that I didn't see the need for PhoeniX. And I still stay with that conclusion
[00:49] <ortalo> golbez: XFree has developped its own approch to 2D accel and 3D accel. Maybe the code base upon which Phoenix is based could be easier to adapt to libggi.
[00:50] <nsouch> golbez: keeping overhead of the driver infrastructure! Why?
[00:50] <skids> OK, new topic, if I may: we should look to provide userspace system ram texture --> VRAM accelerated transfer ASAP after the basic functionality issues are worked out.
[00:51] <golbez> ortalo: that is an option too.
[00:51] <ortalo> skids: VRAM mmap or something else? (blitting from main memory to VRAM? pseudo-DMA?)
[00:51] <nsouch> ortalo: yep!
[00:52] <golbez> nsouch: by using XFree we would have a widely maintained x server and one easily maintained driver
[00:52] <ortalo> golbez: Pheonix code base remain to be studied (Steffen is/was the only one to know it well.)
[00:52] <ortalo> Well, enough on Phoenix I guess. We will look at it later, when the KGI target works.
[00:53] <philbo> PhoeniX is a dead branch. The best way now would be to write a ggi module for XFree86 4.x This would be so very much more user friendly (just dropping a .o in the right directory)
[00:54] <skids> ortalo: the latter.
[00:54] <philbo> ortalo: the kgi target does work.
[00:54] <skids> It will give us an edge up on "the competition"
[00:54] <ortalo> skids: is memcopy() to (off fb) mmap()-ed portion of VRAM so slow?
[00:55] <skids> Certainly slower than letting it be done by DMA>
[00:56] <philbo> ortalo: really slow. Things like movie playing can really benefit from DMA.
[00:56] <ortalo> Final note: I am not a fan of Phoenix, it's just I have doubts wrt XFree (it's such a beast).
[00:56] <bughunter> memcpy() data to VRAM --> never do this on a PPC!
[00:56] <ortalo> skids, philbo: pseudo-DMA is not really DMA...
[00:56] <bughunter> ... due to internal cachings within the CPU.
[00:56] <ortalo> bughunter: with hardware byte-swapping.
[00:57] <cow> bughunter, that's why skids want's to talk about translating to direct to direct blitting
[00:57] <skids> bughunter: well that means LibGGI is pretty much broken on PPC, eh?
[00:57] <bughunter> skids: No, but the fbdev-target was. IIRC, Marcus Sundberg fixed it.
[00:58] <ortalo> The problem with blitting from userspace to VRAM is having the userspace memory locked during the transfer, and allocated at proper place (e.g. with AGP constraints).
[00:58] <skids> ortalo: Yes (but I want to tackle the non-AGP case first.)
[00:58] <skids> We have 2 options:
[00:58] <ortalo> In fact, allocation is probably the biggest problem currently. KGI has to provide some "vramcapable_malloc()".
[00:59] <skids> 1) The KGI driver allocates/maps RAM or 2) The KGI driver uses user app's mlocked RAM.
[00:59] <cow> protection-wise 2.4.19 is doable since it has a generic mprotect, as a sidenote
[00:59] <ortalo> skids: what about FreeBSD?
[00:59] <skids> What does FreeBSD have in this area?
[01:00] <ortalo> s/skids/nsouch/
[01:00] <ortalo> Option 2) is dangerous. If the RAM is not at the right place...
[01:01] <cow> ortalo, i don't think allocation is a problem. you will be able to set whichever constraints you want on the allocation
[01:01] <skids> Right option 2) is also dangerous if the user unlocks/unallocs the RAM.
[01:01] <ortalo> philbo, cow: plus the security constraints (easy DoS with many allocations).
[01:02] <Foske> it sure is far too complicated for me to follow at the moment... I should get some sleep
[01:02] <bughunter> option 2) would be a job for libkgi
[01:02] <skids> But option 2) does have some good points in that it would make it easier for certain existing gl's to be retrofitted to use KGI.
[01:02] <skids> and option 2) skirts the DoS issue because if a user can mlock too much RAM, that's the OSes problem, not KGI.
[01:02] <skids> :-)
[01:03] <philbo> We should move on for the sake of Europeans :-) Multihead: images or displays?
[01:03] <Foske> lol
[01:04] <cow> ortalo, true. i don't really feel like doing a rate limited allocator (wouldn't be too hard, i guess, but i don't see the point) as long as there's panic() or oom()
[01:04] <skids> s/closer/closure/
[01:04] <Foske> *CLICK*
[01:04] <Foske> :)
[01:04] <bughunter> lol
[01:04] <Foske> Anyway...
[01:04] <ortalo> BTW, when the accel engine channel is available, at least on the Matrox, blitting from userspace is feasible. All the driver needs to do is to do the virtual->physical translation in the command stream (involves parsing the command stream however).
[01:05] <Foske> IMHO Images
[01:05] <bughunter> Foske: Not that that you click (or kick) off yourself... :)
[01:05] <Foske> /mode +b #kgi /me
[01:06] <ortalo> Did we get to next topic?
[01:06] <Foske> yes...
[01:06] <Foske> images or displays
[01:06] <ortalo> IIRC multiple images were for stereo or double-buffering no?
[01:07] <philbo> Foske: images really fit so nicely. The only issue is that each image will have to have its own monitor limit calculation. I don't quite know where to hook that up (though at least the unified monitor driver will make it much simpler)
[01:07] <Foske> here, it really is getting late in Europe :)
[01:07] <skids> I'm for images as well, just i think we need to put some thought into sharing the same display between multiple apps, each with their own image.
[01:07] <philbo> ortalo: no, that's frames.
[01:07] <ortalo> Oops. Sorry.
[01:07] <Foske> I just heard you are writing that unified driver, so that's no problem =)
[01:08] <ortalo> Why not both possibilities?
[01:08] <bughunter> philbo: How about using one logical display? There you can hook up all the images.
[01:08] <bughunter> Foske: Didn't you sleep some hours in the afternoon (as I did)?
[01:09] <philbo> ortalo: well, sure I guess. It's just that multiple displays will require serious redesign of KGIM. I don't know if anybody's willing to do it.
[01:09] <Foske> bughunter: I suffer from ME, I sleep almost all day at the moment
[01:09] <skids> philbo: maybe that diagram will help figure out what needs to change and how to get each image it's own mode management structures.
[01:09] <philbo> bughunter: that's pretty much exactly what images give us.
[01:09] <nsouch2> just lost my connection :(, I'm back
[01:10] <Foske> oki
[01:10] <Foske> nsouch2: multihead: images or displays...
[01:10] <ortalo> It seems images for multihead are the simpler way to go.
[01:10] <philbo> skids: right. (BTW, they do have mode management structures, that's why they fit so nicely, it's just that there are assumptions in kgim structure about the fact that each display should have only one monitor. Not very many though)
[01:10] <Foske> what is against images ?
[01:11] <philbo> Foske: user space support.
[01:11] <nsouch2> they where not designed for this purpose
[01:11] <skids> What if we changed to one /dev/graph per *image* ?
[01:11] <philbo> nsouch2: I'm having trouble understanding what were they designed for
[01:11] <Foske> philbo: yes and no... now it's easier to see these images belong together in some way
[01:12] <philbo> skids: I was thinking about that and it seems like a good idea, but a lot of work. I guess the advantage would be that even when that doesn't work it still would be quite useable.
[01:12] <golbez> skids: I think that would make it difficult to set up 2 images (or heads) into a single image
[01:13] <nsouch2> philbo: they look like filters
[01:13] <bughunter> skids: The more /dev/graph* files we need, the harder it becomes to convince Linus in future. (Linus won't add more major,minor numbers)
[01:13] <cow> skids, i always thought that the way to go was displays. apart from that, providing several 'targets' in /dev/graphic/* sounds nice
[01:14] <Foske> bughunter: I wonder if that still holds with the devfs system
[01:14] <bughunter> Foske: I don't know. I don't wish.
[01:14] <philbo> Foske: that's right. It might not be such a big issue, if one thinks about what most people do with their dual head systems (I know its nice to think of all possibilities, but it might be important to concentrate on the most common scenario) very few people will hook up two keyboard and two mice to their multihead system and use it as two computers. Most likely they will use one program (X server most likely) that will control both heads,
[01:14] <philbo> case there really is no problem.
[01:14] <Foske> bughunter: and we use one major number, only more minors
[01:15] <Foske> and we're not talking about claiming 1000's... only 2 or 3 more
[01:15] <cow> foske, bughunter, it's a fight for major numbers, which should be factored out anyways, for a clean system. so, as long as there are static major numbers, that's no problem
[01:15] <ortalo> philbo: or they will play quake on one head and look at kde on the other
[01:16] <Foske> cow: we claimed one major, we still claim one major....
[01:16] <cow> foske, bughunter, an no problem with non static majors, too, of course
[01:16] <skids> philbo: I always thought the purpose of the second monitor was to be able to watch those screen savers you miss because they only come on when you leave your system idle :-)
[01:17] <nsouch> Doesn't devfs provide some local numbering for huge drivers?
[01:17] <nsouch> skids: :))
[01:17] <Foske> skids: never seen quake-360 ?
[01:17] <philbo> ortalo: in which case the quake still runs as an X application (GLX) because you have only one keyboard and mouse and so you need the X server to manage who gets the input
[01:18] <bughunter> Foske: Do you have a panorama-like screenshot?
[01:18] <skids> Foske: I think GTA4 was rumored to slate multimonitor support for the PC version :-)
[01:18] <philbo> Foske: Triple head cards are so great for that, you don't get the disturbing seam right in the spot you look at the most.
[01:18] <ortalo> philbo: you would use the GGI version of quake no? and the Qt-on-GGI version of KDE... :-)
[01:19] <Foske> nopez, sorry
[01:19] <Foske> anyway
[01:19] <ortalo> philbo: do not talk me about triple head cards without specs...
[01:19] <Foske> where are we....
[01:19] <golbez> ortalo: you sound bitter about that ;)
[01:19] <skids> ortalo: triple head is just 4-head with one unplugged :-)
[01:19] <Foske> maybe we should quit here and focus on the things we already discussed...
[01:19] <philbo> ortalo: ah. fair enough :-) Seriously, these are exactly the problems I have with exposing multihead as separate images. I'm hoping we can solve them through /dev/graphic.
[01:20] <skids> ortalo: Or one mounted up for HUD :-)
[01:20] <skids> Yeah, I have housemates that are hungry and want to order pizza. I should be going.
[01:20] <ortalo> skids: how many combinations with 2 DDC1 and 1 DDC monitor?
[01:20] <philbo> nsouch: I wish we had Steffen to explain images purpose. I'm not sure they are filters, isn't that the purpose of the dot stream converters (DSC) ?
[01:20] <nsouch> I've just forwarded a mail to the list that was never received, about multihead. Actually, I definitely think kgim shall handle multihead.
[01:20] <ortalo> I think Foske is right. What do we decide?
[01:21] <nsouch> has this discussion been recorded? Stupid, certainly.
[01:21] <Foske> I'll extract some sort of " who does what" tomorrow and mail it to the mailinglist
[01:21] <golbez> nsouch: it has been logged
[01:22] <Foske> even twice :)
[01:22] <bughunter> skids: Not necessarily. If you have one 2-headed and one 1-headed card, then triple head is NOT 4-headed with one unplugged. :)
[01:22] <nsouch> philbo: kgi/doc/kgi.sgml addresses images. At least, I understood it is not for multihead.
[01:22] <ortalo> I want a 4-port Matrox too. With specs.
[01:22] <Foske> if the US is Nuked, we still got a log in Europe :)
[01:23] <Foske> mea culpa
[01:23] <golbez> US junior
[01:23] <ortalo> 4 specs.
[01:23] <Foske> "teh other side of that shitty sea"
[01:23] <philbo> Foske: great. People can respond to that and make commitments.
[01:23] <skids> Foske: Tell the CIA agents I said hi when they come knocking :-)
[01:23] <skids> Foske: Actualy, don't :-)
[01:24] <Foske> okay
[01:24] <bughunter> skids: Should I do for him? ;-)
[01:24] <Foske> philbo: you and I focus on the monitor driver ?
[01:24] <Foske> CIA already knows now
[01:24] <Foske> All my IP traffic is logged
[01:25] <cow> so.... philbo and golbez will look at multihead by means of images first.
[01:25] <bughunter> Foske: You're kidding?
[01:25] <golbez> cow: k
[01:25] <nsouch> Foske: I'd like to give DDC2 a try if I could init Matrox DDC2 without the whole chipset/kgi running.
[01:25] <cow> bughunter, wish he was ;)
[01:26] <Foske> the libggi stuff is done by ...
[01:26] <bughunter> CIA? :)
[01:26] <philbo> Foske, cow: ok.
[01:26] <nsouch> FreeBSD/KGI was not addressed, it will when there will be something visible ;)
[01:26] <Foske> bughunter: I work for the Dutch KLPD (Sort of FBI)
[01:26] <ortalo> I'll have to do the Matrox-specific libggi stuff.
[01:26] <cow> golbez, if you think it's viable. i don't know
[01:26] <Foske> Kind of too
[01:27] <Foske> okay
[01:27] <philbo> Foske: golbez and I did the basic libggi stuff. I also have a mach64 sublib for ggi yet to commit.
[01:27] <Foske> I take care of the DDC2 implementation besides the generic monitor driver cleanup
[01:27] <nsouch> We need steffen point of view for the multihead issue. He's finishing is PhD.
[01:27] <Foske> philbo: your mach64 driver in thw wip tree is up to date ?
[01:28] <ortalo> philbo: I'll take insipiration from the mach64 sublib for the Matrox one (understand: steal the code) as soon as I'm done with these stupid PLL transistors.
[01:28] <ortalo> And the ->wip transition.
[01:28] <philbo> nsouch: I know. I wish there was a way to get an "emergency" mail to him. Maybe I'll just have to get a plane ticket to germany :)
[01:28] <Foske> isn't too far from France :)
[01:29] <ortalo> I got an answer from Steffen on August 19. At least, he's still alive.
[01:29] <philbo> Foske: It is up to date but not complete. I have some usability issues to address. (and the DDC stuff isn't there either)
[01:29] <skids> Foske: and these days, you could probably get there by boat :-/
[01:29] <cow> i'll listen to skids and perhaps do other stuff too, fwiw
[01:29] <nsouch> Foske: true
[01:29] <Foske> of course... you and I will take a look at the interface issues when working on the monitor driver, ok ?
[01:30] <philbo> Anybody volunteered to look into VC switching?
[01:30] <Foske> that was for philbo
[01:30] <ortalo> The mail Nicolas forwarded seems interesting wrt image/display thing. Maybe this issue can be further debated on the list.
[01:30] <nsouch> ortalo: I got one from today! "I currently finish (writing) my PhD, so I will probably be more active again
[01:30] <nsouch> in a few months. (At least I hope)."
[01:30] <nsouch> ... said steffen.
[01:30] <Foske> in a few MONTHS ???
[01:30] <Foske> gee
[01:30] <Foske> long PhD doc
[01:31] <golbez> nsouch: that's good news!
[01:31] <nsouch> Foske: :) no, good PhD doc
[01:31] <ortalo> Foske: It's usually 6 months to write the PhD and then 3 months latency before defending it in front of a jury. I guess he is at the end of the writing.
[01:31] <bughunter> better late than never.
[01:31] <Foske> anyway...
[01:31] <Foske> still important remarks ?
[01:32] <Foske> otherwise I go to bed
[01:32] <Foske> 01:32 here
[01:32] <ortalo> Which Matrox model has 4 ports?
[01:32] <philbo> I guess nobody wants to touch vcs...
[01:32] <Foske> I'll keep the log on so I don't miss a thing
[01:32] <ortalo> 01:28 here, damn jetlag...
[01:32] <Foske> :)
[01:32] <bughunter> Foske: Your clock goes a wrong a little. Your clock is about 4 mintues ahead.
[01:33] <philbo> I'll try looking into the map/unmap issues but I promise no results :-)
[01:33] <nsouch> Worse here, 1:34
[01:33] <Foske> bughunter: can be.. my clock synchronisation hack doesn't work anymore (synced my PC with my VCR)
[01:34] <nsouch> So bye, see you on the list.
[01:34] <ortalo> VC switch?
[01:34] <Foske> night everyone :)
[01:34] <Foske> see you
[01:34] <ortalo> any candidate?
[01:34] <philbo> Foske: you should use and official ntp server
[01:34] <bughunter> Foske: sleep well
[01:34] <bughunter> :)
[01:34] <ortalo> Well, I'll try to think to that.
[01:34] <Foske> philbo: naah, as an Electrical Engineer, this is more fun...
[01:34] <philbo> Foske: g'night
[01:35] <Foske> Foske &
[01:35] <philbo> lol
[01:35] <ortalo> Have a good night too (or maybe evening?)
[01:35] <bughunter> Foske: Don't press CTRL + Z :)
[01:36] <bughunter> ortalo: evening? I would say, good morning :)
[01:36] <ortalo> Everything was simpler when the earth was flat...
[01:37] <ortalo> Well, I really need to go to bed.
[01:37] <ortalo> I'm only saying stupid things.
[01:37] <ortalo> (BTW, things were also simpler when Matrox boards only had one head.)
[01:37] <philbo> ortalo: hehe
[01:37] <cow> ortalo, good night
[01:37] <bughunter> ortalo: Let's start as a pyjama party! :)
[01:37] <philbo> ortalo: night
[01:37] <cow> ortalo, that's true 8)
[01:38] <ortalo> Good bye. At least, my little boy had a very nice dinner... Thanks for him.
[01:38] <ortalo> (And he went to bed early. Lucky boy.)
[01:38] <golbez> g'night Europe
[01:39] <ortalo> g'night America


NickFirst occurence atNumber of messages