[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 ?