Messages in this thread |  | | Date | Thu, 6 Jun 1996 01:01:36 -0700 (PDT) | From | "Jon M. Taylor" <> | Subject | Re: SVGA kernel chipset drivers. |
| |
On Thu, 6 Jun 1996, Theodore Y. Ts'o wrote:
> Date: Wed, 5 Jun 1996 21:38:35 -0700 (PDT) > From: "Jon M. Taylor" <taylorj@gaia.ecs.csus.edu> > > First, it is GGI, not CGI. Second, why must this be set in > stone? If things can change as much as they have in the /proc > filesystem, a precedent is there for this sort of thing. Besides, there > are undoubtedly ways of either ensuring complete backwards compatibility > (i.e., IOCTLs only get added, never removed or modified) or implementing > some srt of versioning scheme to ensure that older apps always use the > IOCTL set they were compiled to use. I'm sure that there are other > solutions as well. > > True, you can always add new ioctl's. However, this exposes the fallacy > that says that GGI will avoid the requirement of new X servers to > support new fancy accelerated boards. If each new accelerated board > that has some new accleration feature will require new ioctl()'s, then > we will need to compile a new X server to take advantage of the > (constantly changing) GGI API. Otherwise, the old GGI X server, since > it didn't have the old API calls, won't be able to take advantage of the > new accelerated functions.
This is true, but there's really no way around it. One way to mitigate the problem would be to have a layer of library code in between the X server and the GGI, which would handle all the translation of X graphics primitive calls into GGI ioctls (OK, I'll use lowercase |->). This would still need to be updated in the event of an expansion of the GGI primitive set, but the bulk of the X server code could remain unchanged. Xlib would probably be this layer, actually.
There are probably going to be very few apps that talk to the GGI directly - I'd imagine that some sort of library layer will almost always be used, for the reason that you'd have to put the same sort of functionality into the program anyway if you wanted to do anything other than bang away at the raw framebuffer or use whatever ioctls happened to be present.
Also, it isn't like there's gonna be a new ioctl every other week or something, especially if we implement a fairly complete set to start with. Work has already begin on a 'standard' userspace library, and hopefully it will end up being comprehensive enough that significant performance losses due to unsupported accelerations won't be a problem. Especially if I have anything to do with it - I want to write GGI drivers for all those new gamecards that are coming out. > > Finally, please remember that in the grand scheme of things GCI will > > double the amount of work required; when a vendor releases a new card, > > someone will have to write a GCI Linux kernel module, and XFree86 will > > have to put support into their servers directly. After all, remeber > > that XFree86 runs on a large number of OS's, not just Linux, and so > > regardless of what we do, XFree86 will still have to do all of this > > work. > > Since both codebases are free, why duplicate the work? Either > they develop it first and we use their code, or the reverse. > > You're right that it won't be exactly double, however, there will be > some amount of new work required, if nothing else to confirm to the > differing interfaces between the internals of the XFree6 server and the > GGI API.
There's no way this can be reduced to zero, but I think that it can be made trivial enough so as not to be a problem. > I don't doubt that there are advantages in putting parts of the video > board management inside the kernel. However, there are costs in doing > so, and people should neither try to trivialize the cost nor > overemphasize the benefit.
I'm not saying that the GGI will be the holy grail of graphics programming or anything like that, but I honestly think that I will be a great improvement.
Jon Taylor = <taylorj@gaia.ecs.csus.edu> | <http://gaia.ecs.csus.edu/~taylorj> ------------------------------------------------------------------------------ "Everything in excess! To enjoy the flavor of life, take big bites. Moderation is for monks." - Lazarus Long
|  |