forked from arti/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).
110 lines
4.3 KiB
Plaintext
110 lines
4.3 KiB
Plaintext
...\" This manpage source uses rsml coding.
|
|
.so /usr/share/lib/tmac/sml
|
|
.so /usr/share/lib/tmac/rsml
|
|
...\"
|
|
...\" *********************************************************************
|
|
...\" * *
|
|
...\" * Copyright (c) Digital Equipment Corporation, 1992 *
|
|
...\" * *
|
|
...\" * All Rights Reserved. *
|
|
...\" * *
|
|
...\" *********************************************************************
|
|
.TH XieQueryExport 3X "" "" "" "Digital" ""
|
|
...\" MANDOC->Begin OVERVIEW
|
|
.SH NAME
|
|
XieQueryExport \- This routine returns the LUT and a list of allocated color cells,
|
|
if any, that were used during the export of an image.
|
|
...\" MANDOC->End OVERVIEW
|
|
...\" MANDOC->Begin FORMAT
|
|
.SH C Format
|
|
\fI\fPXieQueryExport\fI(pho_id, lut_id_ret, pxl_lst_ret, pxl_cnt_ret)\fP
|
|
...\" MANDOC->End FORMAT
|
|
...\" MANDOC->Begin TEMPLATE_PARA
|
|
.SH C Argument Information
|
|
...\" MANDOC->Begin CODE_EXAMPLE
|
|
.oS
|
|
XiePhoto pho_id;
|
|
XiePhotomap *lut_id_ret;
|
|
unsigned long **pxl_lst_ret;
|
|
unsigned long *pxl_cnt_ret;
|
|
.oE
|
|
...\" MANDOC->End CODE_EXAMPLE
|
|
...\" MANDOC->End TEMPLATE_PARA
|
|
...\" MANDOC->VMS-specific, only valid keyword: HEADONLY
|
|
.SH RETURN VALUES
|
|
...\" MANDOC->Begin RETTEXT
|
|
None.
|
|
...\" MANDOC->End RETTEXT
|
|
...\" MANDOC->Begin PARAMDEFLIST
|
|
.SH PARAMETERS
|
|
.IP "pho_id" 20
|
|
The \fIpho_id\fP argument specifies the identifier of
|
|
the server image from which you want to obtain the ExportContext.
|
|
The image can be an unbound photomap, a photoflo, a bound photomap,
|
|
or a phototap. The photoflo is specified explicitly if the image is
|
|
a photoflo, or implicitly if the image is a bound photomap or phototap.
|
|
If the image is bound to a photoflo, the photoflo execution
|
|
must be complete or the routine returns a BadAccess error.
|
|
.IP "lut_id_ret" 20
|
|
The \fIlut_id_ret\fP argument specifies the address of
|
|
the location to which the routine returns the export LUT photomap identifier.
|
|
If the ExportContext is not using a LUT, the routine returns
|
|
a null. You can free the LUT photomap using the XieFreeResource routine.
|
|
.IP "pxl_lst_ret" 20
|
|
The \fIpxl_lst_ret\fP argument specifies the address of
|
|
the location to which the routine returns the pointer to the list of
|
|
allocated pixels. If you specify a null for either the
|
|
\fIpxl_lst_ret\fP or the \fIpxl_cnt_ret\fP argument, the
|
|
routine does not return a pixel list
|
|
and all allocated pixels remain the property of the
|
|
ExportContext. If the routine returns a pixel list, the list is removed
|
|
from the ExportContext and the application is responsible for
|
|
freeing the list using the XieFree routine.
|
|
.IP "pxl_cnt_ret" 20
|
|
The \fIpxl_cnt_ret\fP argument specifies the address of the
|
|
location to which the routine returns the count of the allocated pixels.
|
|
If you do not want a pixel list and a count of the allocated pixels,
|
|
set this argument to null.
|
|
...\" MANDOC->End PARAMDEFLIST
|
|
...\" MANDOC->Begin DESCRIPTION
|
|
.SH DESCRIPTION
|
|
This routine returns the LUT identifier and a list of allocated color cells,
|
|
if any, that were used during the export of an image. The LUT could have
|
|
been supplied by the application or generated by an XIE routine.
|
|
The application is responsible for freeing the allocated pixels using
|
|
the XFreeColors routine. For example:
|
|
...\" MANDOC->Begin CODE_EXAMPLE
|
|
.oS
|
|
XieExport( photo_id, window, gc, 0,0, 0,0, 100, 100, 0,
|
|
colormap, 0.0,0.0);
|
|
.
|
|
XieQueryExport( photo_id, &lut_id, &pixel_list, &pixel_count );
|
|
.
|
|
XieExport( photo_id, window, gc, 0,0, 0,0, 100, 100, lut_id,
|
|
colormap, 0.0,0.0);
|
|
.
|
|
XFreeColors( display, colormap, pixel_list, pixel_count, 0 );
|
|
pixel_list = XieFree( pixel_list );
|
|
lut_id = XieFreeResource( lut_id );
|
|
.oE
|
|
...\" MANDOC->End CODE_EXAMPLE
|
|
...\" MANDOC->End DESCRIPTION
|
|
...\" MANDOC->Begin TEMPLATE_PARA
|
|
.SH XIE Events and Error Messages
|
|
.PP
|
|
\fBProtocol Messages:\fP X_ieQueryExport
|
|
.PP
|
|
\fBXIE event returned:\fP None
|
|
.PP
|
|
\fBXieLib errors:\fP Reply error, BadLength
|
|
.PP
|
|
\fBXieServer errors:\fP BadIDChoice -- Invalid identifier
|
|
.PP
|
|
BadAlloc -- Insufficient server resources
|
|
.PP
|
|
BadAccess -- The photoflo is running
|
|
...\" MANDOC->End TEMPLATE_PARA
|
|
...\"
|
|
...\" This source file has been processed by the osf_build_manpages
|
|
...\" script. Contact dlibrary@ravine if you need more information.
|