[Xcb] XML description of XKB optional fields

[Ian Osgood]

One or more of the requests also have valuelists that are sized based  
on the bitcount of some combination of masks rather than just one  
mask field. Is that currently expressable?

Ian

On Nov 29, 2006, at 4:48 PM, Jamey Sharp wrote:

> We've had a to-do item for a while to implement the XKB extension (bug
> #6684). Vincent Torri tried to do this in April 2005, but XKB does  
> some
> strange things and he moved on to more productive tasks. :-) I  
> think we
> can express almost all of XKB in our current XML tagset, and I'm  
> hoping
> somebody will volunteer to give it a try.
>
> XKB presents two major challenges: Some fields are optional,  
> conditional
> on the values of other fields; and some lists have a length that  
> depends
> in complicated ways on a bitfield, and elements of varying types. I
> think these are both essentially the same problem, and we can express
> all these cases as lists of either 0 or 1 element.
>
> One of the two optional fields is described this way:
>
> 1	m			nMapEntries
> 1	BOOL			hasPreserve
> ...
> [4m]	LISTofKB_MODDEF 	preserve
>
> Because BOOL values are required to be either 0 or 1, we can represent
> that this way in our XML:
>
> <field type="CARD8" name="map_entries_len" />
> <field type="BOOL" name="has_preserve" />
> <list type="KB_MODDEF">
> 	<op op="*">
> 		<fieldref>map_entries_len</fieldref>
> 		<fieldref>has_preserve</fieldref>
> 	</op>
> </list>
>
> That wasn't too bad. Now for the really ugly.
>
> 2	SETofKB_GBNDETAILMASK		reported
> V	LISTofITEMs			replies
> 	(if this in reported:)		(then this field is present:)
> 	XkbGBN_Types			map
> 	XkbGBN_CompatMap		compat
> 	XkbGBN_ClientSymbols		map
> 	XkbGBN_ServerSymbols		map
> 	XkbGBN_IndicatorMap		indicators
> 	XkbGBN_KeyNames 		names
> 	XkbGBN_OtherNames		names
> 	XkbGBN_Geometry 		geometry
> ITEMs
> M	XkbGetMap reply 		map
> C	XkbGetCompatMap reply		compat
> I	XkbGetIndicatorMap reply	indicators
> N	XkbGetNames reply		names
> G	XkbGetGeometry reply		geometry
>
> Given some extensions of the XML, we can encode that this way:
>
> <field type="CARD16" name="reported" />
> <list type="reply:GetMap" name="map">
> 	<op op="&amp;">
> 		<value>1</value>
> 		<op op="|">
> 			<fieldref>reported</fieldref>
> 			<op op="&gt;&gt;">
> 				<fieldref>reported</fieldref>
> 				<value>2</value>
> 			</op>
> 			<op op="&gt;&gt;">
> 				<fieldref>reported</fieldref>
> 				<value>3</value>
> 			</op>
> 		</op>
> 	</op>
> </list>
> <list type="reply:GetCompatMap" name="compat">
> 	<op op="&amp;">
> 		<value>1</value>
> 		<op op="&gt;&gt;">
> 			<fieldref>reported</fieldref>
> 			<value>1</value>
> 		</op>
> 	</op>
> </list>
> ...
>
> ...Phew, I'm tired of typing already. But perhaps you get the idea.
>
> Now, it isn't too big of a deal to make the XSLT support right- 
> shift and
> bitwise-or operators, in addition to the current left-shift and
> bitwise-and. Adding the ability to refer to a reply as a field type  
> also
> isn't that hard, since fortunately we're already generating iterators
> for them. I can see that a couple more extensions will be needed along
> the way, but I have ideas for those too. Typing all this in is
> time-consuming, but manageable.
>
> Will somebody either go give it a try, or put forward a better  
> proposal?
>
> --Jamey
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb