> The ggi list is telling me Im not subscribed - could you check that I > am? I can't but the list-admin irish ([EMAIL PROTECTED]) probably can. You might as well want to request "HELP" from [EMAIL PROTECTED] which should give you a command overview for the list-manager. Usually there is some command to see the subscribers, which helps to figure out the problem. > I hve several accounts, both [EMAIL PROTECTED] and [EMAIL PROTECTED] > should be subscribed. Are you getting mail _from_ the list there ? Like this one ? > Other than that, could you forward this to the list? Will do. This message is CC to the list (for you to check the connection) and to Irish. I also already commented on your mail below. > Im just trying to get a feel for graphics driver programming etc. is > this the > structure that is used in the current fbdev/kgicon/whatever system? > > > Some User Program or whatever > | | > | | > | Complex Rendering libraries > | | > \/ \/ > Kernel mode driver that can do simple > Raster ops and blitting, plus provide > user mode access to other card features > needed by the complex rendering layer. Yes - that's basically what it looks like. The left arrow isn't quite the recommended way, as this will eventually (depending on the features you use) result in card-specific code. > This seems to be the most sensible way of implementing graphics drivers, > as > it allows one to make the kernel side code /really/ small, and also > allows > for software emulation of unsupported card features. > > The kernel driver and the rendering library must be replaced for each > different card, of course. to allow multihead, perhaps the library could > have common frontends with plugin backends for each supported card? That's how LibGGI works. It even works with traditional fbcon drivers. If LibGGI detects the Matrox fbcon driver below, it will load an acceleration module for it. > The thought occurs that a similar piece of code could work for sound > also. Well - partially. Sound often has to do with very dangerous operations like DMA ... You'd have most of it in the kernel anyway, then. Only very few operations might be suitable for direct card access. > Is this the way it works? Yes. > if not, why? if it would be a good thing, who is interested? All here I suppose ... that's basically what we are doing ;-) CU, ANdy -- Andreas Beck | Email : <[EMAIL PROTECTED]>
