I hope I can be there on Saturday. Btw, at which hour is the meeting in France? It's 1pm eastern time, so 19:00 GMT? isn'it? Isn't it 7 or 8pm in France? Hmmm I'm not sure I can be there at that time (a 2-years-old boy that wants dinner is a pretty high-level interrupt - even with power-switch side-effects sometimes!). I'd rather 2 hours later or 3 hours earlier if possible? Well, do not bother too much only for me however.
On Tue, 20 Aug 2002, Brian S. Julin wrote: > My 2 cents on a good topic for our upcoming IRC meeting: I think we > need to concentrate on creating a firmer definition of what a KGI driver > is and is not expected to do. Yep. It would be useful! > Not to get too in-depth before the meeting, but to summarise: > > IMO there are several areas where we have not limited the scope > enough. We need to be more minimalist. I agree too. The objective should be clearer, and feasible. > For example, since all > KGI kernel-side drivers must be accompanied by a userspace driver > which is specific to the chipset/hardware, Unless I missed something in the last few months (pretty possible), for me this is only true for hw-accelerated functions (either 2D or 3D). For the rest, it seems to me that the userspace driver should be generic. At least, this is true for mode-setting like you say. IMHO it should also be true for basic things like hw-cursor management, palette setting. Also for "standard information" (a "get_info" ioctl will also surely include a hw-specific extension part, but the standard piece should be generic). And also if possible for some "sync()" signaling. It could also be (sort-of) generic for VGA-text issues if we agree to standardize on the VGA-text subsystem (or a compatible one) to provide VGA text functionality (including font setting and hw cursor, the most useful things). The "accelerator engine communication channel" is also a generic thing common to all drivers in some sense. But its standardization may be (?) less critical as it can only be useful for (hw-specific) software that knows how to use it effectively (and fill it with binary ops that the specific hw engine understands). The key issue in the standardization on a generic channel from userspace down to the accelerator is more related to the fact that it will be a (important) design decision. > [...] This saves a lot of time and > effort trying to find standard ways of expressing things like > RAM configurations, and gives the driver author more freedom. I understand (and agree with) this. But there are simple things, like the hw cursor, the 8bpp palette, the gamma correction table, the basic characteristics of the board (available fb RAM size, flags indicating the availability of hw-cursor, gamma table, etc.), that can be standardized without too much thinking. And IMO this should be done because it would be beneficial in short term (driver writers would also get more applications for testing...). As an example, I think one should forget about the 16-color hw cursor of Matrox >=G200 and standardize a 3 color (or even 2-color) cursor. We'll see later on if the Matrox driver maintainer has the motivation to do a Matrox-specific dedicated lib for that unique feature ;-). Basically, the important thing is to have a decent-looking arrow and show(),hide(), set_position(x,y) functions! You can do a similar reasoning for the palette or gamma correction tables, even if the Parhelia (Matrox again!) comes with 10bits for R,G and B. (Fortunately, they did not release the specs for that beast! Well, :-(. Anyway back on topic.). > The > only exception to this IMO should be facilities which are easy to provide > because they had to be implemented in order to provide the OS with > a console/fb system, mainly mode-setting. Other than that, there > should be a strict "validate only" policy. Oh. It seems we agree in fact. What about a "two-level approach" to basic features: * Mandatory: - mode-setting (graphics) - mode setting (text, possibly augmented with some VGA-text facilities) - some standard informational data struct, including a list or bitfield indicating the absence/presence of some standard optional features, and a variable size area at the end for the hw-specific mess. * Optional: (the presence/absence of one feature is indicated by the list/bitfield in the information above) - hw-cursor: 3 colors, standard size and bit layout (whichever you want), show(), hide(), move(x,y), initially hidden. - palette: natural definition according to the mode (ie: 3 arrays of 256 bytes for usual 8bpp, etc.) - gamma correction: 3 arrays of 256 8-bits bytes - sync on frame - current kgi-0.9 pingpong buffers [really optional] - other kgi-1.0 generic accel channel [if already available] > Then there are the areas which we have so far not addressed enough: > 1) Absolute system stability precautions Yep. For that we need more testing and more complex testing (we need libggi! :-); and to do a pause on the accel issue that usually is the bad guy here. (We would also need more complete hw specifications, but that's another problem.) > 2) Absolute inter-process security Hmmm. You mean that we need to double check that the permissions on the /dev/graphics devices and co. are really enforced by the code? Mode-setting management in the kernel per-se is the primary security enhancement of KGI (even if it reduces to allowing a correct implementation of SAK). IMHO, the more subtle security issues are related with the availability of a channel from userspace to the acceleration engine (and that can be left for later). > 3) Graphics driver system pause/resume due to VC-switch and/or system > powersave or suspend-to-disk, Isn't this limited to text mode? In "VC-switch", there is the C for console which means text (even if on a graphical fb)... Okay, that's just a pun, but isn't my point valid anyway? It seems to me that, on one graphical head, a switch should be handled the simple way (SIGSTOP? Can be trapped no?). > and 4) handling funny corner cases safely > even if it means killing or blocking the app (e.g. monitor swap during > running application). Well, maybe hot GPU plugging could be left for later, no? :-)) However, I agree that we should focuss on having full control (understanding, at least) of all the possible states KGI can lead to. Rodolphe
