[Xorg] Xinerama backward compatibility issues

[Egbert Eich]

Kaleb S. KEITHLEY writes:
 > 
 > > 3. XineramaSetCenterHint(), XineramaGetCenterHint(): new functions
 > >    declared in the header but I couldn't find an implementation.
 > 
 > These are not in the SourceForge spec. They should be removed from the 
 > header.

OK. 

 > 
 > > 4. No backward compatibility on the wire protocol level. It least 
 > >    I didn't find any.

...

 > > Unfortunately this will not help us as libXinerama has always been 
 > > as static library so far.
 > 
 > It helps in that, in the worst case scenario, all that's required is to 
 > merely relink, rather than modify source and recompile.

Yes.

 > 
 > > More dramatically backward compatibility on the wire protocol level
 > > exists neither on the client nor on the server side. This means an 
 > > older client won't work on the Xorg server and a client built with 
 > > the new version of libXinerama will fail on older servers.
 > > This may create a compatibility problem.
 > 
 > That's correct, no attempt has been made -- so far -- to preserve BC at 
 > the wire protocol level. (Nobody has made the case that it needs to be, 
 > either. Not yet anyway.)
 > 
 > And, FWIW, in XFree86 4.4RCx, libXinerama is now a shared library.
 > 

I've revied the changes to the wire protocol.
Here are my findings:

1. The old panoramiX requests were removed.
   That eliminated 3 requests moving request 4 and 5 
   to request 1 and 2 resp.
2. a. Request 4 V1.1 corresponds to request 1 V2 a window ID has been added to
      the request, location and size of the other data stayed the same.
   b. The reply differs in that the state used to be CARD8 and is now CARD32.
3. a. Request 5 V1.1 corresponds to request 2 V2 a window ID has been added to
      the request.
   b. Reply didn't change.


Wouldn't it have been wise to leave in the old panoramiX requests this 
way keeping the request IDs?
2.b Seems to be unnecessary to me.
2.a and 3.a: I don't see the purpose of this change. The server code
just does a  LookupWindow () and fails if the returned WindowPtr is NULL.
The returend window pointer is never actually used anywhere.
I don't see that this may be a security feature here as we don't even
call a SecurityLookupWindow() - which wouldn't make sense since we
don't plan to do anything with this window.

I may not getting something here. Can somebody please explain.

Egbert.