/usr/share/doc/x11proto-record-dev/record.html is in x11proto-record-dev 1.14.2-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 | <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Record Extension Protocol Specification</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /><style xmlns="" type="text/css">/*
* Copyright (c) 2011 Gaetan Nadon
* Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*/
/*
* Shared stylesheet for X.Org documentation translated to HTML format
* http://www.sagehill.net/docbookxsl/UsingCSS.html
* http://www.w3schools.com/css/default.asp
* https://addons.mozilla.org/en-US/firefox/addon/web-developer/developers
* https://addons.mozilla.org/en-US/firefox/addon/font-finder/
*/
/*
* The sans-serif fonts are considered more legible on a computer screen
* http://dry.sailingissues.com/linux-equivalents-verdana-arial.html
*
*/
body {
font-family: "Bitstream Vera Sans", "DejaVu Sans", Tahoma, Geneva, Arial, Sans-serif;
/* In support of using "em" font size unit, the w3c recommended method */
font-size: 100%;
}
/*
* Selection: all elements requiring mono spaced fonts.
*
* The family names attempt to match the proportionally spaced font
* family names such that the same font name is used for both.
* We'd like to use Bitstream, for example, in both proportionally and
* mono spaced font text.
*/
.command,
.errorcode,
.errorname,
.errortype,
.filename,
.funcsynopsis,
.function,
.parameter,
.programlisting,
.property,
.screen,
.structname,
.symbol,
.synopsis,
.type
{
font-family: "Bitstream Vera Sans Mono", "DejaVu Sans Mono", Courier, "Liberation Mono", Monospace;
}
/*
* Books have a title page, a preface, some chapters and appendices,
* a glossary, an index and a bibliography, in that order.
*
* An Article has no preface and no chapters. It has sections, appendices,
* a glossary, an index and a bibliography.
*/
/*
* Selection: book main title and subtitle
*/
div.book>div.titlepage h1.title,
div.book>div.titlepage h2.subtitle {
text-align: center;
}
/*
* Selection: article main title and subtitle
*/
div.article>div.titlepage h2.title,
div.article>div.titlepage h3.subtitle,
div.article>div.sect1>div.titlepage h2.title,
div.article>div.section>div.titlepage h2.title {
text-align: center;
}
/*
* Selection: various types of authors and collaborators, individuals or corporate
*
* These authors are not always contained inside an authorgroup.
* They can be contained inside a lot of different parent types where they might
* not be centered.
* Reducing the margin at the bottom makes a visual separation between authors
* We specify here the ones on the title page, others may be added based on merit.
*/
div.titlepage .authorgroup,
div.titlepage .author,
div.titlepage .collab,
div.titlepage .corpauthor,
div.titlepage .corpcredit,
div.titlepage .editor,
div.titlepage .othercredit {
text-align: center;
margin-bottom: 0.25em;
}
/*
* Selection: the affiliation of various types of authors and collaborators,
* individuals or corporate.
*/
div.titlepage .affiliation {
text-align: center;
}
/*
* Selection: product release information (X Version 11, Release 7)
*
* The releaseinfo element can be contained inside a lot of different parent
* types where it might not be centered.
* We specify here the one on the title page, others may be added based on merit.
*/
div.titlepage p.releaseinfo {
font-weight: bold;
text-align: center;
}
/*
* Selection: publishing date
*/
div.titlepage .pubdate {
text-align: center;
}
/*
* The legal notices are displayed in smaller sized fonts
* Justification is only supported in IE and therefore not requested.
*
*/
.legalnotice {
font-size: small;
font-style: italic;
}
/*
* Selection: book or article main ToC title
* A paragraph is generated for the title rather than a level 2 heading.
* We do not want to select chapters sub table of contents, only the main one
*/
div.book>div.toc>p,
div.article>div.toc>p {
font-size: 1.5em;
text-align: center;
}
/*
* Selection: major sections of a book or an article
*
* Unlike books, articles do not have a titlepage element for appendix.
* Using the selector "div.titlepage h2.title" would be too general.
*/
div.book>div.preface>div.titlepage h2.title,
div.book>div.chapter>div.titlepage h2.title,
div.article>div.sect1>div.titlepage h2.title,
div.article>div.section>div.titlepage h2.title,
div.book>div.appendix>div.titlepage h2.title,
div.article>div.appendix h2.title,
div.glossary>div.titlepage h2.title,
div.index>div.titlepage h2.title,
div.bibliography>div.titlepage h2.title {
/* Add a border top over the major parts, just like printed books */
/* The Gray color is already used for the ruler over the main ToC. */
border-top-style: solid;
border-top-width: 2px;
border-top-color: Gray;
/* Put some space between the border and the title */
padding-top: 0.2em;
text-align: center;
}
/*
* A Screen is a verbatim environment for displaying text that the user might
* see on a computer terminal. It is often used to display the results of a command.
*
* http://www.css3.info/preview/rounded-border/
*/
.screen {
background: #e0ffff;
border-width: 1px;
border-style: solid;
border-color: #B0C4DE;
border-radius: 1.0em;
/* Browser's vendor properties prior to CSS 3 */
-moz-border-radius: 1.0em;
-webkit-border-radius: 1.0em;
-khtml-border-radius: 1.0em;
margin-left: 1.0em;
margin-right: 1.0em;
padding: 0.5em;
}
/*
* Emphasis program listings with a light shade of gray similar to what
* DocBook XSL guide does: http://www.sagehill.net/docbookxsl/ProgramListings.html
* Found many C API docs on the web using like shades of gray.
*/
.programlisting {
background: #F4F4F4;
border-width: 1px;
border-style: solid;
border-color: Gray;
padding: 0.5em;
}
/*
* Emphasis functions synopsis using a darker shade of gray.
* Add a border such that it stands out more.
* Set the padding so the text does not touch the border.
*/
.funcsynopsis, .synopsis {
background: #e6e6fa;
border-width: 1px;
border-style: solid;
border-color: Gray;
clear: both;
margin: 0.5em;
padding: 0.25em;
}
/*
* Selection: paragraphs inside synopsis
*
* Removes the default browser margin, let the container set the padding.
* Paragraphs are not always used in synopsis
*/
.funcsynopsis p,
.synopsis p {
margin: 0;
padding: 0;
}
/*
* Selection: variable lists, informal tables and tables
*
* Note the parameter name "variablelist.as.table" in xorg-xhtml.xsl
* A table with rows and columns is constructed inside div.variablelist
*
* Set the left margin so it is indented to the right
* Display informal tables with single line borders
*/
table {
margin-left: 0.5em;
border-collapse: collapse;
}
/*
* Selection: paragraphs inside tables
*
* Removes the default browser margin, let the container set the padding.
* Paragraphs are not always used in tables
*/
td p {
margin: 0;
padding: 0;
}
/*
* Add some space between the left and right column.
* The vertical alignment helps the reader associate a term
* with a multi-line definition.
*/
td, th {
padding-left: 1.0em;
padding-right: 1.0em;
vertical-align: top;
}
.warning {
border: 1px solid red;
background: #FFFF66;
padding-left: 0.5em;
}
</style></head><body><div class="book" title="Record Extension Protocol Specification"><div class="titlepage"><div><div><h1 class="title"><a id="record"></a>Record Extension Protocol Specification</h1></div><div><h2 class="subtitle">X Consortium Standard</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Martha</span> <span class="surname">Zimet</span></h3><div class="affiliation"><span class="orgname">Network Computing Devices, Inc.<br /></span></div></div><div class="editor"><h4 class="editedby">Edited by</h4><h3 class="editor"><span class="firstname">Stephen</span> <span class="surname">Gildea</span></h3><div class="affiliation"><span class="orgname">X Consortium<br /></span></div></div></div></div><div><p class="releaseinfo">X Version 11, Release 7.6</p></div><div><p class="copyright">Copyright © 1994 Network Computing Devices, Inc.</p></div><div><div class="legalnotice" title="Legal Notice"><a id="idp17041304"></a><p>
Permission to use, copy, modify, distribute, and sell this
documentation for any purpose is hereby granted without fee,
provided that the above copyright notice and this permission
notice appear in all copies. Network Computing Devices, Inc.
makes no representations about the suitability for any purpose
of the information in this document. This documentation is
provided “as is” without express or implied warranty.
</p></div></div><div><div class="legalnotice" title="Legal Notice"><a id="idp16887568"></a><p class="multiLicensing">Copyright © 1994, 1995 X Consortium</p><p>
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
</p><p>
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
</p><p>
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
</p><p>
Except as contained in this notice, the name of the X Consortium and
shall not be used in advertising or otherwise to promote the sale, use
or other dealings in this Software without prior written authorization
from the X Consortium.
</p><p>X Window System is a trademark of The Open Group.</p></div></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="chapter"><a href="#Introduction">1. Introduction</a></span></dt><dd><dl><dt><span class="sect1"><a href="#Acknowledgements">Acknowledgements</a></span></dt><dt><span class="sect1"><a href="#Goals">Goals</a></span></dt><dt><span class="sect1"><a href="#Requirements">Requirements</a></span></dt></dl></dd><dt><span class="chapter"><a href="#Design">2. Design</a></span></dt><dd><dl><dt><span class="sect1"><a href="#Overview">Overview</a></span></dt><dd><dl><dt><span class="sect2"><a href="#Data_Delivery">Data Delivery</a></span></dt><dt><span class="sect2"><a href="#Record_Context">Record Context</a></span></dt><dt><span class="sect2"><a href="#Record_Client_Connections">Record Client Connections</a></span></dt><dt><span class="sect2"><a href="#Events">Events</a></span></dt><dt><span class="sect2"><a href="#Timing">Timing</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Types">Types</a></span></dt><dt><span class="sect1"><a href="#Errors">Errors</a></span></dt></dl></dd><dt><span class="chapter"><a href="#Protocol_Requests">3. Protocol Requests</a></span></dt><dt><span class="chapter"><a href="#Encoding">4. Encoding</a></span></dt><dd><dl><dt><span class="sect1"><a href="#Types_2">Types</a></span></dt><dt><span class="sect1"><a href="#Errors_2">Errors</a></span></dt><dt><span class="sect1"><a href="#Requests">Requests</a></span></dt></dl></dd></dl></div><div class="chapter" title="Chapter 1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a id="Introduction"></a>Chapter 1. Introduction</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="sect1"><a href="#Acknowledgements">Acknowledgements</a></span></dt><dt><span class="sect1"><a href="#Goals">Goals</a></span></dt><dt><span class="sect1"><a href="#Requirements">Requirements</a></span></dt></dl></div><p>
Several proposals have been written over the past few years that address some
of the issues surrounding the recording and playback of user actions
in the X Window System<sup>[<a id="idp17749024" href="#ftn.idp17749024" class="footnote">1</a>]</sup>
:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
<span class="emphasis"><em>Some Proposals for a Minimal X11 Testing Extension</em></span>,
Kieron Drake, UniSoft Ltd., April 1991
</p></li><li class="listitem"><p>
<span class="emphasis"><em>X11 Input Synthesis Extension Proposal</em></span>, Larry Woestman,
Hewlett Packard, November 1991
</p></li><li class="listitem"><p>
<span class="emphasis"><em>XTrap Architecture</em></span>, Dick Annicchiario, et al, Digital Equipment Corporation,
July 1991
</p></li><li class="listitem"><p>
<span class="emphasis"><em>XTest Extension Recording Specification</em></span>, Yochanan Slonim,
Mercury Interactive, December 1992
</p></li></ul></div><p>
This document both unifies and extends the previous diverse approaches
to generate a proposal for an X extension that provides support for
the recording of all core X protocol and arbitrary extension protocol.
Input synthesis, or playback, has already been implemented in the
XTest extension, an X Consortium standard. Therefore, this extension
is limited to recording.
</p><p>
In order to provide both record and playback functionality, a
hypothetical record application could use this extension to capture
both user actions and their consequences. For example, a button press
(a user action) may cause a window to be mapped and a corresponding
<code class="function">MapNotify</code>
event to be sent (a consequence). This information could be
stored for later use by a playback application.
</p><p>
The playback application could use the recorded actions as input for
the XTest extension's
<code class="function">XTestFakeInput</code>
operation to synthesize the
appropriate input events. The "consequence" or synchronization
information is then used as a synchronization point during playback.
That is, the playback application does not generate specific
synthesized events until their matching synchronization condition
occurs. When the condition occurs the processing of synthesized
events continues. Determination that the condition has occurred may be
made by capturing the consequences of the synthesized events and
comparing them to the previously recorded synchronization information.
For example, if a button press was followed by a
<code class="function">MapNotify</code>
event on a
particular window in the recorded data, the playback application might
synthesize the button press then wait for the
<code class="function">MapNotify</code>
event on the
appropriate window before proceeding with subsequent synthesized
input.
</p><p>
Because
it is impossible to predict what synchronization information will be
required by a particular application, the extension provides
facilities to record any subset of core X protocol and arbitrary
extension protocol.
As such, this extension does not enforce a specific
synchronization methodology; any method based on information in the X
protocol stream (e.g., watching for window mapping/unmapping, cursor
changes, drawing of certain text strings, etc.) can capture the
information it needs using RECORD facilities.
</p><div class="sect1" title="Acknowledgements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Acknowledgements"></a>Acknowledgements</h2></div></div></div><p>
The document represents the culmination of two years of debate and
experiments done under the auspices of the X Consortium xtest working
group. Although this was a group effort, the author remains
responsible for any errors or omissions.
Two years ago, Robert Chesler of Absol-puter, Kieron Drake of UniSoft
Ltd., Marc Evans of Synergytics and Ken Miller of Digitial shared the
vision of a standard extension for recording and were all instrumental
in the early protocol development. During the last two years, Bob
Scheifler of the X Consortium and Jim Fulton of NCD continuously
provided input to the protocol design, as well as encouragement to the
author. In the last few months, Stephen Gildea and Dave Wiggins,
both X Consortium staff, have spent considerable time fine tuning the
protocol design and reviewing the protocol specifications. Most
recently, Amnon Cohen of Mercury Interactive has assisted in
clarification of the recorded event policy, and Kent Siefkes of
Performance Awareness has assisted in clarification of the timestamp
policy.
</p></div><div class="sect1" title="Goals"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Goals"></a>Goals</h2></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
To provide a standard for recording,
whereby both device events and synchronization information in the
form of device event consequences are recorded.
</p></li><li class="listitem"><p>
To record contextual information used in synchronized playback
without prior knowledge of the application
that
is being recorded.
</p></li><li class="listitem"><p>
To provide the ability to record arbitrary X protocol extensions.
</p></li></ul></div></div><div class="sect1" title="Requirements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Requirements"></a>Requirements</h2></div></div></div><p>
The extension should function as follows:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
It should
not be dependent on other clients or extensions for its operation.
</p></li><li class="listitem"><p>
It should
not significantly impact performance.
</p></li><li class="listitem"><p>
It should
support the recording of all device input (core devices and XInput devices).
</p></li><li class="listitem"><p>
It should
be extendible.
</p></li><li class="listitem"><p>
It should
support the recording of synchronization information for user events.
</p></li></ul></div></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.idp17749024" href="#idp17749024" class="para">1</a>] </sup>
<span class="emphasis"><em>X Window System</em></span> is a trademark of The Open Group.
</p></div></div></div><div class="chapter" title="Chapter 2. Design"><div class="titlepage"><div><div><h2 class="title"><a id="Design"></a>Chapter 2. Design</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="sect1"><a href="#Overview">Overview</a></span></dt><dd><dl><dt><span class="sect2"><a href="#Data_Delivery">Data Delivery</a></span></dt><dt><span class="sect2"><a href="#Record_Context">Record Context</a></span></dt><dt><span class="sect2"><a href="#Record_Client_Connections">Record Client Connections</a></span></dt><dt><span class="sect2"><a href="#Events">Events</a></span></dt><dt><span class="sect2"><a href="#Timing">Timing</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Types">Types</a></span></dt><dt><span class="sect1"><a href="#Errors">Errors</a></span></dt></dl></div><p>
This section gives an overview of the RECORD extension and discusses
its overall operation and data types.
</p><div class="sect1" title="Overview"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Overview"></a>Overview</h2></div></div></div><p>
The mechanism used by this extension for recording is to intercept
core X protocol and arbitrary X extension protocol entirely within the X server
itself. When the extension has been requested to intercept specific
protocol by one or more clients, the protocol data are formatted and
returned to the recording clients.
</p><p>
The extension provides a mechanism for capturing all events, including
input device events that go to no clients, that is analogous to a client
expressing "interest" in all events in all windows, including the root
window. Event filtering in the extension provides a mechanism for feeding
device events to recording clients; it does not provide a mechanism for
in-place, synchronous event substitution, modification, or withholding.
In addition, the
extension does not provide data compression before intercepted protocol
is returned to the recording clients.
</p><div class="sect2" title="Data Delivery"><div class="titlepage"><div><div><h3 class="title"><a id="Data_Delivery"></a>Data Delivery</h3></div></div></div><p>
Because
events are limited in size to
32 bytes, using events to return intercepted protocol data to recording
clients is prohibitive in terms of performance. Therefore, intercepted
protocol data are returned to recording clients through multiple replies
to the extension request to begin protocol interception and reporting.
This utilization is consistent with
<code class="function">ListFontsWithInfo ,</code>
for example, where a
single request has multiple replies.
</p><p>
Individual requests, replies, events or errors intercepted by the extension
on behalf of recording clients cannot be split across reply packets. In order
to reduce overhead, multiple intercepted requests, replies, events and errors
might be collected
into a single reply.
Nevertheless, all data are returned to the client in a timely manner.
</p></div><div class="sect2" title="Record Context"><div class="titlepage"><div><div><h3 class="title"><a id="Record_Context"></a>Record Context</h3></div></div></div><p>
The extension adds a record context resource (RC)
to the set of resources managed by the server. All the
extension operations take an RC as an argument. Although the protocol
permits sharing of RCs between clients, it is expected that clients will
use their own RCs. The attributes used in extension operations are stored
in the RCs, and these attributes include the protocol and clients to
intercept.
</p><p>
The terms "register" and "unregister" are used to describe the
relationship between clients to intercept and the RC. To register
a client with an RC means the client is added to the list
of clients to intercept; to unregister a client means the client
is deleted from the list of clients to intercept. When the
server is requested to register or unregister clients from an RC,
it is required to do so immediately. That is, it is not permissible for
the server to wait until recording is enabled to register clients
or recording is disabled to unregister clients.
</p></div><div class="sect2" title="Record Client Connections"><div class="titlepage"><div><div><h3 class="title"><a id="Record_Client_Connections"></a>Record Client Connections</h3></div></div></div><p>
The typical communication model for a recording client is to open
two connections to the server and use one for RC control and
the other for reading protocol data.
</p><p>
The "control" connection can execute requests to obtain information about
the supported protocol version, create and destroy RCs, specify protocol
types to intercept and clients to be recorded, query the current state
of an RC, and to stop interception and reporting of protocol data. The
"data" connection can execute a request to
enable interception
and reporting of specified protocol for a particular RC. When the
"enable" request is issued, intercepted protocol is sent back on the
same connection, generally in more than one reply packet. Until the last
reply to the "enable" request is sent by the server, signifying that
the request execution is complete, no other requests will be executed by
the server on that connection. That is, the connection that data are being
reported on cannot issue the "disable" request until the last reply
to the "enable" request is sent by the server. Therefore, unless a
recording client never has the need to disable the interception and reporting
of protocol data, two client connections are necessary.
</p></div><div class="sect2" title="Events"><div class="titlepage"><div><div><h3 class="title"><a id="Events"></a>Events</h3></div></div></div><p>
The terms "delivered events" and "device events" are used
to describe the two event classes recording clients may
select for interception. These event classes are handled differently
by the extension. Delivered events are core X events or X extension events
the server actually delivers to one or more clients. Device events are
events generated by core X devices or extension input devices that the
server may or may not deliver to any clients. When device events
are selected for interception by a recording client, the extension
guarantees each device event is recorded and will be forwarded
to the recording client in the same order it is generated by the
device.
</p><p>
The recording of selected device events is not affected
by server grabs. Delivered events, on the other hand, can be affected
by server grabs.
If a recording client selects both
a device event and delivered events that result from that device
event, the delivered events are recorded after the device event.
In the absence of grabs, the delivered events for a
device event precede later device events.
</p><p>
Requests that have side effects on
devices, such as
<code class="function">WarpPointer</code>
and
<code class="function">GrabPointer</code>
with a confine-to window,
will cause RECORD to record an associated device event.
The XTEST extension request
<code class="function">XTestFakeInput</code>
causes a device event to be recorded; the
device events are recorded in the same order that the
<code class="function">XTestFakeInput</code>
requests are received by the server.
</p><p>
If a key autorepeats, multiple
<code class="function">KeyPress</code>
and
<code class="function">KeyRelease</code>
device events are reported.
</p></div><div class="sect2" title="Timing"><div class="titlepage"><div><div><h3 class="title"><a id="Timing"></a>Timing</h3></div></div></div><p>
Requests are recorded just before
they are executed; the time associated with a request is the server
time when it is recorded.
</p></div></div><div class="sect1" title="Types"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Types"></a>Types</h2></div></div></div><p>
The following new types are used in the request definitions that appear
in section 3.
</p><p>RC: CARD32</p><p>
The
<code class="function">"RC"</code>
type is a resource identifier for a server record context.
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /><col align="left" class="c3" /></colgroup><tbody><tr><td align="left">RANGE8:</td><td align="left">[first, last:</td><td align="left">CARD8]</td></tr><tr><td align="left">RANGE16:</td><td align="left">[first, last:</td><td align="left">CARD16]</td></tr><tr><td align="left">EXTRANGE:</td><td align="left">[major:</td><td align="left">RANGE8</td></tr><tr><td align="left"> </td><td align="left">minor:</td><td align="left">RANGE16]</td></tr></tbody></table></div><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /><col align="left" class="c3" /></colgroup><tbody><tr><td align="left">RECORDRANGE:</td><td align="left">[core-requests:</td><td align="left">RANGE8</td></tr><tr><td align="left"> </td><td align="left">core-replies:</td><td align="left">RANGE8</td></tr><tr><td align="left"> </td><td align="left">ext-requests:</td><td align="left">EXTRANGE</td></tr><tr><td align="left"> </td><td align="left">ext-replies:</td><td align="left">EXTRANGE</td></tr><tr><td align="left"> </td><td align="left">delivered-events:</td><td align="left">RANGE8</td></tr><tr><td align="left"> </td><td align="left">device-events:</td><td align="left">RANGE8</td></tr><tr><td align="left"> </td><td align="left">errors:</td><td align="left">RANGE8</td></tr><tr><td align="left"> </td><td align="left">client-started:</td><td align="left">BOOL</td></tr><tr><td align="left"> </td><td align="left">client-died:</td><td align="left">BOOL]</td></tr></tbody></table></div><p>
The
<code class="function">"RECORDRANGE"</code>
structure contains the protocol values to intercept. Typically,
this structure is sent by recording clients over the control connection
when creating or modifying an RC.
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
Specifies core X protocol requests with an opcode field between <span class="emphasis"><em>first</em></span>
and <span class="emphasis"><em>last</em></span> inclusive. If <span class="emphasis"><em>first</em></span> is equal to 0 and <span class="emphasis"><em>last</em></span> is equal to 0, no
core requests are specified by this RECORDRANGE. If <span class="emphasis"><em>first</em></span> is greater
than <span class="emphasis"><em>last</em></span>, a
<code class="function">"Value"</code>
error results.
</p></li><li class="listitem"><p>
Specifies replies resulting from core X protocol requests with an opcode
field between <span class="emphasis"><em>first</em></span> and <span class="emphasis"><em>last</em></span> inclusive. If <span class="emphasis"><em>first</em></span> is equal to 0 and <span class="emphasis"><em>last</em></span>
is equal to 0, no core replies are specified by this RECORDRANGE. If
<span class="emphasis"><em>first</em></span> is greater than <span class="emphasis"><em>last</em></span>, a
<code class="function">"Value"</code>
error results.
</p></li><li class="listitem"><p>
Specifies extension protocol requests with a major opcode field between
<span class="emphasis"><em>major.first</em></span> and <span class="emphasis"><em>major.last</em></span> and a minor opcode field between <span class="emphasis"><em>minor.first</em></span>
and <span class="emphasis"><em>minor.last</em></span> inclusive.
If <span class="emphasis"><em>major.first</em></span> and <span class="emphasis"><em>major.last</em></span> are equal to 0, no
extension protocol requests are specified by this RECORDRANGE. If
<span class="emphasis"><em>major.first</em></span> or <span class="emphasis"><em>major.last</em></span> is less than 128 and greater than 0,
if <span class="emphasis"><em>major.first</em></span> is greater than <span class="emphasis"><em>major.last</em></span>,
or if <span class="emphasis"><em>minor.first</em></span>
is greater than <span class="emphasis"><em>minor.last</em></span>, a
<code class="function">"Value"</code>
error results.
</p></li><li class="listitem"><p>
Specifies replies resulting from extension protocol requests with a
major opcode field between <span class="emphasis"><em>major.first</em></span> and <span class="emphasis"><em>major.last</em></span> and
a minor opcode field between <span class="emphasis"><em>minor.first</em></span> and <span class="emphasis"><em>minor.last</em></span>
inclusive. If <span class="emphasis"><em>major.first</em></span> and <span class="emphasis"><em>major.last</em></span> are equal to 0,
no extension protocol replies are specified by this RECORDRANGE. If
<span class="emphasis"><em>major.first</em></span> or <span class="emphasis"><em>major.last</em></span> is less than 128 and greater
than 0,
if <span class="emphasis"><em>major.first</em></span> is greater than <span class="emphasis"><em>major.last</em></span>,
or if <span class="emphasis"><em>minor.first</em></span> is greater than <span class="emphasis"><em>minor.last</em></span>, a
<code class="function">"Value"</code>
error results.
</p></li><li class="listitem"><p>
This is used for both core X protocol events and arbitrary extension
events. Specifies events that are delivered to at least one client
that have a code field between <span class="emphasis"><em>first</em></span> and <span class="emphasis"><em>last</em></span>
inclusive. If <span class="emphasis"><em>first</em></span> is equal to 0 and <span class="emphasis"><em>last</em></span> is equal to 0,
no events are specified by this RECORDRANGE.
Otherwise, if <span class="emphasis"><em>first</em></span> is less than 2
or <span class="emphasis"><em>last</em></span> is less than 2, or if
<span class="emphasis"><em>first</em></span> is greater than <span class="emphasis"><em>last</em></span>, a
<code class="function">"Value"</code>
error results.
</p></li><li class="listitem"><p>
This is used for both core X device events and X extension device
events that may or may not be delivered to a client.
Specifies device events that have a code field between <span class="emphasis"><em>first</em></span> and
<span class="emphasis"><em>last</em></span> inclusive. If <span class="emphasis"><em>first</em></span> is equal to 0 and <span class="emphasis"><em>last</em></span>
is equal to 0, no device events are specified by this RECORDRANGE.
Otherwise,
if <span class="emphasis"><em>first</em></span> is less than 2 or <span class="emphasis"><em>last</em></span> is less
than 2, or if <span class="emphasis"><em>first</em></span> is greater than <span class="emphasis"><em>last</em></span>, a
<code class="function">"Value"</code>
error results.
</p></li><li class="listitem"><p>
Because
the generated device event may or may not be associated with a
client, unlike other RECORDRANGE components, which select protocol for a
specific client, selecting for device events in any RECORDRANGE in an RC
causes the recording client to receive one instance for each device event
generated that is in the range specified.
</p></li><li class="listitem"><p>
This is used for both core X protocol errors and arbitrary extension
errors. Specifies errors that have a code field between <span class="emphasis"><em>first</em></span> and
<span class="emphasis"><em>last</em></span> inclusive. If <span class="emphasis"><em>first</em></span> is equal to 0 and <span class="emphasis"><em>last</em></span> is equal to 0, no
errors are specified by this RECORDRANGE. If <span class="emphasis"><em>first</em></span> is greater
than <span class="emphasis"><em>last</em></span>, a
<code class="function">"Value"</code>
error results.
</p></li><li class="listitem"><p>
Specifies the connection setup reply.
If
<code class="function">False ,</code>
the connection setup reply is not specified by
this RECORDRANGE.
</p></li><li class="listitem"><p>
Specifies notification when a client disconnects.
If
<code class="function">False ,</code>
notification when a client disconnects is not specified by
this RECORDRANGE.
</p></li></ul></div><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /><col align="left" class="c3" /></colgroup><tbody><tr><td align="left">ELEMENT_HEADER:</td><td align="left">[from-server-time:</td><td align="left">BOOL</td></tr><tr><td align="left"> </td><td align="left">from-client-time:</td><td align="left">BOOL</td></tr><tr><td align="left"> </td><td align="left">from-client-sequence:</td><td align="left">BOOL]</td></tr></tbody></table></div><p>
The
<code class="function">ELEMENT_HEADER</code>
structure specifies additional data that precedes each protocol
element in the <span class="emphasis"><em>data</em></span> field of a
<code class="function">RecordEnableContext</code>
reply.
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
If <span class="emphasis"><em>from-server-time</em></span> is
<code class="function">True ,</code>
each intercepted protocol element
with category
<code class="function">FromServer</code>
is preceded by the server time when the protocol was recorded.
</p></li><li class="listitem"><p>
If <span class="emphasis"><em>from-client-time</em></span> is
<code class="function">True ,</code>
each intercepted protocol element
with category
<code class="function">FromClient</code>
is preceded by the server time when the protocol was recorded.
</p></li><li class="listitem"><p>
If <span class="emphasis"><em>from-client-sequence</em></span> is
<code class="function">True ,</code>
each intercepted protocol
element with category
<code class="function">FromClient</code>
or
<code class="function">ClientDied</code>
is preceded by the
32-bit sequence number of the recorded client's most recent request
processed by the server at that time.
For
<code class="function">FromClient ,</code>
this will be one less than the sequence number of the
following request.
For
<code class="function">ClientDied ,</code>
the sequence number will be the only data, because no
protocol is recorded.
</p></li></ul></div><p>
Note that a reply containing device events is treated the same as
other replies with category
<code class="function">FromServer</code>
for purposes of these flags.
Protocol with category
<code class="function">FromServer</code>
is never preceded by a sequence
number because almost all such protocol has a sequence number in it anyway.
</p><p>
If both a server time and a sequence number have been requested for a
reply, each protocol request is
preceded first by the time and second by the sequence number.
</p><p>XIDBASE: CARD32</p><p>
The XIDBASE type is used to identify a particular client. Valid
values are any existing resource identifier
of any connected client,
in which case the client
that created the resource is specified, or the resource identifier
base sent to the target client from the server in the connection setup
reply. A value of 0 (zero) is valid when the XIDBASE is associated
with device events that may not have been delivered to a client.
</p><p>
CLIENTSPEC: XIDBASE or {<span class="emphasis"><em>CurrentClients</em></span>,
<span class="emphasis"><em>FutureClients</em></span>, <span class="emphasis"><em>AllClients</em></span>}
</p><p>
The CLIENTSPEC type defines the set of clients the RC attributes are
associated with. This type is used by recording clients when creating
an RC or when changing RC attributes. XIDBASE specifies that the RC
attributes apply to a single client only.
<code class="function">CurrentClients</code>
specifies
that the RC attributes apply to current client connections;
<code class="function">FutureClients</code>
specifies future client connections;
<code class="function">AllClients</code>
specifies all client connections, which includes current and future.
</p><p>
The numeric values for
<code class="function">CurrentClients ,</code>
<code class="function">FutureClients</code>
and
<code class="function">AllClients</code>
are
defined such that there will be no intersection with valid XIDBASEs.
</p><p>
When the context is enabled, the data connection is unregistered if it
was registered.
If the context is enabled,
<code class="function">CurrentClients</code>
and
<code class="function">AllClients</code>
silently exclude the recording data connection.
It is an error to explicitly register the data connection.
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /><col align="left" class="c3" /></colgroup><tbody><tr><td align="left">CLIENT_INFO:</td><td align="left">[client-resource:</td><td align="left">CLIENTSPEC</td></tr><tr><td align="left"> </td><td align="left">intercepted-protocol:</td><td align="left">LISTofRECORDRANGE]</td></tr></tbody></table></div><p>
This structure specifies an intercepted client and the protocol to be
intercepted for the client. The <span class="emphasis"><em>client-resource</em></span> field is a
resource base that identifies the intercepted client. The
<span class="emphasis"><em>intercepted-protocol</em></span> field specifies the protocol to intercept
for the <span class="emphasis"><em>client-resource</em></span>.
</p></div><div class="sect1" title="Errors"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Errors"></a>Errors</h2></div></div></div><p>
<span class="bold"><strong>RecordContext</strong></span>
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
This error is returned if the value for an RC argument
in a request does not name a defined record context.
</p></li></ul></div></div></div><div class="chapter" title="Chapter 3. Protocol Requests"><div class="titlepage"><div><div><h2 class="title"><a id="Protocol_Requests"></a>Chapter 3. Protocol Requests</h2></div></div></div><p>
<code class="function">RecordQueryVersion</code>
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
<span class="emphasis"><em>major-version</em></span>,
<span class="emphasis"><em>minor-version</em></span>: CARD16
</p></li></ul></div><p>
->
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
<span class="emphasis"><em>major-version</em></span>,
<span class="emphasis"><em>minor-version</em></span>: CARD16
</p></li></ul></div><p>
This request specifies the RECORD extension protocol version the client
would like to use. When the specified protocol version is supported
by the extension, the protocol version the server expects from the
client is returned. Clients must use this request before other RECORD
extension requests.
</p><p>
This request also determines whether or not the RECORD extension protocol
version specified by the client is supported by the extension. If the
extension supports the version specified by the client, this version number
should be returned. If the client has requested a higher version than is
supported by the server, the server's highest version should be returned.
Otherwise, if the client has requested a lower version than is supported
by the server, the server's lowest version should be returned. This document
defines major version one (1),
minor version thirteen (13).
</p><p>
<code class="function">RecordCreateContext</code>
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><tbody><tr><td align="left">
<span class="emphasis"><em>context</em></span>: RC
</td></tr><tr><td align="left">
<span class="emphasis"><em>element-header</em></span>: ELEMENT_HEADER
</td></tr><tr><td align="left">
<span class="emphasis"><em>client-specifiers</em></span>: LISTofCLIENTSPEC
</td></tr><tr><td align="left">
<span class="emphasis"><em>ranges</em></span>: LISTofRECORDRANGE
</td></tr><tr><td align="left">
Errors:
<code class="function">Match ,</code>
<code class="function">Value ,</code>
<code class="function">IDChoice ,</code>
<code class="function">Alloc</code>
</td></tr></tbody></table></div><p>
This request creates a new
record context
within the server and assigns the identifier <span class="emphasis"><em>context</em></span> to
it. After the <span class="emphasis"><em>context</em></span> is created, this request registers the
set of clients in <span class="emphasis"><em>client-specifiers</em></span> with the <span class="emphasis"><em>context</em></span> and
specifies the protocol to intercept for those clients.
The recorded protocol elements will be preceded by data as specified
by <span class="emphasis"><em>element-header</em></span>.
Typically,
this request is used by a recording client over the control
connection. Multiple RC
objects can exist simultaneously, containing overlapping sets of
protocol and clients to intercept.
</p><p>
If any of the values in
<span class="emphasis"><em>element-header</em></span> or
<span class="emphasis"><em>ranges</em></span> is invalid, a
<code class="function">"Value"</code>
error results. Duplicate items in the list of <span class="emphasis"><em>client-specifiers</em></span> are
ignored. If any item in the <span class="emphasis"><em>client-specifiers</em></span> list is not a valid
CLIENTSPEC, a
<code class="function">"Match"</code>
error results. Otherwise, each item in the <span class="emphasis"><em>client-specifiers</em></span> list is
processed as follows:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
If the item is an XIDBASE identifying a particular client, the
specified client is registered with the <span class="emphasis"><em>context</em></span> and the protocol
to intercept for the client is then set to <span class="emphasis"><em>ranges</em></span>.
</p></li><li class="listitem"><p>
If the item is
<code class="function">CurrentClients ,</code>
all existing clients are registered with the
<span class="emphasis"><em>context</em></span> at this time.
The protocol to intercept for all clients registered
with the <span class="emphasis"><em>context</em></span> is then set to <span class="emphasis"><em>ranges</em></span>.
</p></li><li class="listitem"><p>
If the item is
<code class="function">FutureClients ,</code>
all clients that connect to the server
after this request executes will be automatically registered with the
<span class="emphasis"><em>context</em></span>. The protocol to intercept for such clients will be set to
<span class="emphasis"><em>ranges</em></span> in the <span class="emphasis"><em>context</em></span>.
</p></li><li class="listitem"><p>
If the item is
<code class="function">AllClients ,</code>
the effect is as if the actions described
for
<code class="function">FutureClients</code>
are performed, followed by the actions for
<code class="function">CurrentClients .</code>
</p></li></ul></div><p>
The
<code class="function">"Alloc"</code>
error results when the server is unable to allocate the necessary
resources.
</p><p>
<code class="function">RecordRegisterClients</code>
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><tbody><tr><td align="left">
<span class="emphasis"><em>context</em></span>: RC
</td></tr><tr><td align="left">
<span class="emphasis"><em>element-header</em></span>: ELEMENT_HEADER
</td></tr><tr><td align="left">
<span class="emphasis"><em>client-specifiers</em></span>: LISTofCLIENTSPEC
</td></tr><tr><td align="left">
<span class="emphasis"><em>ranges</em></span>: LISTofRECORDRANGE
</td></tr><tr><td align="left">
Errors:
<code class="function">Match ,</code>
<code class="function">Value ,</code>
<code class="function">RecordContext ,</code>
<code class="function">Alloc</code>
</td></tr></tbody></table></div><p>
This request registers the set of clients in <span class="emphasis"><em>client-specifiers</em></span> with
the given <span class="emphasis"><em>context</em></span> and specifies the protocol to intercept for those
clients.
The header preceding each recorded protocol element is set as specified
by <span class="emphasis"><em>element-header</em></span>.
These flags affect the entire
context; their effect is not limited to the clients registered by
this request.
Typically, this request is used by a recording client over
the control connection.
</p><p>
If <span class="emphasis"><em>context</em></span> does not name a valid RC, a
<code class="function">"RecordContext"</code>
error results. If any of the values in
<span class="emphasis"><em>element-header</em></span> or <span class="emphasis"><em>ranges</em></span> is invalid, a
<code class="function">"Value"</code>
error results. Duplicate items in the list of <span class="emphasis"><em>client-specifiers</em></span> are
ignored. If any item in the list of <span class="emphasis"><em>client-specifiers</em></span> is not a
valid CLIENTSPEC, a
<code class="function">"Match"</code>
error results.
If the <span class="emphasis"><em>context</em></span> is enabled and the XID of the enabling connection
is specified, a
<code class="function">"Match"</code>
error results.
Otherwise, each item in the <span class="emphasis"><em>client-specifiers</em></span> list is
processed as follows:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
If the item is an XIDBASE identifying a particular client, the
specified client is registered with the <span class="emphasis"><em>context</em></span> if it is not already
registered. The protocol to intercept for the client is then set to
<span class="emphasis"><em>ranges</em></span>.
</p></li><li class="listitem"><p>
If the item is
<code class="function">CurrentClients ,</code>
all existing clients that are not
already registered with the specified <span class="emphasis"><em>context</em></span>,
except the enabling connection if the <span class="emphasis"><em>context</em></span> is enabled,
are registered at this
time. The protocol to intercept for all clients registered with the
<span class="emphasis"><em>context</em></span> is then set to <span class="emphasis"><em>ranges</em></span>.
</p></li><li class="listitem"><p>
If the item is
<code class="function">FutureClients ,</code>
all clients that connect to the server
after this request executes will be automatically registered with the
<span class="emphasis"><em>context</em></span>. The protocol to intercept for such clients will be set to
<span class="emphasis"><em>ranges</em></span> in the <span class="emphasis"><em>context</em></span>.
The set of clients that are registered with the
<span class="emphasis"><em>context</em></span> and their corresponding sets
of protocol to intercept are left intact.
</p></li><li class="listitem"><p>
If the item is
<code class="function">AllClients ,</code>
the effect is as if the actions described
for
<code class="function">FutureClients</code>
are performed, followed by the actions for
<code class="function">CurrentClients .</code>
</p></li></ul></div><p>
The
<code class="function">"Alloc"</code>
error results when the server is unable to allocate the necessary
resources.
</p><p>
<code class="function">RecordUnregisterClients</code>
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><tbody><tr><td align="left">
<span class="emphasis"><em>context</em></span>: RC
</td></tr><tr><td align="left">
<span class="emphasis"><em>client-specifiers</em></span>: LISTofCLIENTSPEC
</td></tr><tr><td align="left">
Errors:
<code class="function">Match ,</code>
<code class="function">RecordContext</code>
</td></tr></tbody></table></div><p>
This request removes the set of clients in <span class="emphasis"><em>client-specifiers</em></span> from the
given <span class="emphasis"><em>context</em></span>'s set of registered clients. Typically, this request is
used by a recording client over the control connection.
</p><p>
If <span class="emphasis"><em>context</em></span> does not name a valid RC, a
<code class="function">"RecordContext"</code>
error results. Duplicate items in the list of <span class="emphasis"><em>client-specifiers</em></span> are
ignored. If any item in the list is not a valid CLIENTSPEC, a
<code class="function">"Match"</code>
error results. Otherwise, each item in the <span class="emphasis"><em>client-specifiers</em></span> list is
processed as follows:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
If the item is an XIDBASE identifying a particular client, and the
specified client is currently registered with the <span class="emphasis"><em>context</em></span>, it is
unregistered, and the set of protocol to intercept for the client is
deleted from the <span class="emphasis"><em>context</em></span>. If the specified client is not registered
with the <span class="emphasis"><em>context</em></span>, the item has no effect.
</p></li><li class="listitem"><p>
If the item is
<code class="function">CurrentClients ,</code>
all clients currently registered with
the <span class="emphasis"><em>context</em></span> are unregistered from it, and their corresponding sets of
protocol to intercept are deleted from the <span class="emphasis"><em>context</em></span>.
</p></li><li class="listitem"><p>
If the item is
<code class="function">FutureClients ,</code>
clients that connect to the server after
this request executes will not automatically be registered with the
<span class="emphasis"><em>context</em></span>. The set of clients that are registered with this context
and their corresponding sets of protocol that will be
intercepted are left intact.
</p></li><li class="listitem"><p>
If the item is
<code class="function">AllClients ,</code>
the effect is as if the actions described
for
<code class="function">FutureClients</code>
are performed, followed by the actions for
<code class="function">CurrentClients .</code>
</p></li></ul></div><p>
A client is unregistered automatically when it disconnects.
</p><p>
<code class="function">RecordGetContext</code>
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><tbody><tr><td align="left">
<span class="emphasis"><em>context</em></span>: RC
</td></tr><tr><td align="left">
->
</td></tr><tr><td align="left">
<span class="emphasis"><em>enabled</em></span>: BOOL
</td></tr><tr><td align="left">
<span class="emphasis"><em>element-header</em></span>: ELEMENT_HEADER
</td></tr><tr><td align="left">
<span class="emphasis"><em>intercepted-clients</em></span>: LISTofCLIENT_INFO
</td></tr><tr><td align="left">
Errors:
</td></tr><tr><td align="left">
<code class="function">RecordContext</code>
</td></tr></tbody></table></div><p>
This request queries the current state of the specified <span class="emphasis"><em>context</em></span>
and is typically used by a recording client over the control connection.
The <span class="emphasis"><em>enabled</em></span> field
specifies the state of data transfer between the extension and the
recording client, and is either enabled
<code class="function">( True )</code>
or disabled
<code class="function">( False ).</code>
The initial state is disabled.
When enabled, all core X protocol and
extension protocol received from (requests) or sent to (replies,
errors, events) a particular client, and requested to be intercepted
by the recording client, is reported to the recording client over the
data connection.
The <span class="emphasis"><em>element-header</em></span> specifies the header that precedes each
recorded protocol element.
The
<span class="emphasis"><em>intercepted-clients</em></span> field specifies the list of clients currently
being recorded and the protocol associated with each client.
If future clients will be automatically registered with the context,
one of the returned CLIENT_INFO structures has a <span class="emphasis"><em>client-resource</em></span> value
of FutureClients and an <span class="emphasis"><em>intercepted-protocol</em></span> giving the protocol to
intercept for future clients.
Protocol ranges may be decomposed, coalesced, or otherwise modified
by the server from how they were specified by the client.
All CLIENTSPECs registered with the server are returned, even if the
RECORDRANGE(s) associated with them specify no protocol to record.
</p><p>
When the <span class="emphasis"><em>context</em></span> argument is not valid, a
<code class="function">RecordContext</code>
error results.
</p><p>
<code class="function">RecordEnableContext</code>
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><tbody><tr><td align="left">
<span class="emphasis"><em>context</em></span>: RC
</td></tr><tr><td align="left">
->+
</td></tr><tr><td align="left">
<span class="emphasis"><em>category</em></span>:
{<code class="function">FromServer</code>, <code class="function">FromClient</code>,
<code class="function">ClientStarted</code>, <code class="function">ClientDied</code>,
<code class="function">StartOfData</code>,
<code class="function">EndOfData</code>}
</td></tr><tr><td align="left">
<span class="emphasis"><em>element-header</em></span>: ELEMENT_HEADER
</td></tr><tr><td align="left">
<span class="emphasis"><em>client-swapped</em></span>: BOOL
</td></tr><tr><td align="left">
<span class="emphasis"><em>id-base</em></span>: XIDBASE
</td></tr><tr><td align="left">
<span class="emphasis"><em>server-time</em></span>: TIMESTAMP
</td></tr><tr><td align="left">
<span class="emphasis"><em>recorded-sequence-number</em></span>: CARD32
</td></tr><tr><td align="left">
<span class="emphasis"><em>data</em></span>: LISTofBYTE
</td></tr><tr><td align="left">
Errors:
<code class="function">Match</code>,
<code class="function">RecordContext</code>
</td></tr></tbody></table></div><p>
This request enables data transfer between the recording client
and the extension and returns the protocol data the recording client
has previously expressed interest in. Typically, this request is
executed by the recording client over the data connection.
</p><p>
If the client is registered on the <span class="emphasis"><em>context</em></span>, it is unregistered
before any recording begins.
</p><p>
Once the server receives this request, it begins intercepting
and reporting to the recording client all core and extension protocol
received from or sent to clients registered with the RC that the
recording client has expressed interest in. All intercepted protocol data
is returned in the byte-order of the recorded client. Therefore,
recording clients are responsible for all byte swapping, if required.
More than one recording client cannot enable data transfer on the
same RC at the same time. Multiple intercepted requests, replies,
events and errors might be packaged into a single reply before
being returned to the recording clients.
</p><p>
The
<span class="emphasis"><em>category</em></span> field determines the possible
types of the data.
When a context is enabled, the server will immediately send a reply of
category
<code class="function">StartOfData</code>
to notify the client that recording is enabled.
A category of
<code class="function">FromClient</code>
means the data are from the client
(requests);
<code class="function">FromServer</code>
means data are from the server (replies,
errors, events, or device events).
For a new client, the category is
<code class="function">ClientStarted</code>
and the data are the connection setup reply.
When
the recorded client connection is closed, <span class="emphasis"><em>category</em></span> is
set to the value
<code class="function">ClientDied</code>
and no protocol is included in this reply.
When the disable request is made over the control connection,
a final reply is sent over the data connection with category
<code class="function">EndOfData</code>
and no protocol.
</p><p>
The <span class="emphasis"><em>element-header</em></span> field returns the value currently set for the
context, which tells what header information precedes each recorded
protocol element in this reply.
</p><p>
The <span class="emphasis"><em>client-swapped</em></span> field is
<code class="function">True</code>
if the byte order of
the protocol being recorded
is swapped
relative to the recording client;
otherwise, <span class="emphasis"><em>client-swapped</em></span> is
<code class="function">False .</code>
The recorded protocol
is in the byte order of the client being
recorded; device events are in the byte order of the
recording client.
For replies of category
<code class="function">StartOfData</code>
and
<code class="function">EndOfData</code>
the
<span class="emphasis"><em>client-swapped</em></span> bit is set
according
to the byte order of the server relative to the recording client.
The <span class="emphasis"><em>id-base</em></span> field is the resource identifier base
sent to the client from the server in the
connection setup reply, and hence, identifies the client being
recorded. The <span class="emphasis"><em>id-base</em></span> field is 0 (zero) when the protocol
data being
returned are device events.
The <span class="emphasis"><em>server-time</em></span> field is set to the time of the
server when the first protocol element in this reply was intercepted.
The <span class="emphasis"><em>server-time</em></span>
of reply N+1 is greater than or equal to the <span class="emphasis"><em>server-time</em></span> of reply N,
and is greater than or equal to the time of the last protocol
element in reply N.
</p><p>
The <span class="emphasis"><em>recorded-sequence-number</em></span> field is set to the sequence number
of the recorded client's most recent request processed by the server.
</p><p>
The <span class="emphasis"><em>data</em></span> field
contains the raw protocol data being returned to the recording client.
If requested by the <span class="emphasis"><em>element-header</em></span> of this record context, each
protocol element may be preceded by a 32-bit timestamp and/or
a 32-bit sequence number.
If present, both the timestamp and sequence number are always in the
byte order of the recording client.
</p><p>
For the core X events
<code class="function">KeyPress ,</code>
<code class="function">KeyRelease ,</code>
<code class="function">ButtonPress ,</code>
and
<code class="function">ButtonRelease ,</code>
the fields of a device event that contain
valid information are <span class="emphasis"><em>time</em></span> and <span class="emphasis"><em>detail</em></span>.
For the core X event
<code class="function">MotionNotify ,</code>
the fields of a device event that contain
valid information are <span class="emphasis"><em>time</em></span>, <span class="emphasis"><em>root</em></span>,
<span class="emphasis"><em>root-x</em></span> and <span class="emphasis"><em>root-y</em></span>.
The <span class="emphasis"><em>time</em></span> field refers to the time the event was generated by the
device.
</p><p>
For the extension input device events
<code class="function">DeviceKeyPress ,</code>
<code class="function">DeviceKeyRelease ,</code>
<code class="function">DeviceButtonPress ,</code>
and
<code class="function">DeviceButtonRelease ,</code>
the fields of a device event that contain valid information are
<span class="emphasis"><em>device</em></span>, <span class="emphasis"><em>time</em></span> and <span class="emphasis"><em>detail</em></span>.
For
<code class="function">DeviceMotionNotify ,</code>
the valid device event fields are
<span class="emphasis"><em>device</em></span> and <span class="emphasis"><em>time</em></span>.
For the extension input device events
<code class="function">ProximityIn</code>
and
<code class="function">ProximityOut ,</code>
the fields of a device event that contain valid
information are <span class="emphasis"><em>device</em></span> and <span class="emphasis"><em>time</em></span>.
For the extension input device event
<code class="function">DeviceValuator ,</code>
the fields of a device event that contain valid information are
<span class="emphasis"><em>device</em></span>,
<span class="emphasis"><em>num_valuators</em></span>, <span class="emphasis"><em>first_valuator</em></span>, and <span class="emphasis"><em>valuators</em></span>.
The <span class="emphasis"><em>time</em></span> field refers to the time the event was generated by the
device.
</p><p>
The error
<code class="function">"Match"</code>
is returned when data transfer is already enabled.
When the <span class="emphasis"><em>context</em></span> argument is not valid, a
<code class="function">RecordContext</code>
error results.
</p><p>
<code class="function">RecordDisableContext</code>
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /></colgroup><tbody><tr><td align="left">
<span class="emphasis"><em>context</em></span>: RC
</td></tr><tr><td align="left">
Errors:
<code class="function">RecordContext</code>
</td></tr></tbody></table></div><p>
This request is typically executed by the recording client over the
control connection. This request directs the extension to immediately
send any complete protocol elements currently buffered,
to send a final reply with category
<code class="function">EndOfData ,</code>
and to discontinue
data transfer between the extension and the recording client.
Protocol reporting is disabled
on the data connection that is currently enabled for the given
<span class="emphasis"><em>context</em></span>. Once the extension completes
processing this request, no additional recorded protocol will
be reported to the recording client. If a data connection is not
currently enabled when this request is executed, then this request has
no affect on the state of data transfer.
An RC is disabled automatically when the connection to the enabling
client is closed down.
</p><p>
When the <span class="emphasis"><em>context</em></span> argument is not valid, a
<code class="function">RecordContext</code>
error results.
</p><p>
<code class="function">RecordFreeContext</code>
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
<span class="emphasis"><em>context</em></span> RC
</p></li><li class="listitem"><p>
Errors:
<code class="function">RecordContext</code>
</p></li></ul></div><p>
This request deletes the association between the resource ID and the
RC and destroys the RC.
If a client has enabled data transfer on this <span class="emphasis"><em>context</em></span>, the actions
described in
<code class="function">RecordDisableContext</code>
are performed before the <span class="emphasis"><em>context</em></span>
is freed.
</p><p>
An RC is destroyed automatically when the connection to the creating client
is closed down and the close-down mode is <code class="function">DestroyAll</code>. When the
<span class="emphasis"><em>context</em></span> argument is not valid, a
<code class="function">RecordContext</code>
error results.
</p></div><div class="chapter" title="Chapter 4. Encoding"><div class="titlepage"><div><div><h2 class="title"><a id="Encoding"></a>Chapter 4. Encoding</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="sect1"><a href="#Types_2">Types</a></span></dt><dt><span class="sect1"><a href="#Errors_2">Errors</a></span></dt><dt><span class="sect1"><a href="#Requests">Requests</a></span></dt></dl></div><p>
Please refer to the X11 Protocol Encoding document as this document uses
conventions established there.
</p><p>
The name of this extension is "RECORD".
</p><div class="sect1" title="Types"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Types_2"></a>Types</h2></div></div></div><p>
RC: CARD32
</p><pre class="literallayout">
RANGE8
1 CARD8 first
1 CARD8 last
</pre><pre class="literallayout">
RANGE16
2 CARD16 first
2 CARD16 last
</pre><pre class="literallayout">
EXTRANGE
2 RANGE8 major
4 RANGE16 minor
</pre><pre class="literallayout">
RECORDRANGE
2 RANGE8 core-requests
2 RANGE8 core-replies
6 EXTRANGE ext-requests
6 EXTRANGE ext-replies
2 RANGE8 delivered-events
2 RANGE8 device-events
2 RANGE8 errors
1 BOOL client-started
1 BOOL client-died
</pre><pre class="literallayout">
ELEMENT_HEADER
1 CARD8
0x01 from-server-time
0x02 from-client-time
0x04 from-client-sequence
</pre><p>
XIDBASE: CARD32
</p><pre class="literallayout">
CLIENTSPEC
4 XIDBASE client-id-base
1 CurrentClients
2 FutureClients
3 AllClients
</pre><pre class="literallayout">
CLIENT_INFO
4 CLIENTSPEC client-resource
4 CARD32 n, number of record ranges in
intercepted-protocol
24n LISTofRECORDRANGE intercepted-protocol
</pre></div><div class="sect1" title="Errors"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Errors_2"></a>Errors</h2></div></div></div><pre class="literallayout">
<code class="function">RecordContext</code>
1 0 Error
1 CARD8 extension's base error code + 0
2 CARD16 sequence number
4 CARD32 invalid record context
24 unused
</pre></div><div class="sect1" title="Requests"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Requests"></a>Requests</h2></div></div></div><pre class="literallayout">
<code class="function">RecordQueryVersion</code>
1 CARD8 major opcode
1 0 minor opcode
2 2 request length
2 CARD16 major version
2 CARD16 minor version
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
2 CARD16 major version
2 CARD16 minor version
20 unused
</pre><pre class="literallayout">
<code class="function">RecordCreateContext</code>
1 CARD8 major opcode
1 1 minor opcode
2 5+m+6n request length
4 RC context
1 ELEMENT_HEADER element-header
3 unused
4 CARD32 m, number of client-specifiers
4 CARD32 n, number of ranges
4m LISTofCLIENTSPEC client-specifiers
24n LISTofRECORDRANGE ranges
</pre><pre class="literallayout">
<code class="function">RecordRegisterClients</code>
1 CARD8 major opcode
1 2 minor opcode
2 5+m+6n request length
4 RC context
1 ELEMENT_HEADER element-header
3 unused
4 CARD32 m, number of client-specifiers
4 CARD32 n, number of ranges
4m LISTofCLIENTSPEC client-specifiers
24n LISTofRECORDRANGE ranges
</pre><pre class="literallayout">
<code class="function">RecordUnregisterClients</code>
1 CARD8 major opcode
1 3 minor opcode
2 3+m request length
4 RC context
4 CARD32 m, number of client-specifiers
4m LISTofCLIENTSPEC client-specifiers
</pre><pre class="literallayout">
<code class="function">RecordGetContext</code>
1 CARD8 major opcode
1 4 minor opcode
2 2 request length
4 RC context
=>
1 1 Reply
1 BOOL enabled
2 CARD16 sequence number
4 j reply length
1 ELEMENT_HEADER element-header
3 unused
4 CARD32 n, number of intercepted-clients
16 unused
4j LISTofCLIENT_INFO intercepted-clients
</pre><pre class="literallayout">
<code class="function">RecordEnableContext</code>
1 CARD8 major opcode
1 5 minor opcode
2 2 request length
4 RC context
=>+
1 1 Reply
1 category
0 FromServer
1 FromClient
2 ClientStarted
3 ClientDied
4 StartOfData
5 EndOfData
2 CARD16 sequence number
4 n reply length
1 ELEMENT_HEADER element-header
1 BOOL client-swapped
2 unused
4 XIDBASE id-base
4 TIMESTAMP server-time
4 CARD32 recorded-sequence-number
8 unused
4n BYTE data
</pre><pre class="literallayout">
<code class="function">RecordDisableContext</code>
1 CARD8 major opcode
1 6 minor opcode
2 2 request length
4 RC context
</pre><pre class="literallayout">
<code class="function">RecordFreeContext</code>
1 CARD8 major opcode
1 7 minor opcode
2 2 request length
4 RC context
</pre></div></div></div></body></html>
|