PEX 5.0 Interoperability Addendum Version 1.0 Greg Stiehl April 24, 1992 1) Each X Consortium vendor wishing to define their own OC types, enum types, enum values, table types, or GDP/GSE ids will be given a unique vendor id (a number) by the MIT registry. 2) Vendor id numbers will range from 1 to 126. The numbers 0 and 127 are reserved and will not be distributed. 3) If all vendor id numbers are distributed, a new vendor wishing a number will have to negotiate with an existing registered vendor and share that number space; otherwise, the new vendor will have to wait until PEX 6.0 when the vendor id space will be expanded. 4) A vendor specific OC type, table type, enum type, or enum value will have the high bit set (bit 15) and the vendor id encoded in the high bits (bits 14 through 8) of the type or value: Bit 15 a one Bits 14..8 a unique vendor number Bits 7..0 the type or value 5) A vendor specific GSE/GDP ids will have the high bit set (bit 31) and the vendor id encoded in the high bits (bits 30 through 16) of the GSE/GDP id: Bit 31 a one Bits 30..16 a unique vendor number Bits 15..0 the id 6) All vender specific OC types, table types, enum types, enum values, and GSE/GDP ids can be queried by GetEnumeratedType. Since the GetEnumerateType interface is only 16 bits, GSE/GDP ids will be packed into 16 bits. Therefore all types, values and ids are encoded: Bit 15 a one Bits 14..8 a unique vendor number Bits 7..0 a type, value, or id 7) Since less information can be stored when returning GDP/GSE ids through GetEnumeratedType, it is possible to have ids that are the same. In this case, the mnemonics will have to be use to distinguish between the two. Because of this problem, it is recommend that venders tightly pack their ids so as not to exceed 8 bits of significance. 8) Defining a separate X extension is the only way to add requests, events, or errors to PEX. XQueryExtension can be used to determine the base offsets for any new requests, errors, or events. 9) Rather than adding a new PEX request to determine which extensions to PEX are supported, the standard XListExtensions request should be used. 10) Large requests (those greater than the maximum request size) will be passed to the server using a general X extension mechanism TBD. Individual OC's will still be limited to 64K words. 11) OCNil is encoded as 0xFFFF (This is the current PEX-SI OC value, and would conform to the encoding specified, if PEX-SI had vendor id 127: 0xFFFF = [1,vendor 127,value 255]). 12) If facet normals are not given, the server should compute them as described in the PHIGS-PLUS (DP) Document (ISO/IEC 9592-4, February 14, 1991 draft, page 39, clause 4.5.5.3, Reflection Normals). The server should not modify any normals that the client explicitly defines. 13) The direction vector associated with the WCS_Vector and WCS_Spot light types points in the direction the light would travel from these sources. 14) Specular exponents are used as specified in Annex C of the PHIGS-PLUS (DP) Document (ISO/IEC 9592-4, February 14, 1991 draft). 15) Not all server support all drawables. The only drawable type that can be assumed is Window. In a future release of PEX, a routine will be provided for checking for support of each drawable type. 16) To double buffer while using the Workstation subset, the Workstation should be created using the Double Buffer Workstation type. ==8<==8<==8<==8<==8<==8<==8<==8<== CUT HERE ==>8==>8==>8==>8==>8==>8==>8==>8= New items to be considered: 17) 5.1 servers will return their list of supported rendering targets in the order of descreasing "goodness" for PEX rendering, i.e. the first target in the list should be the best target for PEX. 18) 5.0 and 5.1 servers will return their native floating point format as the first entry in the list of supported floating point formats returned by PEXGetEnumeratedTypeInfo. 19) Implementations which do not support the pattern interior style will not guarantee support for the pattern lookup table (a LookupTable error will be returned from PEXCreateLookupTable). 20) Implementations will return a Value error from PEXCreateLookupTable for attempted creation of vendor specific lookup tables which are not supported. 21) 5.0 servers will return a Match error from PEXBeginRendering with a drawable of a type not supported for PEX rendering. 22) There is an issue about color approximation constraints - are they allowed, and if so, how does the client determine what is supported? HP proposed the following: Predefined Color Approximation Table Entries Implementations that support only a limited set of color approximation configurations, which may vary by target, should support a predefined entry in the color approximation table for each of the supported configurations. All the PEXColorSpace entries should appear first in the set of predefined entries (i.e., at lower indices in the range of predefined indices), ordered from best overall behavior (image quality and performance, in the implementation vendor's judgment) to worst. If the implementation also has limited support for PEXColorRange, those predefined entries should follow the PEXColorSpace entries, again ordered from best to worst. Implementations that support arbitrary color approximation should define no predefined color approximation entries. This convention allows clients to use PEXGetPredefinedEntries (which requires an example drawable) to inquire the color approximation support in a target-specific manner. If an implementation in fact has limited color approximation support, but does not support this convention, the client will assume it has unlimited support, just as it would if the convention did not exist. -- Jas