[VW7.x][Linux/FVWM] Starting the image (solved)
Locked
[VW7.x][Linux/FVWM] Starting the image (solved)
 
|
Hello,
finally, we have solved our problem with starting the image on Linux. The problem is that any image is unable to start for the first time and sometimes even the second time. It just hangs and must be killed because it probably waits for some X event. We haven't read the VW X11 code throughoutly but it seems that the code around the _PPS_WIN_OFFSETS property is somehow messed up. We solved this by creating a little program (see attachment) that sets up the property on the root window accordingly to the WM configuration. This prevents VW from trying to play with the property and thus prevents the kaboom. We run this program after login into X and everyithing works just fine. However, this is not the final solution. We tried to fix the VW sources but we were unable to compile them because not all the makefiles are supplied. We know that this message fits better to vw-dev mailing list but we are not members of it. Nevertheless we believe it will find its way to the right hands. Martin Dvorak Ladislav Lenart #define WINDOW_X 2 #define WINDOW_Y 2 #define DIALOG_X 2 #define DIALOG_Y 2 #include <stdio.h> #include <sys/types.h> #include <X11/Xlib.h> #define vwwtNormal 2 #define vwwtApplicationModalDialog 4 #define maxVwWindowType 7 #define _PPS_WIN_OFFSETS "_PPS_WIN_OFFSETS" typedef struct { struct { int32_t mapping_offset_x; int32_t mapping_offset_y; int32_t configuration_offset_x; int32_t configuration_offset_y; } offsets[maxVwWindowType + 1]; } ppsWinOffsets; int main ( void ) { Display *display; Atom win_offsets_atom; ppsWinOffsets pps_win_offsets; int window_type_index; display = XOpenDisplay ( NULL ); win_offsets_atom = XInternAtom ( display, _PPS_WIN_OFFSETS, False ); for ( window_type_index = 0; window_type_index <= maxVwWindowType; window_type_index++ ) { pps_win_offsets.offsets[window_type_index].mapping_offset_x = 0; pps_win_offsets.offsets[window_type_index].mapping_offset_y = 0; pps_win_offsets.offsets[window_type_index].configuration_offset_x = 0; pps_win_offsets.offsets[window_type_index].configuration_offset_y = 0; } pps_win_offsets.offsets[vwwtNormal].mapping_offset_x = WINDOW_X; pps_win_offsets.offsets[vwwtNormal].mapping_offset_y = WINDOW_Y; pps_win_offsets.offsets[vwwtApplicationModalDialog].mapping_offset_x = DIALOG_X; pps_win_offsets.offsets[vwwtApplicationModalDialog].mapping_offset_y = DIALOG_Y; XChangeProperty(display, DefaultRootWindow(display), win_offsets_atom, win_offsets_atom, 32, PropModeReplace, (unsigned char *) &pps_win_offsets, (int) sizeof(ppsWinOffsets) / 4); XCloseDisplay ( display ); return 0; } Seeing that the repeatability hinges around XServer restarts I guess that it has to do with some state lingering in the XServer.Thank you for this great idea, this has been our start point for the investigation. The property _PPS_WIN_OFFSETS is set on root window and provides hints for any other VW image started later. However this smart cache seems of no use (too much code for too little benefit) as getting the decorations offsets (left top offset of the inner VW window) is quite fast and is cached within the VM globals. Talking of this feature of moving windows so that their decoration is visible, we have to admit we weren't able to get it working. We have tried to put 'visual*adjustWindowPositions:true' (and some other classes) into XRDB but with no visible effect (after evaluating aWindow moveTo: 0@0). How the resource should be set? Is there some way to set this option programatically from a running image? Playing with gdb for a while we have found that the image always hangs in mapWindow() (plat/x11Canvas.c) waiting for the MapNotify event. Strange thing in this method is that the window is first mapped and then the StructureNotifyMask is set so there's a possibility we can "miss" the event as it's not selected (thus hanging in XPeekIfEvent forever as gdb backtrace shows in all cases). But we're not X11 gurus to say that this can cause some malfunction. Furthermore, sometimes before the image hangs, a window gets quickly mapped and unmapped but this may not be relevant. We wanted to modify the code and get deeper into the problem but Cincom doesn't provide all the makefiles (at least for 7.3 VM, haven't tried 7.4 yet), namely makefiles/makefile.generic (and some others). However, this would cause problems anytime but we encounter only one or two hangs with first image and any image run later works fine - this makes some connection with the _PPS_WIN_OFFSETS property:
As far as we can see there's no black magic in finding the root window on a particular display and screen, DefaultWindow and DefaultScreen are used throughout the X11 code. Reading the X11 code we've found that it's quite ready for multiple displays open from one image (as Smalltalk/X provides). This makes me wonder why pdInitWindow() (plat/x11Win.c) terminates due to fatal error when opening new display. Propagating the error into higher level (Smalltak code) would make it more possible to open multiple displays. This needs hard work around 'Screen default' however. We'll give it a try but FVWM is an ICCCM (2.0) compliant window manager and there should be no problems with it. This may not be the only problem as on my previous hardware (upgraded from P3/650MHz to P4HT/3GHz) I had no problem with starting VW (with the same version of FVWM). WindowMaker works fine on three machines (so far), we don't use other window managers. Any ideas would be greatly appreciated. Martin Dvorak Ladislav Lenart
|
Re: [VW7.x][Linux/FVWM] Starting the image (solved)
|
|
We have just discovered that VW7.2 needs different values in _PPS_WIN_OFFSETS than VW7.3. This means that our program works only for VW7.3 (because we were studying vw7.3 sources), but not for VW7.2 (or any other version that uses different values). Furthemore, this bug means that each time we successfully start particular VW version, we will have trouble starting the other one (and so on and so forth). I can't help myself, but this is REALLY stupid. Could you please consider not using _PPS_WIN_OFFSETS property at all (it is really useless since it is used only once at image startup) and make us not that angry? Thanks, Ladislav Lenart Martin Dvořák wrote: Hello, finally, we have solved our problem with starting the image on Linux. The problem is that any image is unable to start for the first time and sometimes even the second time. It just hangs and must be killed because it probably waits for some X event. We haven't read the VW X11 code throughoutly but it seems that the code around the _PPS_WIN_OFFSETS property is somehow messed up. We solved this by creating a little program (see attachment) that sets up the property on the root window accordingly to the WM configuration. This prevents VW from trying to play with the property and thus prevents the kaboom. We run this program after login into X and everyithing works just fine. However, this is not the final solution. We tried to fix the VW sources but we were unable to compile them because not all the makefiles are supplied. We know that this message fits better to vw-dev mailing list but we are not members of it. Nevertheless we believe it will find its way to the right hands. Martin Dvorak Ladislav Lenart |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |