forked from opencode.energia.arti.ee/vt1200
arti
d8d54bb990
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).
81 lines
4.4 KiB
Plaintext
81 lines
4.4 KiB
Plaintext
THE XIE PROTOCOL SPECIFICATION WAS FOUND, WITH THE PHOTOFLO ELEMENT ENCODING.
|
|
|
|
Source (the same FTP mirror that yielded xieSIarch.txt):
|
|
https://ftp5.gwdg.de/pub/xfree86/XFree86/4.2.0/doc/
|
|
XIEProto.TXT 291988 bytes "X Image Extension Protocol", Version 5.02,
|
|
X11R6.3, Dec 1996, (c) DEC/X Consortium/AGE Logic
|
|
photoflo=343 photomap=132
|
|
xielib.TXT 297381 bytes photoflo=267 photomap=110
|
|
overview_xie.TXT 26659 bytes
|
|
Saved to xie/docs/dec/ (XIEProto.TXT, xielib.TXT, overview_xie.TXT).
|
|
NOTE: this is the document whose vocabulary matches the VT1200 (photoflo /
|
|
photomap). The X11R4 "contrib" specs already in xie/docs/x11r4/ have ZERO
|
|
photoflo hits -- they are a different lineage.
|
|
|
|
WHAT IT DEFINES (verbatim structures)
|
|
|
|
1. PhotoElement subpacket (a subpacket INSIDE a photoflo request, not a request):
|
|
2 bytes CARD16 Element type
|
|
2 bytes CARD16 Element length (bytes divided by 4)
|
|
multiple of 2 XieTyp(Phototag|Tile) element's data source(s), if required
|
|
N parameters as required by element type
|
|
< 4 pad to a multiple of 4
|
|
"A photo element consists of four (4) bytes of header followed by zero (0) or
|
|
more bytes of element input connection definitions and by ... additional data."
|
|
|
|
2. Element list / phototag rules (chapter 5):
|
|
- the protocol representation of a Photoflo IS a list of elements, sent as ONE
|
|
request; its total length must fit in maximum-request-length;
|
|
- each element is identified by its POSITION in the list = Phototag; the first
|
|
element is index ONE (1); phototag 0 is reserved;
|
|
- "the order of elements in the list does not have to match the Photoflo
|
|
topology ... the source for each element's input connections are explicitly
|
|
specified using the Phototags of upstream elements";
|
|
- three element kinds: Import (no inputs, 1 output), Process (>=1 input, 1
|
|
output), Export (1 input, no output). A useful Photoflo has >=1 import and
|
|
>=1 export.
|
|
|
|
3. Request encodings (v5.02 minor numbers):
|
|
CreatePhotoflo minor 17 length 3+n/4
|
|
photoflo(4) | CARD16 #elements | 2 unused | element-list
|
|
ExecuteImmediate minor 16 length 4+n/4
|
|
Executable(8) | CARD16 #elements | BOOL notify | 1 unused | element-list
|
|
ExecutePhotoflo minor 19 length 3
|
|
photoflo(4) | BOOL notify | 3 unused
|
|
ModifyPhotoflo minor 20 ; RedefinePhotoflo minor 21 ;
|
|
DestroyPhotoflo minor 18
|
|
PutClientData minor 22 (client -> ImportClient element; phototag + band)
|
|
GetClientData minor 23
|
|
And: "CreatePhotoflo ... no action is taken to validate them at that time.
|
|
CreatePhotoflo will only STORE the Photoflo's definition; parameter validation
|
|
is delayed until an execute request is received."
|
|
|
|
4. Photomap (7.2.3 / XieTypPhotomap): the resource that stores image data;
|
|
ImportPhotomap brings it into a flo, ExportPhotomap re-populates it.
|
|
|
|
MEASURED AGAINST THE VT1200 THIS TURN
|
|
|
|
slot 18 is the only handler whose length gate is a MINIMUM (>=4) and it reads
|
|
w0 (0x20) plus request BYTE 13 (0x68) -- that is exactly the shape of
|
|
CreatePhotoflo (photoflo id in w0; the element-type CARD16 of the first
|
|
element straddles bytes 12-13). But the v5.02 numbering does not hold:
|
|
slot18 with a NEW id + 3 header-only elements
|
|
[FLO, 3, 0x00010001, 0x00010002, 0x00010003] (len = 6 words)
|
|
-> err14 (BadIDChoice) bad = the new id, and NOTHING registers
|
|
So on this server slot 18 operates on an EXISTING resource, i.e. it is a
|
|
modify/execute-family request, not CreatePhotoflo. (Earlier: an existing
|
|
class-2 resource and an existing class-1 photoflo both gave BadAccess(10).)
|
|
|
|
The shared lookup's BadAccess site was also read exactly:
|
|
6BAB2 A7 = *A13(0xff20) ; JRLT 0x6BABC
|
|
6BAB8 A7 = *A11 ; JRNE 0x6BAEA ; value != 0 -> gate path
|
|
6BABC A7 = *A13(0xff20) ; JRLT 0x6BBCE ; < 0 -> skip
|
|
6BAC6 MOVK 0xa -> BadAccess ; only when >=0 AND *A11 == 0
|
|
i.e. BadAccess requires the caller-supplied signed local at frame 0xff20 to be
|
|
>= 0 while the dereferenced caller pointer holds 0.
|
|
|
|
STATUS. No client-chosen XIE image. src_base (rp+0x610) 0 in every run, the
|
|
window never differs from the no-export baseline, and xshow (core X) is still the
|
|
only viewer that has displayed an image. What changed: the element wire format is
|
|
now READ rather than guessed.
|