On Mon, 26 Mar 2001, Gavriel State wrote:
This patch fixes several issues with the way OpenGL manages visuals:
It always uses a double-buffered visual if one is available, even when not running Wine in --desktop mode. Previously, we just hoped that the default visual was double buffered, which is isn't in some DRI GL drivers.
It ensures that all colormaps created use the double-buffered visual if it exists. This prevents problems where DRI GL implementations fail to work unless the colormap visual matches the window visual matches the glX visual.
It gets around similar visual issue with the default GL context created for apps that don't create their own contexts before trying to use GL functions.
Note that we are not able to support the wgl ChoosePixelFormat/DescribePixelFormat APIs properly. Some of the infrastructure for this exists in graphics/x11drv/opengl.c so that it can be done when the time comes. This patch explicitly removes the wgl code that tries to match the OpenGL visual to a requested pixel format, because that won't work until we can dynamically remap HWNDs to new X11 Windows with a new visual.
-Gav
Something is not right, I think. Ordinary apps (Dmitry's About.exe, say) look as if they were using a vga16 server - unless the pointer is over the desktop: then the entire X display is black and white. Without a desktop with managed moving the pointer over the app's window radically changes the palette for the whole screen, but not to black and white. With neither managed nor desktop, the pointer has no effect on the palette.
No doubt I am not well set up for DGA:
grep -i dga config.cache ac_cv_header_X11_extensions_xf86dga_h=${ac_cv_header_X11_extensions_xf86dga_h=yes} ac_cv_lib_Xxf86dga_XDGAQueryExtension=${ac_cv_lib_Xxf86dga_XDGAQueryExtension=no} ac_cv_lib_Xxf86dga_XF86DGAQueryExtension=${ac_cv_lib_Xxf86dga_XF86DGAQueryExtension=yes}
but I don't see why DGA support should disturb things so.
I haven't really looked into it much yet...maybe you will see right off what you or I have done wrong?
Regards,
Lawson ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
lawson_whitney@juno.com wrote:
On Mon, 26 Mar 2001, Gavriel State wrote:
This patch fixes several issues with the way OpenGL manages visuals:
Something is not right, I think. Ordinary apps (Dmitry's About.exe, say) look as if they were using a vga16 server - unless the pointer is over the desktop: then the entire X display is black and white. Without a desktop with managed moving the pointer over the app's window radically changes the palette for the whole screen, but not to black and white. With neither managed nor desktop, the pointer has no effect on the palette.
Argh. I'm getting the same behaviour in 8-bit mode on my NVidia card. I don't remember getting it when testing the 3dfx card I just loaned out to someone. Maybe I flubbed the 8-bit testing there...
Can you tell me: - What video card you're using - What bit depth and resolution you've got - Whether the behaviour continues if you turn off the setup_opengl_visual() call in dlls/x11drv/x11drv_main.c - Whether notepad.exe exhibits the same behaviour (that's the only non game app I run on a regular basis for testing).
No doubt I am not well set up for DGA:
DGA shouldn't matter for this stuff at all.
I haven't really looked into it much yet...maybe you will see right off what you or I have done wrong?
At a guess - the privately created ColorMaps need to take their initial colors from the Default Color Map?
I'll try to have a further look into it tomorrow. Sorry for any wasted time.
-Gav
On Thu, 29 Mar 2001, Gavriel State wrote:
Argh. I'm getting the same behaviour in 8-bit mode on my NVidia card. I don't remember getting it when testing the 3dfx card I just loaned out to someone. Maybe I flubbed the 8-bit testing there...
Can you tell me:
- What video card you're using
(**) Mach64: Graphics device ID: "ATI Mach64 CT (264CT)"
- What bit depth and resolution you've got
(--) Mach64: PCI: Mach64 CT rev 9, Aperture @ 0xfe000000, Block I/O @ 0xfc00 (--) Mach64: Card type: PCI (--) Mach64: Memory type: DRAM (1) (--) Mach64: Clock type: Internal (--) Mach64: Maximum allowed dot-clock: 135.000 MHz (**) Mach64: Mode "640x480": mode clock = 45.800 (**) Mach64: Mode "800x600": mode clock = 69.650 (**) Mach64: Mode "1024x768": mode clock = 85.000 (**) Mach64: Mode "1280x1024": mode clock = 110.000 (--) Mach64: Virtual resolution: 1280x1024 (--) Mach64: Video RAM: 2048k (--) Mach64: Using hardware cursor (--) Mach64: Using 16 MB aperture @ 0xfe000000 (--) Mach64: Ramdac is Internal (--) Mach64: Ramdac speed: 135 MHz (--) Mach64: Using 8 bits per RGB value
What is bit depth? :-) can you tell from that? That is interesting. At 16 bpp, the symptoms I reported don't occur, and all is well. I guess you suspected that, but it didn't occur to me to check before. I might be the only wine user who habitually uses 8bpp: I can't see any difference between 8 and 16 bpp. Well, with your patch in I can.
- Whether the behaviour continues if you turn off the setup_opengl_visual() call in dlls/x11drv/x11drv_main.c
- Whether notepad.exe exhibits the same behaviour (that's the only non game app I run on a regular basis for testing).
No doubt I am not well set up for DGA:
DGA shouldn't matter for this stuff at all.
I haven't really looked into it much yet...maybe you will see right off what you or I have done wrong?
At a guess - the privately created ColorMaps need to take their initial colors from the Default Color Map?
I'll try to have a further look into it tomorrow. Sorry for any wasted time.
-Gav
-- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav@transgaming.com
I'll get on with some more tests now, but I want to give you that to start with.
Lawson ---cut here
Dammit, my winelib sendmail program won't work unless X is running. Try again. ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
On Thu, 29 Mar 2001, Gavriel State wrote:
Can you tell me:
- What video card you're using
- What bit depth and resolution you've got
- Whether the behaviour continues if you turn off the setup_opengl_visual() call in dlls/x11drv/x11drv_main.c
No. To be precise, I did exactly:
diff -ur /gp/gav/was/dlls/x11drv/x11drv_main.c dlls/x11drv/x11drv_main.c --- /gp/gav/was/dlls/x11drv/x11drv_main.c Wed Mar 28 22:31:00 2001 +++ dlls/x11drv/x11drv_main.c Thu Mar 29 10:23:03 2001 @@ -379,7 +379,8 @@
/* If OpenGL is available, change the default visual, etc as necessary */ #ifdef HAVE_OPENGL - setup_opengl_visual(); +/* setup_opengl_visual(); +*/ #endif /* HAVE_OPENGL */
/* tell the libX11 that we will do input method handling ourselves
and everything works fine.
- Whether notepad.exe exhibits the same behaviour (that's the only non game app I run on a regular basis for testing).
How about winemine?? (didn't have notepad.exe handy.) winemine does it, so does programs/notepad. I pulled a 1993 notepad.exe from a tar.bz2 - that would be from wfw3.11, I think.
It does it too.
At a guess - the privately created ColorMaps need to take their initial colors from the Default Color Map?
That sounds about right. Oh, at one point I reverted only wnd.c - no difference - then palette.c. Colors seemed better with the pointer off the window IIRC, but it still went to black and white withe the pointer on the desktop.
I'll try to have a further look into it tomorrow. Sorry for any wasted time.
-Gav
-- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav@transgaming.com
Lawson ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
lawson_whitney@juno.com wrote:
At a guess - the privately created ColorMaps need to take their initial colors from the Default Color Map?
That sounds about right. Oh, at one point I reverted only wnd.c - no difference - then palette.c. Colors seemed better with the pointer off the window IIRC, but it still went to black and white withe the pointer on the desktop.
Ok - this is what I'll explore further then. It may be a few more days before I can get to it though, since it looks like I'm going to be a daddy in a few hours. 8-)
-Gav
On Fri, 30 Mar 2001, Gavriel State wrote:
Ok - this is what I'll explore further then. It may be a few more days before I can get to it though, since it looks like I'm going to be a daddy in a few hours. 8-)
-Gav
Don't let me stop you. :-) I lived with local patches for about 3 months while file handles were getting sorted out, I guess I can give you a few days - hell, take a week if you need it. I just hope the wine-users don't catch us.
Lawson ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
lawson_whitney@juno.com wrote:
On Fri, 30 Mar 2001, Gavriel State wrote:
Ok - this is what I'll explore further then. It may be a few more days before I can get to it though, since it looks like I'm going to be a daddy in a few hours. 8-)
-Gav
Don't let me stop you. :-) I lived with local patches for about 3 months while file handles were getting sorted out, I guess I can give you a few days - hell, take a week if you need it. I just hope the wine-users don't catch us.
Ok - I just submitted a patch that takes care of this. Basically, since we're now using a private colormap even when doing 'shared' color, we have to copy the most important colors out of the default colormap to avoid colormap flashing. I chose 128, since it was the first power of 2 that let kdm's graduated-color title bars display properly. It's user-adjustable in the config file though ([x11drv]/CopyDefaultColors).
As far as the other thing goes, everything turned out very well. 8-)
-dad@aladara.com
On Sun, 15 Apr 2001, Gavriel State wrote:
Ok - I just submitted a patch that takes care of this. Basically, since we're now using a private colormap even when doing 'shared' color, we have to copy the most important colors out of the default colormap to avoid colormap flashing. I chose 128, since it was the first power of 2 that let kdm's graduated-color title bars display properly. It's user-adjustable in the config file though ([x11drv]/CopyDefaultColors).
AFAICT, it makes no difference. At 8 bpp, with the pointer on the wine desktop, the entire X display is black & white. With the pointer off the desktop, it still looks like it is run with a VGA16 server, well, maybe VGA32, if there were such a thing. I might have missed a patch in that flurry of msvcrt patches, but I don't think so. Maybe we barked up the wrong tree? At 16 bpp, all is well. I tried "CopyDefaultColors" = "256", but it didn't seem to make any difference.
As far as the other thing goes, everything turned out very well. 8-)
Good-oh.
-dad@aladara.com
-- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav@transgaming.com
Lawson ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
lawson_whitney@juno.com wrote:
AFAICT, it makes no difference. At 8 bpp, with the pointer on the wine desktop, the entire X display is black & white. With the pointer off the desktop, it still looks like it is run with a VGA16 server, well, maybe VGA32, if there were such a thing. I might have missed a patch in that flurry of msvcrt patches, but I don't think so. Maybe we barked up the wrong tree? At 16 bpp, all is well. I tried "CopyDefaultColors" = "256", but it didn't seem to make any difference.
Can you double-check that you applied the patch correctly? I was experiencing exactly the behaviour you describe on my system in 8-bit mode, and the patch (included again, just in case) does a good job of fixing it on my machine.
If this fix isn't the right one, I'm at a loss to explain what's going on.
-Gav
On Mon, 16 Apr 2001, Gavriel State wrote:
Can you double-check that you applied the patch correctly? I was experiencing exactly the behaviour you describe on my system in 8-bit mode, and the patch (included again, just in case) does a good job of fixing it on my machine.
If this fix isn't the right one, I'm at a loss to explain what's going on.
-Gav
I did do a make clean in all the x11drv's and make again, I didn't want to believe it either, and I looked at the source to make sure the patch applied, but I will check it all again tomorow. I think there may be some other fairly recent patch involved. I have been using 16 bpp lately because 8bpp looks like 5bpp even with the setup_opengl_visual comented out (I assumed that some other patch had changed that, but not so) - so something else is wrong. Also, with setup_opengl_visual active, I have critsect timeouts, and have a hard time to get the app to start at all.
Maybe the problem has to do with ./configure detects opengl, but it is not active. Maybe HAVE_OPENGL is the wrong test to decide if we should setup_opengl_visual, or maybe I am badly misconfigured (Andreas' winecheck thinks so, but that is mostly because I have no native registry) and it has taken y'all four years to catch me at it.
I hope I will be more helpful after I have slept on it.
Lawson
If you don't want my peaches, then don't shake my tree. ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
lawson_whitney@juno.com wrote:
On Mon, 16 Apr 2001, Gavriel State wrote:
Can you double-check that you applied the patch correctly? I was experiencing exactly the behaviour you describe on my system in 8-bit mode, and the patch (included again, just in case) does a good job of fixing it on my machine.
If this fix isn't the right one, I'm at a loss to explain what's going on.
-Gav
I did do a make clean in all the x11drv's and make again, I didn't want to believe it either, and I looked at the source to make sure the patch applied, but I will check it all again tomorow. I think there may be some other fairly recent patch involved. I have been using 16 bpp lately because 8bpp looks like 5bpp even with the setup_opengl_visual comented out (I assumed that some other patch had changed that, but not so) - so something else is wrong. Also, with setup_opengl_visual active, I have critsect timeouts, and have a hard time to get the app to start at all.
I'm not sure about this last problem - unless it's somehow that the X driver for your card flakes out when asked for a double-buffered visual in 8-bit mode.
I have however figured out the other problem. It's not that the code I added isn't working, it's that in desktop mode and non-managed mode, our colormap isn't being switched in. I thought that this could be because we're not setting the WM_COLORMAP_WINDOW property of our created windows, but a quick test of forcing it on in X11DRV_WND_CreateWindow was unable to fix the problem.
Does anyone else have any idea what the problem might be there? Is it the window manager's responsability to switch in the Colormap? If so, I guess that we need to do it ourselves for non-managed mode, but that doesn't explain why it isn't working in desktop mode.
-Gav
On Mon, 16 Apr 2001, Gavriel State wrote:
I'm not sure about this last problem - unless it's somehow that the X driver for your card flakes out when asked for a double-buffered visual in 8-bit mode.
I have however figured out the other problem. It's not that the code I added isn't working, it's that in desktop mode and non-managed mode, our colormap isn't being switched in. I thought that this could be because we're not setting the WM_COLORMAP_WINDOW property of our created windows, but a quick test of forcing it on in X11DRV_WND_CreateWindow was unable to fix the problem.
Does anyone else have any idea what the problem might be there? Is it the window manager's responsability to switch in the Colormap? If so, I guess that we need to do it ourselves for non-managed mode, but that doesn't explain why it isn't working in desktop mode.
-Gav
No, but I agree, I couldn't see from the trace that the fix was getting called in desktop mode. If I get rid of desktop and add managed, I am back to 8 bpp instead of what looks like 5 bpp. Strange.
Have I fallen off of wine-cvs, is it broken, or just inactive? Oops, cancel that question. Here it is now. :-)
Lawson ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
-
Gavriel State -
lawson_whitney＠juno.com