Cause of depth 16 color problem found

[Tommy Trussell]

On 9/29/05, Hans-Martin Mosner <hmm at heeg.de> wrote:
>
> When using 16 bit depth, MOL needs to convert from 555 format as used by
> the Mac to 565 format as used by X.
> It does this in the vs.blit_hook_pre function.
> After sending the converted bits to the X server, they are converted
> back to 555 format.
> However, when we use the shm extension, the bits in the buffer are
> converted back before the X server has processed them.
> I've added an XSync call in blit_rect() just before the
> vs.blit_hook_post() call, and that did the job.


I have noticed that the color map gets scrambled slightly when launching MOL
for the first time after starting an X session, but (being a non-programmer)
the best solution I have found is to invoke a screen saver. After the screen
saver has run and refreshed the X display the screen looks great and I can
start and stop MOL without scrambled colors.

Because I don't know anything about the code I don't understand why my
solution works at all, but it's also possible we're describing different
colormap distortions. I have been assuming the problem was with how I
initialized my fb device (I run a PowerBook G3 Series PDQ / Wallstreet II)
because I get video debug messages from the video in dmesg -- at least I do
under Ubuntu Hoary... I never saw any of these messages (and the video
scrambling was more sporadic) under Debian Sarge.

I apologize that I'm not at that machine right now so I can't say for
certain what color depth I use normally. Please let me know if what I'm
seeing is likely a different issue!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.terrasoftsolutions.com/pipermail/mol-general/attachments/20051001/815a56df/attachment.htm