> oh, nice bug you have there, what's the screen depth when that > happens?
I feel stupid - how do I check screen depth? ehm... I added xdpyinfo output at the end. anyway, the main issue is not screen depth. (ok. I see somewhat different colors for the twm bars between parallels and drawterm, using same twm. this might be creen depth related) the main issue could very well be an issue in parallels. it has something to do, not with when equis is started, but with when a window is created in rio - whether parallels is running full screen, or in a big window (screen-sized) with top-left corner not at top-left of display. when I run full-screen parallels, create a rio window there, start equis, all works fine. http://plan9.cs.utwente.nl/equis-parls2.png when I have screen-sized parallels window running as window among other mac windows, with top-left corner somewhere in the middle of the screen, then create rio window and start equis I get the slanted stuff. I tried various times, and the issue is indeed about the situation at the moment the rio window is created. that situation seems to be rembered as part of the rio window: once a rio window is created 'the wrong way', it does not help to make the parallels window full-screen before starting equis. it might be possible to see the difference in properties of the created rio window, if I would known where to look. when I put the parallels window non-full screen, but with left border at left border of display, then create a rio window, then make it full screen again and start equis it worked fine too. when I move the parallels window to the right, create a rio window, go full screen and start equis I get the slanted lines. conclusion: somehow the horizontal offset between left corner of parallels window and left corner of display confuses parallels, or plan 9, or the combination. also, with the parallels window left-top corner in the middle of the display, as soon as the fat plan 9 mouse cursor hits the bottom of the display (or the off-screen bottom of the parallels window?) a second small mouse cursor (the mac one) appears, with an offset from the fat plan 9 one. which one is leftmost depends on the horizontal position of the plan 9 cursor when it hits the bottom (of display or parallels window, I don't know) the second cursor disappears again either when it is the first to go beyond the top or left border of the parallels window, or when the plan 9 cursor hits such border first, then further mouse movement pushes the mac mouse cursor to the plan 9 one till they coincide and the mac mouse cursor disappears. there is also some interaction with stuff in the dock. when I see the two mouse cursors and they go low enough the dock that was hidden at the bottom of the display unhides. If I only see one mouse cursor that does not happen. ===== drawterm ========================================= bash-3.2$ name of display: slurp:0.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 6600 X.Org version: 0.0.6.600 maximum request size: 262140 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 5 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 24, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x60000a, revert to PointerRoot number of extensions: 4 RENDER SHAPE X-Resource XInputExtension default screen number: 0 number of screens: 1 screen #0: print screen: no dimensions: 837x575 pixels (212x146 millimeters) resolution: 100x100 dots per inch depths (6): 1, 8, 16, 24, 32, 32 root window id: 0x35 depth of root window: 32 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 2048 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 837x575 current input event mask: 0xd0001d KeyPressMask ButtonPressMask ButtonReleaseMask EnterWindowMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals: 1 default visual id: 0x21 visual: visual id: 0x21 class: TrueColor depth: 32 planes available colormap entries: 2048 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits ================================================== ===== parallels =============================== name of display: 10.211.55.3:0.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 6600 X.Org version: 0.0.6.600 maximum request size: 262140 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 5 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 24, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: PointerRoot number of extensions: 4 RENDER SHAPE X-Resource XInputExtension default screen number: 0 number of screens: 1 screen #0: print screen: no dimensions: 604x494 pixels (153x125 millimeters) resolution: 100x100 dots per inch depths (6): 1, 8, 16, 24, 32, 16 root window id: 0x35 depth of root window: 16 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 64 preallocated pixels: black 0, white 65535 options: backing-store NO, save-unders NO largest cursor: 604x494 current input event mask: 0x0 number of visuals: 1 default visual id: 0x21 visual: visual id: 0x21 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 8 bits =====================================================
