Open Shared Memory and Render Pictures

[Michael Titke]

My misunderstanding of mystical prepadding, missing request encoding 
titles (go find the opcode in the header files) and silenced core 
requests during the x keyboard adventure may have drained my capability 
to just "intuit" the right thing (mt).

For now we have a window (!!!) with keyboard events and characters or 
symbols (!!!) and a system V shared memory segment with a puttable image 
pixmap (!!!) which shows some severe flaw of the original matrix. Yes, 
that was me, I guess.

That Bad Access was a missing depth argument in the product? Thus the 
byte size of the pixmap was too small which usually results in a. ...  
Was that bits-per-pixel or minimum scanline unit? That's part of the 
following clean-up stage then. (Do formats really have a one byte id in 
XSHM or is that list of formats reversed in xcons?)

Thank you for your support here and there then.



On 05/08/2016 18:38, Ilya Anfimov wrote:
> On Fri, Aug 05, 2016 at 02:53:06PM +0200, Michael Titke wrote:
>
> [skipped]
>
>> I'm just asking because solving a puzzle is funny but maybe someone still
>> knows about those "private" protocol "mechanics".
>   All of that protocol mechanics is described in the X Window Sys-
> tem Protocol X Consortium Standard.
>   Any your misunderstanding means that you misread  some  part  of
> that book.
>   There  is  no other possibilities with the CORE at your level of
> confidence with the protocol.
>
> _______________________________________________
> xorg at lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2016-08-05 20:37:34.png
Type: image/png
Size: 226401 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg/attachments/20160805/28556600/attachment-0001.png>