I'd like to bring this back toward reality a bit, though I'm happy to
see the interest, and do not wish to discourage that discussion.
The rest of RandR have been done, for kdrive, and immediate integration
into the mainline XFree86 server is managable.
So we have 3 options:
1) Integrate what we have, as is.
Features:
Least work for us. If we happened to get the design right
for depth switching, the protocol framework is there.
Bugs:
The depth switching part of the protocol is untested, which
means it may have lurking problems we would not discover.
2) Strip out depth switching, and integrate into the XFree86 mainline server.
Depth switching can be added later, as additional interfaces.
Features:
We can rely on this part of functionality to not change,
and remains stable.
Bugs:
We hope, none :-). Some more work to strip out the
depth switching part of the protocol and library; this
is a day or so's work.
3) attempt to do the depth switching immediately.
Features: we get the entire cake, someday, maybe.
Bugs: 4.3 is almost upon us, and there is no way to get depth
switching done in time that we can see, even if there were
magically more resources expended to work on it immediately.
I think the realistic result will be nothing happens.
I don't think 3) is really an option: we don't have time even if we had
resources.
I'm very nervous integrating and deploying functionality that hasn't
been fully tested; but as someone who has a laptop, I really want
size changing, and I suspect many other people do as well. The history,
both in X and other protocols, is that there are almost always problems
not discovered until implemented for real. The compromise
is that there are configurations that will fit into VRAM than we cannot
provide without depth switching.
So, given today's date, and that 2) does not preclude future implementation
of depth switching, I think we should pull out depth switching in
the RandR protocol and get what we have finished, integrated,
and fully deployed.
- Jim
--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
[EMAIL PROTECTED]
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
