aboutsummaryrefslogtreecommitdiff
path: root/libxcb/doc/xkb_issues
diff options
context:
space:
mode:
authormarha <marha@users.sourceforge.net>2012-06-08 09:33:13 +0200
committermarha <marha@users.sourceforge.net>2012-06-08 09:33:13 +0200
commit990bc3f015a4f8fce2eb918375defcd44980a845 (patch)
tree8e8301f19482b52cc00bd95b4593522cc93267af /libxcb/doc/xkb_issues
parent1af6fc1b5d93e54d6674de8b5870448b29f139a7 (diff)
downloadvcxsrv-990bc3f015a4f8fce2eb918375defcd44980a845.tar.gz
vcxsrv-990bc3f015a4f8fce2eb918375defcd44980a845.tar.bz2
vcxsrv-990bc3f015a4f8fce2eb918375defcd44980a845.zip
Used synchronise script to update files
Diffstat (limited to 'libxcb/doc/xkb_issues')
-rw-r--r--libxcb/doc/xkb_issues74
1 files changed, 37 insertions, 37 deletions
diff --git a/libxcb/doc/xkb_issues b/libxcb/doc/xkb_issues
index f10c015e5..80efcc1fc 100644
--- a/libxcb/doc/xkb_issues
+++ b/libxcb/doc/xkb_issues
@@ -1,38 +1,38 @@
-
-There are a number of problematic special cases in XKB. The issues
-mentioned here are at most partly resolved.
-
-1. The are several XxxDoodad structures defined in xkb.xml. They are used
- in a few lists, but in a rather special way:
- The struct "CommonDoodad" is supposed to be a rather generic data type,
- combining the most basic Doodad fields that are common in all these structures.
- All Doodads are encapsulated in a union type simply called "Doodad".
- Now this union is used in subsequent list definitions, aiming at a kind of
- 'polymorphism': From inspection of the protocol and Xlib, the Doodads are to
- be discriminated based on their type field.
- However the special meaning of the type field is not encoded in the protocol.
- Furthermore the TextDoodad and the LogoDoodad are variable size types due to
- some fields of type CountedString16, thereby turning the union into a
- possibly variable size type as well.
- However, for lists with variable size elements, special sizeof functions are
- required. These cannot be autogenerated as it cannot be referred which
- Doodad type to use for the union.
- Therefore, the Doodad type structures are unsupported at the moment.
-
-2. There are still some bugs in xkb.xml: Either certain fields are missing
- that are required by the protocol, or Xlib simply has another understanding
- of the protocol.
-
-3. The interface for accessors should be reviewed.
-
-4. Currently some bitcases carry 'name' attributes. These could be avoided if
- the data within would consist of a singe struct field only.
-
-5. switch could get a 'fixed_size' attribute, so when rewriting valueparam to switch,
- an uint32_t * pointer could be used instead of void *.
-
-6. The automatic inclusion of padding requires some complicated coding in the
- generator. This is errorprone and could be avoided if all padding is explicitly
- given in the protocol definition. For variable size fields that require padding,
- the pad tag could get a 'fieldref' attribute. That way padding could be handled
+
+There are a number of problematic special cases in XKB. The issues
+mentioned here are at most partly resolved.
+
+1. The are several XxxDoodad structures defined in xkb.xml. They are used
+ in a few lists, but in a rather special way:
+ The struct "CommonDoodad" is supposed to be a rather generic data type,
+ combining the most basic Doodad fields that are common in all these structures.
+ All Doodads are encapsulated in a union type simply called "Doodad".
+ Now this union is used in subsequent list definitions, aiming at a kind of
+ 'polymorphism': From inspection of the protocol and Xlib, the Doodads are to
+ be discriminated based on their type field.
+ However the special meaning of the type field is not encoded in the protocol.
+ Furthermore the TextDoodad and the LogoDoodad are variable size types due to
+ some fields of type CountedString16, thereby turning the union into a
+ possibly variable size type as well.
+ However, for lists with variable size elements, special sizeof functions are
+ required. These cannot be autogenerated as it cannot be referred which
+ Doodad type to use for the union.
+ Therefore, the Doodad type structures are unsupported at the moment.
+
+2. There are still some bugs in xkb.xml: Either certain fields are missing
+ that are required by the protocol, or Xlib simply has another understanding
+ of the protocol.
+
+3. The interface for accessors should be reviewed.
+
+4. Currently some bitcases carry 'name' attributes. These could be avoided if
+ the data within would consist of a singe struct field only.
+
+5. switch could get a 'fixed_size' attribute, so when rewriting valueparam to switch,
+ an uint32_t * pointer could be used instead of void *.
+
+6. The automatic inclusion of padding requires some complicated coding in the
+ generator. This is errorprone and could be avoided if all padding is explicitly
+ given in the protocol definition. For variable size fields that require padding,
+ the pad tag could get a 'fieldref' attribute. That way padding could be handled
a lot easier in the autogenerator. \ No newline at end of file