Internal-wm/rootless observations

Alexander Gottwald
Wed Dec 1 18:14:00 GMT 2004

On Wed, 1 Dec 2004, Torrey Lyons wrote:

> I have been away on a long Thanksgiving vacation so I've been slow to 
> respond.

No problem. I'm hunting this for some weeks already

> In any case, the 16 bpp modes are problematic but I believe 
> we solved issues with them in the rootless code awhile back. The 
> fundamental problem is that fb assumes screens are always 32-bit 
> aligned. Thus you if a window's pixmap is not 32-bit aligned, fb 
> assumes it can still access the word before the start of a drawable's 
> data. In rootless mode, where windows are located higgledy-piggledy 
> in memory, this is not true.
> Rootless solves (or attempts to solve) this problem with the 
> SetPixmapBaseToScreen() macro in rootlessCommon.h. The idea is that 
> the unaligned window's pixmap is moved backwards in memory to align 
> it and then a positive offset it given to fb to indicate where the 
> window resides in the pixmap.
> If there is an edge case where rootless does not work in 16-bits it 
> would be good to track down. This mode is sometimes used on Mac OS X.

Maybe the odd window width is the problem.

Testcase: xterm width 501 pixel

setting the with to 502 pixel in the debugger solved the distorted

assuming the base was 0x2b00000.
After the window was translated by (0,5) the pixmap base was moved
by 5 * 1002 bytes. In the fb drawing functions the offset was never
correct to 0x2b00000. It was still below that value and the access 
an access violation.

I had problems with fbCopyNtoN and fbBlt. 

SetPixmapBaseToScreen does: 
ptr = 0x2b00000 - 5 * 1002 = 0x2afec6e
This is unaligned -> fixing this
ptr = 0x2afec6e - 2 = 0x2afec6c

fbCopyNtoN does dst + (pbox->y1 + dstYoff) * dstStride
so this is 

0x2afec6c + (0 + 5) * 1002 = 0x2affffe -> unaligned and _off pixmap_

--           ICQ: 126018723

More information about the Cygwin-xfree mailing list