Martin Bochnig wrote:
> #1.) *Solely* for the sake of backwards compatibility: An open-up Sun's
> proprietary libXext, so that we can add proprietary functionality to Xorg's
> default version of libXext (de facto standard since 6.8), via automatically
> patching the diffs in before each src tree generation.
I'd planned on the same thing we plan for replacing all the code in
our closed fork of X:
1) Diff old Sun code against current X.Org code
2) For each diff, determine:
a) Is it of general use? If so, commit to X.Org
b) Is it no longer useful or the X.Org code better? If so, dump
c) Is it still useful, but Solaris specific (such as stuff
like the old Xinerama code we just need for backwards
compatibility)? If so, add as a patch to the X.Org code
in our build tree.
This both gets us back to the X.Org open source and reduces the amount
of code we have to check for rights to open source to just the diffs
we're either keeping as patches or giving back to X.Org.
Unfortunately, that also limits it to people at Sun, since we're doing
the diff before the determination of releaseability.
> p.s. Did you already hear some info from g11n regarding where SUNWxorg-xkb
> has gone?
I heard from the G11n team we had passed it off to that they
just started transitioning it to another G11n team, and am
waiting to hear back from the new team, but given there's a lot of
moving around of G11n projects right now, it may take some time.
I do still have a copy of the code we handed off to them, and
could post that, but it'll be missing the last year's worth of
fixes from them, including many European layout fixes and the
infamous Ctrl-Backspace-with-NumLock-on-kills-Xorg bug fix.
Would that be useful as a temporary placeholder?
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
