Files
vt1200/xie/docs/dec/xie23-src/include/xteststr.h
T
arti d8d54bb990 feat(xie): a client-chosen XIE image is displayed on the VT1200
The XIE path now runs end to end: XieCreateImage -> XieCreatePhoto ->
XiePutTile -> XieExport(photomap -> depth-1 pixmap) -> XCopyArea(pixmap ->
window), and the client's tile appears on screen at the client's own window
position, pixel-exact.

TWO FAULTS BEHIND THE LONG DEAD END

1. Device model (harness/mame/vt1200.cpp, opt-in VT1200_ACCEL=1).  The
   accelerator's output port 0x5600200 returns the pixel stream the firmware
   pushed into the FIFO -- the firmware then stores it into the drawable itself
   (file 0x125528: MOVE *B6,*B1 ; ADDK 0x10,B1).  The FIFO read pointer was
   never reset between transfers, so consecutive exports read stale words and
   the same fill produced 759 then 516 set pixels.  Reset m_fifo_in/out on the
   data-register write; the export is now deterministic.

2. Measurement, not the device.
   - dwt/screenshot.py without --real reads 1024x1024 at a 128-byte row stride,
     but the VR319 default programs 1280x1024 at a 2048-bit (256-byte) pitch.
     That is the "shifted" picture; --real is the correct read.
   - The earlier "0 differing bytes over 128 KiB" VRAM comparison stepped peek
     by 1024 *bit* addresses, so it scanned rows 0..63 only -- never the window
     at rows 200..263.  Over the real raster the white/black diff is 576 bytes
     spanning exactly those rows.
   - New instrument: decclient does a server-side XGetImage readback of the
     pixmap and window and counts set pixels.  That separated "the server never
     drew it" from "the framebuffer view is wrong".

EVIDENCE (reproduced twice, the second time from a fresh machine)

  no export vs 0xFF : 4096 / 4096 pixels differ
  no export vs 0x00 :    0 / 4096   (the window background is black)
  0xFF      vs 0x00 : 4096 / 4096
  0xAA      vs 0x0F : 2048 / 4096   (the two stripe phases)

Tile byte 0xAA reproduces as 1-pixel vertical stripes, 0x0F as 4-pixel, with
no shear -- so the placement is right and the pixels are the client's.

Contents: xie/ holds DEC XIE 2.3 headers, 84 man pages and complete
client+server source; a libXie.a and decclient built from DEC's own code; the
XIE probes; and evidence/ with every measurement, including explicit
retractions of the earlier wrong readings (VRAM_IDENTICAL_FOR_BOTH_FILLS and
friends).  xie/evidence/XIE_IMAGE_DISPLAYED.md is the report; frames are in
xie/evidence/png/.

The accelerator model stays opt-in: it answers the status poll and relays the
pixel stream, but performs no compositing, so it is a stand-in and the verified
default configuration is unchanged (a no-env run still parks in the level-0
diagnostics menu at PC=3FDCE400).
2026-11-01 23:22:25 +02:00

122 lines
3.9 KiB
C

/*
* *****************************************************************
* * *
* * Copyright (c) Digital Equipment Corporation, 1991, 1994 *
* * *
* * All Rights Reserved. Unpublished rights reserved under *
* * the copyright laws of the United States. *
* * *
* * The software contained on this media is proprietary to *
* * and embodies the confidential technology of Digital *
* * Equipment Corporation. Possession, use, duplication or *
* * dissemination of the software and media is authorized only *
* * pursuant to a valid written license from Digital Equipment *
* * Corporation. *
* * *
* * RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure *
* * by the U.S. Government is subject to restrictions as set *
* * forth in Subparagraph (c)(1)(ii) of DFARS 252.227-7013, *
* * or in FAR 52.227-19, as applicable. *
* * *
* *****************************************************************
*/
/*
* HISTORY
*/
/* $XConsortium: xteststr.h,v 1.5 92/04/20 13:14:15 rws Exp $ */
/*
Copyright 1992 by the Massachusetts Institute of Technology
Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that
the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation, and that the name of M.I.T. not be used in advertising or
publicity pertaining to distribution of the software without specific,
written prior permission. M.I.T. makes no representations about the
suitability of this software for any purpose. It is provided "as is"
without express or implied warranty.
*/
/* The following are needed for correctly-sized protocol requests */
#include <X11/Xmd.h>
#define Window CARD32
#define Time CARD32
#define Cursor CARD32
#define XTestCurrentCursor ((Cursor)1)
typedef struct {
CARD8 reqType; /* always XTestReqCode */
CARD8 xtReqType; /* always X_XTestGetVersion */
CARD16 length B16;
CARD8 majorVersion;
CARD8 pad;
CARD16 minorVersion B16;
} xXTestGetVersionReq;
#define sz_xXTestGetVersionReq 8
typedef struct {
BYTE type; /* X_Reply */
CARD8 majorVersion;
CARD16 sequenceNumber B16;
CARD32 length B32;
CARD16 minorVersion B16;
CARD16 pad0 B16;
CARD32 pad1 B32;
CARD32 pad2 B32;
CARD32 pad3 B32;
CARD32 pad4 B32;
CARD32 pad5 B32;
} xXTestGetVersionReply;
#define sz_xXTestGetVersionReply 32
typedef struct {
CARD8 reqType; /* always XTestReqCode */
CARD8 xtReqType; /* always X_XTestCompareCursor */
CARD16 length B16;
Window window B32;
Cursor cursor B32;
} xXTestCompareCursorReq;
#define sz_xXTestCompareCursorReq 12
typedef struct {
BYTE type; /* X_Reply */
BOOL same;
CARD16 sequenceNumber B16;
CARD32 length B32;
CARD32 pad0 B32;
CARD32 pad1 B32;
CARD32 pad2 B32;
CARD32 pad3 B32;
CARD32 pad4 B32;
CARD32 pad5 B32;
} xXTestCompareCursorReply;
#define sz_xXTestCompareCursorReply 32
/* used only on the client side */
typedef struct {
CARD8 reqType; /* always XTestReqCode */
CARD8 xtReqType; /* always X_XTestFakeInput */
CARD16 length B16;
BYTE type;
BYTE detail;
CARD16 pad0 B16;
Time time B32;
Window root B32;
CARD32 pad1 B32;
CARD32 pad2 B32;
INT16 rootX B16, rootY B16;
CARD32 pad3 B32;
CARD32 pad4 B32;
} xXTestFakeInputReq;
#define sz_xXTestFakeInputReq 36
#undef Window CARD32
#undef Time CARD32
#undef Cursor CARD32