http://bugs.winehq.org/show_bug.cgi?id=11203
Summary: Versions 9.52 & 9.53 throw page exception on Enterprise Architect Product: Wine Version: 0.9.52. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: igoddard@nildram.co.uk
Created an attachment (id=10271) --> (http://bugs.winehq.org/attachment.cgi?id=10271) traces for errors under 9.52&3 and normal operation under 9.51
Enterprise Architect is a UML package from www.sparxsystems.com.au I'm running V6.5.806. It works fine under Wine in many versions including 9.51. In 9.52 & 9.53 it throws a page exception. See attached traces (including a trace for normal operation under 9.51)
http://bugs.winehq.org/show_bug.cgi?id=11203
Jeff Zaroyko jeffzaroyko@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeffzaroyko@gmail.com
--- Comment #1 from Jeff Zaroyko jeffzaroyko@gmail.com 2008-01-15 07:45:43 --- Hi Ian
If you can compile from source, please attempt Regression testing as described here http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #2 from Luke Bratch l_bratch@yahoo.co.uk 2008-01-15 12:31:38 --- Ian, please post in Bugzilla, don't reply to wine-bugs. Email read:
"OK, Jeff. I'm setting that up now.
Ian"
http://bugs.winehq.org/show_bug.cgi?id=11203
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com URL| |http://www.sparxsystems.com. | |au/products/ea_downloads.htm | |l Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=11203
Ian Goddard igoddard@nildram.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #3 from Ian Goddard igoddard@nildram.co.uk 2008-01-15 13:10:09 --- Created an attachment (id=10281) --> (http://bugs.winehq.org/attachment.cgi?id=10281) Result of regression test
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #4 from Dan Kegel dank@kegel.com 2008-01-15 13:31:33 --- Thanks! No need to attach those. Here it is inline:
commit 5461d505d727411f8de3f7846c5d1e8ed6343247 Author: Stefan Dösinger stefan@codeweavers.com Date: Fri Dec 14 00:39:34 2007 +0100
winex11: Activate the depth-bpp difference.
http://bugs.winehq.org/show_bug.cgi?id=11203
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #5 from Stefan Dösinger stefandoesinger@gmx.at 2008-01-15 13:47:46 --- At which depth do you run your X server?
http://bugs.winehq.org/show_bug.cgi?id=11203
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com
http://bugs.winehq.org/show_bug.cgi?id=11203
Ian Goddard igoddard@nildram.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |igoddard@nildram.co.uk
--- Comment #6 from Ian Goddard igoddard@nildram.co.uk 2008-01-15 16:42:22 --- (In reply to comment #5)
At which depth do you run your X server?
24
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #7 from Stefan Dösinger stefandoesinger@gmx.at 2008-01-15 16:48:43 --- What card do you have? Does it use a 32 bit framebuffer(at depth 24), or a 24 bit framebuffer?
what happens if you replace the screen_bpp = 32; line with screen_bpp = 24; ?
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #8 from Ian Goddard igoddard@nildram.co.uk 2008-01-15 18:33:27 --- (In reply to comment #7)
What card do you have? Does it use a 32 bit framebuffer(at depth 24), or a 24 bit framebuffer?
This is a laptop so no separate card but uses i810 chipset. According to the datasheet on the Intel site this is 24-bit max.
what happens if you replace the screen_bpp = 32; line with screen_bpp = 24; ?
That does the trick!
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #9 from Stefan Dösinger stefandoesinger@gmx.at 2008-01-16 01:10:32 --- Do you have Windows installed on that machine? Does it offer 32 bpp there?
Maybe we just need a better detection of the real framebuffer depth, and hardcoding 24 -> 32 isn't enough.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #10 from Ian Goddard igoddard@nildram.co.uk 2008-01-16 16:02:01 --- (In reply to comment #9)
Do you have Windows installed on that machine? Does it offer 32 bpp there?
Not currently. I had NT4 installed under Virtualbox at one time and EA ran OK on that. OTOH it ran OK on Wine up to 0.9.51
Maybe we just need a better detection of the real framebuffer depth, and hardcoding 24 -> 32 isn't enough.
It seems that way. If you come up with any changes you want to try please let me know.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #11 from Ian Goddard igoddard@nildram.co.uk 2008-01-18 06:41:18 --- (In reply to comment #9)
Maybe we just need a better detection of the real framebuffer depth, and hardcoding 24 -> 32 isn't enough.
I tried the following:
In x11drv_main.c I verified that X11DRV_setup_opengl_visual() was being called before the switch.
I added a 32-bit case to the switch so that screen_bpp would be set to 24 or 32 as appropriate.
In opengl.c I added 32-bit options to the start of the visualProperties array in X11DRV_setup_opengl_visual()
The result of this is that it correctly identifies the 24-bit server but I have no way of knowing whether it would correctly identify a 32-bit server nor whether the opengl.c changes might cause problems on other hardware.
However a second bug is exposed. If 24 bits are set, either by simply hacking the 24-bit switch as per the earlier comment or by the amendments I've just described, text in some dialogs is invisible. I'll try running regression tests to determine whether this shows up in an earlier patch.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #12 from Ian Goddard igoddard@nildram.co.uk 2008-01-18 09:07:54 --- (In reply to comment #11)
However a second bug is exposed. If 24 bits are set, either by simply hacking the 24-bit switch as per the earlier comment or by the amendments I've just described, text in some dialogs is invisible. I'll try running regression tests to determine whether this shows up in an earlier patch.
This is weird. Every test back to the first patch after 0.9.51 threw up the invisible text bug and the description of the first patch doesn't seem a likely source of the bug. I then checked out 9.51 (which is what I have installed as the working version from a .deb download from winehq) and built that. The locally built version shows the problem, the installed version doesn't. It appears that the invisible text is an artefact of my local build environment.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #13 from Dan Kegel dank@kegel.com 2008-01-18 10:23:09 --- What does grep X11 include/config.h show on your build system? It should not show any commented out defines.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #14 from Ian Goddard igoddard@nildram.co.uk 2008-01-18 14:54:16 --- (In reply to comment #13)
What does grep X11 include/config.h show on your build system? It should not show any commented out defines.
None commented out. Stefan asked in a PM if fontforge is installed. It is.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #15 from Dan Kegel dank@kegel.com 2008-01-18 16:10:08 --- For completeness, what version of fontforge is installed?
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #16 from Ian Goddard igoddard@nildram.co.uk 2008-01-18 17:25:05 --- (In reply to comment #15)
For completeness, what version of fontforge is installed?
fontforge -version fontforge: /opt/mono-1.2.4/lib/libpng12.so.0: no version information available (required by /usr/lib/libgdraw.so.1) Copyright (c) 2000-2005 by George Williams. Executable based on sources from 12:08 5-Dec-2005. fontforge 20051205
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #17 from Dan Kegel dank@kegel.com 2008-01-18 17:30:30 --- That version's too old. You have to install a fresh one from source (or possibly from testing or unstable?). http://wiki.winehq.org/Recommended_Packages mentions this but doesn't make it clear.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #18 from Ian Goddard igoddard@nildram.co.uk 2008-01-19 03:46:37 --- (In reply to comment #17)
That version's too old. You have to install a fresh one from source (or possibly from testing or unstable?). http://wiki.winehq.org/Recommended_Packages mentions this but doesn't make it clear.
Thanks. That provides a rational explanation of my local compilation issue.
Unfortunately even the Etch release of fontforge quibbles about library versions let alone testing or unstable. As I'm working with my everyday laptop and not a crash-and-burn box I'm not inclined to go down the route of installing more and more non-distro versions of libraries (fixing what isn't otherwise broken) to try building a working Wine from scratch. So...
The original bug has been identified. Irrespective of whether the solution I proposed is the correct one I'm sure that a future Wine release will incorporate a fix. The apparent second bug appears to be an artefact. Until such a release comes along 0.9.51 works and the only negative aspect of leaving the box as it is with that version installed is being nagged about an available upgrade. I can live with that.
Thanks to all for their help.
http://bugs.winehq.org/show_bug.cgi?id=11203
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2008-05-28 09:25:55 --- *** Bug 13510 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11203
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=11203
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dpblnt@gmail.com
--- Comment #21 from Austin English austinenglish@gmail.com 2008-09-29 14:29:32 --- *** Bug 11785 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11203
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@chrobis.com
--- Comment #22 from Austin English austinenglish@gmail.com 2008-09-29 14:30:15 --- *** Bug 12174 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11203
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine.dev@web.de
--- Comment #23 from Austin English austinenglish@gmail.com 2008-09-29 14:30:46 --- *** Bug 13663 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #24 from Ian Goddard igoddard@nildram.co.uk 2008-09-29 17:38:29 --- I have the same problem on both my laptop and a Via thin client. I now take each release from git, build it and run the test suite (igoddard_laptop) and check that the problem still exists with EA. I then make a one line change and install it (no more fontforge problems nowadays!). I ran the test suite on one of these rebuilds. It fixed a whole bunch of test failures.
On the face of it the code could be greatly simplified by reducing the switch at about line 300 of x11drv_main.c to return 16 on case 15, return depth on all the other existing cases and leave the default in place.
However, the comment about opengl is a worry - if this were done would it break opengl apps which could use a 32-bit depth from some H/W which reports 24? This is why I haven't submitted a patch. If the test suite tests for such opengl cases maybe it would be possible to put some such fix into a dev release and be prepared to back it out with the intent of putting something better in place if it does break tests.
Ian
http://bugs.winehq.org/show_bug.cgi?id=11203
higuita higuita@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |higuita@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #25 from Ian Goddard igoddard@nildram.co.uk 2008-12-14 07:26:57 --- Created an attachment (id=17920) --> (http://bugs.winehq.org/attachment.cgi?id=17920) Minimal patch to fix
In response to Austin English's request in WWW 354 this bug is still present in 1.1.10 and is, as far as I can tell, responsible for most if not all the visual failures for igoddard-laptop in winetest.
I've attached a minimal patch which works for me. The existing code contains this comment, however:
"This is not necessarily right. X11 always has 24 bits per pixel, but it can run with 24 bit framebuffers and 32 bit framebuffers. It doesn't make any difference for windowing, but gl applications can get visuals with alpha channels. So we should check the framebuffer and/or opengl formats available to find out what the framebuffer actually does"
So maybe there could be issues with other H/W if the patch is applied.
When the patch is applied the Enterprise Architect starts up OK but in doing so returns this message:
err:x11drv:X11DRV_CreateBitmap Trying to make bitmap with planes=1, bpp=32
As the "error" being reported is non-fatal I wonder if it is significant or whether the message could be removed.
Ian
http://bugs.winehq.org/show_bug.cgi?id=11203
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=11203
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #26 from Ken Sharp kennybobs@o2.co.uk 2009-08-14 12:18:15 --- Confirming in Acorbat Reader 3 16-bit.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #27 from Stefan Dösinger stefandoesinger@gmx.at 2009-08-14 15:33:03 --- Is the problem with those apps that the apps don't like 32 bpp, or that the X server has a 24 bit framebuffer?
Wrt 16 bit apps I can imagine that Windows 3.x never had 32 bpp support, so the apps don't expect this. Maybe we have to fix this value up in the Win32<->Win16 thunks. A 16 bit test case run under WinXP with a 32 bpp depth could shed some light.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #28 from Stefan Dösinger stefandoesinger@gmx.at 2009-08-14 15:35:49 --- (In reply to comment #27)
A 16 bit test case run under WinXP with a 32 bpp depth could shed some light.
What I mean with this is a Win16 test app that reads the depth on a 32 bit Windows running in 32 bpp color depth.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #29 from Ian Goddard igoddard@nildram.co.uk 2009-08-14 16:11:20 --- (In reply to comment #27)
Is the problem with those apps that the apps don't like 32 bpp, or that the X server has a 24 bit framebuffer?
The problem is with X servers which have 24 bit buffers encountering apps that try to use 32.
The problem code assumes that if a 24 bit buffer is reported it can really handle 32 anyway and sets the depth to 32. When the app sends a 32 bit bitmap a fault is thrown as per my original trace. If the code is changed to set the depth to 24 as reported (see my minimal patch) then an error is reported to the console (see comment #25) but the app runs (at least EA does and so does an app reported in a duplicate bug).
I now run the patched version with no problems but it may well be that there is some server out there which will meet the original assumption in the code and lose some functionality if the patch is applied. See the comment in the code which I quoted in comment #25.
The patch does cure a number of errors which used to come up regularly in winetest (igoddard-laptop was my ID). Unfortunately it's some time since I ran winetest as, some months ago, it started hanging my laptop so that I couldn't get through to the point were results were reported.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #30 from Stefan Dösinger stefandoesinger@gmx.at 2009-08-14 17:33:02 --- The thing is, you can't use 32 bpp pixmaps etc on X11. Its all 24 bit, there's also no alpha except in very few situations(that's partially why we need a DIB engine)
If there's any attempt to create a 32 bit X object we probably have to request a 24 bit one instead. Or that's how I understand it at least.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #31 from Ian Goddard igoddard@nildram.co.uk 2009-08-14 18:42:08 --- (In reply to comment #30)
The thing is, you can't use 32 bpp pixmaps etc on X11. Its all 24 bit, there's also no alpha except in very few situations(that's partially why we need a DIB engine)
If there's any attempt to create a 32 bit X object we probably have to request a 24 bit one instead. Or that's how I understand it at least.
In that case there seems to be no value in retaining the code which rewrites the depth.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #32 from Stefan Dösinger stefandoesinger@gmx.at 2009-08-15 01:25:24 --- Sure - pretty much every modern game needs 32 bpp, and many check that and refuse to start if we report 24.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #33 from Ian Goddard igoddard@nildram.co.uk 2009-08-15 13:04:19 --- (In reply to comment #32)
Sure - pretty much every modern game needs 32 bpp, and many check that and refuse to start if we report 24.
This gets odder & odder. X only supports 24 but we tell the app that we support 32 anyway because the app may want it. So how is the 32 bpp app expected to be handled by 24 bpp X? Or does the app, having made sure 32 is available, only send 24 bpp pixmaps?
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #34 from Stefan Dösinger stefandoesinger@gmx.at 2009-08-15 14:53:52 --- 32 bpp == 24 bits color information + 8 byte padding. There's a difference between color depth and framebuffer size on X. Windows doesn't properly separate them. This is where all this confusion comes from, and even I don't get it right all the time.
GDI objects always have at most 8 bits per channel color information. However, since 3 byte aligned data is hard to manage, graphics cards usually pad the information to 4 bytes, adding 8 junk bits. The size of the image grows, the data it stores doesn't. You can essentially see this as a tradeoff of comparably cheap video memory(you don't need more than 4-8 MB for GDI really) for faster processing.
X usually writes this during startup: (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
That means that there are 24 bits color depth, and a pixel takes 32 bits. 8 bits are unused. This setup is known on Windows as "32 bpp". This line is driver specific, so the Intel driver might write something different.
The reason why games usually check for 32 bpp is:
*) Because they're stupid and don't know what they're doing *) OpenGL and D3D can use the 8 fill bytes for backbuffer alpha, allowing additional blend modes. There are better ways to check for support for that, so it comes down to "games are stupid" again.
The D3D formats have a nicer representation:
D3DFMT_R5G6B5: Usually known as 16 bpp D3DFMT_R8G8B8: This is packed RGB8, known as 24 bpp. Very few cards support it these days for framebuffers, and no card I know supports it for textures. D3DFMT_X8R8G8B8: This is known as 32 bpp. It contains the same information as the former format, and 8 unused filler bits D3DFMT_A8R8G8B8: This isn't available in GDI - it uses the 8 filler bits for alpha storage. However, the back buffer can be in this format. The front buffer is always in X8R8G8B8 format. If the back buffer is presented, the alpha data is copied over(simple memcpy in the GPU, or just a pointer change for a flip), and the A channel becomes an X channel and is just ignored.
On newer cards(d3d10 class) there is also this: D3DFMT_A2R10G10B10: Also a 32 bpp mode, 30 bits color information - just interesting for D3D, not too interesting for GDI. This format can be used for back buffers I think, but usually it is used for temporary results that need higher precision. Afaik monitors are still in 24 bit color depth mode, which was once considered more than the human eye can see - although not everyone agrees with that.
But the 24->32 bit patch was mostly about making wine separate the two elements in this line: (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
Advertise this as 32 bpp to the app, and use 24 bit depth for X11 objects. Its up to X11 how to store it - it will usually store it as 24+8, and I think shared memory access can talk that way, but I am not 100% sure about this. Wine has conversion functions, although that tends to slow things down.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #35 from Ian Goddard igoddard@nildram.co.uk 2009-08-16 03:41:44 --- (In reply to comment #34) Thanks for that explanation, Stefan. I think I've got a better feeling for what's happening.
If Wine reports 24bpp as per my mod this app still tries to use 32bpp but there's a check made elsewhere which reports a non-fatal error. Presumably there is further code down the line which is then able to ignore the padding. Maybe there's scope here for reporting back 32bpp for those apps that want to see it but using 24 internally.
I'll take a look to see if there's something obvious that can be done. Unfortunately it would need to be simple because it's years since I did much C & even then it was app rather than system programming ;-)
Since my last post I've had another look at Winetest & I now find that I don't have to reach for the power-switch. I did find myself staring at a hung screen but this time the keyboard was still working so I could log in on a character terminal & kill a debugger process that seemed to be hung & blocking the tests.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #36 from Ian Goddard igoddard@nildram.co.uk 2009-08-16 05:37:54 --- (In reply to comment #35) I backed out my change so that x11drv_main.c continued to report a depth of 32 but modified bitmap.c at line 143 so that it would report an error on trying to create a bitmap more than 24bpp. This is the test which generates the non-fatal error when I return a depth of 24.
This now reports several similar errors but then crashes with the normal read error.
It appears that the app is trying to create a number of bitmaps. In most cases it respects the reported depth but in one case it doesn't and tries to generate a 32bpp bitmap whatever the depth.
I also looked at a number of pieces of code which seemed to be setting the depth and limited these to 24 but none of them prevented the crash.
As the app respects the reported depth in most cases it seems likely that my original fix of reporting a depth of 24 avoids the crash by the app respecting it and not by allowing Wine to use the conversion functions you mentioned to correct a 32bpp operation by the app.
At present it seems that the best solution is for those of us who aren't using Nvidia but are using apps that will try to use 32bpp to amend the appropriate line in xlldrv_main.c (currently line 315). Instead of "return 32;" this should be amended to "return depth;".
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #37 from Stefan Dösinger stefandoesinger@gmx.at 2009-08-16 06:23:22 ---
At present it seems that the best solution is for those of us who aren't using Nvidia but are using apps that will try to use 32bpp to amend the appropriate line in xlldrv_main.c (currently line 315). Instead of "return 32;" this should be amended to "return depth;".
Doubtful.
Pretty much every graphics card that was built in the past 10 years uses 32 bit framebuffers, not 24 bit ones. 32 bit framebuffers aren't an Nvidia specific. The only GPU I could find that still supports a 24 bit framebuffer is an old ATI Mach64 - a GPU core from around 1994.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #38 from Ian Goddard igoddard@nildram.co.uk 2009-08-16 08:12:47 --- (In reply to comment #37)
At present it seems that the best solution is for those of us who aren't using Nvidia but are using apps that will try to use 32bpp to amend the appropriate line in xlldrv_main.c (currently line 315). Instead of "return 32;" this should be amended to "return depth;".
Doubtful.
Pretty much every graphics card that was built in the past 10 years uses 32 bit framebuffers, not 24 bit ones. 32 bit framebuffers aren't an Nvidia specific. The only GPU I could find that still supports a 24 bit framebuffer is an old ATI Mach64 - a GPU core from around 1994.
Not all graphics kit uses a separate graphics card. Some of us, particularly laptop users, use what's on the motherboard.
I'm using a laptop which is much less than 10 years old using Intel chipset. I suppose there must be many users in the same situation.
If I attempt to set the depth to 32 in xorg.conf X will not run properly.
If I attempt to let Wine set the depth to 32 the app will crash.
For me and anyone else in this situation, the mod I suggested will work.
However, hacking the C & rebuilding will not be acceptable to all users. If there's no clear way to achieve an all-round solution based on what the X server returns ISTM that a more acceptable solution would be to make provision for the user to specify the depth to be used.
I note when looking through the code that there's scope for optionally picking up the depth from the registry. As things stand at present, however, this value, if set, is overridden by the existing code.
My suggestion would be to sanity-check any value set in the registry and, if it's OK let it override the value set in the current code. This seems to me to meet everyone's requirements: H/W and S/W combinations which currently work would continue to do so but anyone for whom this does not work would be able to add the optional key to the registry to provide a depth setting which would work. Do you think this could be that all-round solution?
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #39 from Stefan Dösinger stefandoesinger@gmx.at 2009-08-16 08:53:34 --- I'm pretty sure the onboard chipsets like the Intel GMA also use 32 bit framebuffers. They have their own graphics processor, just not their own memory. Accessing the system memory with unaligned access would be pretty awkward I think.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #40 from Ian Goddard igoddard@nildram.co.uk 2009-08-16 10:37:32 --- (In reply to comment #39)
I'm pretty sure the onboard chipsets like the Intel GMA also use 32 bit framebuffers. They have their own graphics processor, just not their own memory. Accessing the system memory with unaligned access would be pretty awkward I think.
I follow your reasoning and I agree that that certainly seems to be what might be expected. But, on the basis that 24bpp is unaligned and 32 bpp is aligned, empirical evidence says that for some H/W / S/W combinations it just doesn't seem to work like that: 24bpp works, 32bpp doesn't.
Looking at the duplicate bugs there are multiple reports of this problem involving four other apps - and from memory I've seen at least one other report on the Ubuntu forums for a further app.
Given that there's empirical evidence that there really is a problem with setting the depth to 24, does the solution I outlined, enabling an override via the registry, seem a likely solution?
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #41 from Henri Verbeet hverbeet@gmail.com 2009-08-16 12:23:30 --- (In reply to comment #34)
The reason why games usually check for 32 bpp is:
*) Because they're stupid and don't know what they're doing *) OpenGL and D3D can use the 8 fill bytes for backbuffer alpha, allowing additional blend modes. There are better ways to check for support for that, so it comes down to "games are stupid" again.
Not entirely. Having 32bpp screen depth also implies alpha channel support for DIBs and DDBs. Current winex11.drv doesn't always handle that correctly, but Roderick's XRender patches might eventually fix that.
http://bugs.winehq.org/show_bug.cgi?id=11203
Detlef Riekenberg wine.dev@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|wine.dev@web.de |
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #42 from Dan Kegel dank@kegel.com 2010-06-22 22:36:31 --- Is this still an issue with wine-1.2rc4?
http://bugs.winehq.org/show_bug.cgi?id=11203
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|jeffz@jeffz.name |
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #43 from Ian Goddard iang@austonley.org.uk 2010-06-23 04:43:02 --- (In reply to comment #42)
Is this still an issue with wine-1.2rc4?
I don't know. I've given up on the whole thing. Somewhere along the line there were further issues with blacked out icons in the file dialog box. As a some-time sysadmin I also wasn't happy about the attitudes to lack of test environments when support for do-tests was abandoned. So I've just resorted to patching 1.1 so that it works & left it at that.
However I'll take a look at the code & get back to you.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #44 from Ian Goddard iang@austonley.org.uk 2010-06-23 04:59:39 --- (In reply to comment #43)
(In reply to comment #42)
Is this still an issue with wine-1.2rc4?
I don't know. ... However I'll take a look at the code & get back to you.
Yes its still there. Line 322 of x11drv_main.c says "return 32;" but it drops through from the previous cases such as "case 24:" a few lines above. The consequence is that any system which reports a 24 bbp display will be treated as if it had reported 32 bpp. If an application (and it appears, from duplicate bugs, that there are several, not just EA) then tries to send a 32 bpp image and the display really can only handle 24 then, unless some other code elsewhere works round this then it will crash. To check further I'll need to make the code & test it. That will take me a good while longer.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #45 from Ian Goddard iang@austonley.org.uk 2010-06-23 06:11:02 --- (In reply to comment #44)
(In reply to comment #43)
(In reply to comment #42)
Is this still an issue with wine-1.2rc4?
I don't know. ... However I'll take a look at the code & get back to you.
Yes its still there. Line 322 of x11drv_main.c says "return 32;" but it drops through from the previous cases such as "case 24:" a few lines above. The consequence is that any system which reports a 24 bbp display will be treated as if it had reported 32 bpp. If an application (and it appears, from duplicate bugs, that there are several, not just EA) then tries to send a 32 bpp image and the display really can only handle 24 then, unless some other code elsewhere works round this then it will crash. To check further I'll need to make the code & test it. That will take me a good while longer.
(In reply to comment #44)
(In reply to comment #43)
(In reply to comment #42)
Is this still an issue with wine-1.2rc4?
I don't know. ... However I'll take a look at the code & get back to you.
Yes its still there. Line 322 of x11drv_main.c says "return 32;" but it drops through from the previous cases such as "case 24:" a few lines above. The consequence is that any system which reports a 24 bbp display will be treated as if it had reported 32 bpp. If an application (and it appears, from duplicate bugs, that there are several, not just EA) then tries to send a 32 bpp image and the display really can only handle 24 then, unless some other code elsewhere works round this then it will crash. To check further I'll need to make the code & test it. That will take me a good while longer.
Yes, I've just checked. It still crashes. Altering the line to "return depth;" still works.
It occurred to me that as there is provision for setting bpp in the registry if such a registry setting were used and allowed to override both the depth reported by the driver and the assumption made in the present code then we would have the best of both worlds: those for whom the assumption holds true would continue to have the speed benefit of 32 bits & those of us who have a problem could use the registry to work round it.
BTW the blacked-out icon problem seems to have been fixed.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #46 from Ian Goddard iang@austonley.org.uk 2010-06-23 06:23:33 ---
BTW the blacked-out icon problem seems to have been fixed.
Maybe I spoke too soon. Although the file dialogs looked OK on a quick check I noticed that the terminal window has many lines such as this:
err:commctrl:COMCTL32_SubclassProc Our sub classing stack got erased for 0x10bae!! Nothing we can do
http://bugs.winehq.org/show_bug.cgi?id=11203
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |5461d505d727411f8de3f7846c5 | |d1e8ed6343247
http://bugs.winehq.org/show_bug.cgi?id=11203
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frederic.delanoy@gmail.com
--- Comment #47 from Frédéric Delanoy frederic.delanoy@gmail.com 2012-02-24 11:35:33 CST --- Is this still an issue in recent (1.4-rc4 or later) wine?
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #48 from Ian Goddard iang@austonley.org.uk 2012-02-27 04:50:17 CST --- (In reply to comment #47)
Is this still an issue in recent (1.4-rc4 or later) wine?
Probably not but there may be others. Back in November I looked at some of the more recent development versions of Wine & that area of the code had been totally changed.
The problem was an interaction between hardware, application and code which made unwarranted assumptions about both. I've changed H/W although the new laptop has similar graphics & drivers to the old. Although neither the original problem nor the black icons recurred although there was a new one in that some control backgrounds were black instead of white.
However at that time I also upgraded to a more recent version of the application. I experimented a little with different combinations of more recent versions of Wine (& the then current Crossover Office) & the two versions of the application but every change seemed to solve one problem & introduce another. Eventually I went back to using 1.2.3 with my workaround as it works.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #49 from Dan Kegel dank@kegel.com 2012-02-27 09:16:27 CST --- It would be nice if you could check whether this particular problem is still present on wine-1.4rc5. If the symptom has changed, please file a new bug for the new symptom.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #50 from Alistair Leslie-Hughes leslie_alistair@hotmail.com 2012-02-27 15:21:13 CST --- I still get a crash when running the Enterprise Architect 6.5.806. The crash dump appears to be the same though.
BTW: The blank window is a separate issue.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #51 from Ian Goddard iang@austonley.org.uk 2012-02-28 05:44:29 CST --- (In reply to comment #49)
It would be nice if you could check whether this particular problem is still present on wine-1.4rc5. If the symptom has changed, please file a new bug for the new symptom.
Yes, it's still present. Reading through the code some more I see that there's a line in opengl.c which substitutes 32 for 24; maybe this is where the bug's being implemented now.
I'm trying to remember just what the events were last year. I know I was trying Wine 1.3.x
I updated EA to the current version. Possibly it was that that ran without crashing on 1.3 but with the black background problem.
Reading through the comments it's clear that the development focus is on enabling games to run on high-end kit at the expense of a show-stopper for non-game S/W on commodity kit. Personally I can live with that as I can patch something that works for me as I've no interest in game S/W.
But if you really want to address both requirements you'll need to do so well before stable rc time. If I could help further I would but I really don't have a handle on display technology, opengl or the like, even under Linux let alone under Windows.
http://bugs.winehq.org/show_bug.cgi?id=11203
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #52 from Bruno Jesus 00cpxxx@gmail.com 2012-11-26 14:45:28 CST --- Is this still an issue in the latest development version of wine? The current program version 9.3.935 does not seem to crash the way described. I can't find the old one to test.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #53 from Alistair Leslie-Hughes leslie_alistair@hotmail.com 2012-11-26 21:34:28 CST --- The crash still occurs when using EA v6.5 build 806.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #54 from Ian Goddard iang@austonley.org.uk 2012-11-27 12:03:14 CST --- I don't know. I've stuck with 1.0.1 hacked to remove what I consider to be a bug & the devs seemed to consider a feature (see the comments from Aug 2009).
The problem seems to be a deliberate design decision: to assume that a graphic driver which reports only 24-bit capability can, in fact, handle 32 bits & to act on that assumption in the interest of running games. If an application then sends a 24-bit image the program will crash. I have had several boards with 24-bit drivers and that assumption has been false for all of them.
Last time I looked - about a year ago - the code had been substantially changed but was still based on that assumption. Until that decision is rescinded the problem will remain. If it is rescinded the change required will be trivial.
It did seem to me quite feasible to add a switch in the registry so that the assumption could be applied or not depending on the H/W; I'd have been prepared to code it myself on the original version of the code. However I gained the impression that supporting Intel graphics wasn't of interest to the project and, having a quick hack that works, I don't need a more elaborate version myself.
I agree that last time I checked against a more recent Wine build 9.x builds of EA were OK but this is a feature of later EA builds,, not of Wine. As comment 53 from A L-H shows the problem is still there with the original EA. However there were duplicate bug reports against various other applications (VB was one IIRC) it may still be a problem for some Wine users who have different requirements.
I only have that one application which needs Wine. Although the current version of that no longer has a problem I've stuck with what already works for me: 1.0.1 with a one line change. I have long since stopped testing any more recent builds of Wine. I'd be happy retest if & when the devs decide to revisit the issue.
At present the code supports the following use case:
A board which reports 24bpp but can handle 32 is used to run an application which insists on having 32bpp.
The use case which fails is:
A board which reports 24bpp and can't handle 32 is used to run an application which will fall back to 24bpp if that's what's reported but will attempt to use 32 if that's reported.
How prevalent are these two use cases? At present the 2nd is being sacrificed to support the 1st. If the 1st isn't valid then I suggest a trivial code change to report 24bpp back to the application. Otherwise, make a decision to either add a registry switch to support both of them or mark as won't fix.
http://bugs.winehq.org/show_bug.cgi?id=11203
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #55 from Stefan Dösinger stefan@codeweavers.com 2012-11-27 12:59:41 CST --- Can you do something like
grep framebuffer /var/log/Xorg.0.log
And post the resulting line here? It should write a line like
[ 71.474] (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
possibly with some other values, and with the Intel display driver instead of NVIDIA. If your Xorg log goes somewhere else, adjust the filename of course. If there's no log, you can start an X server as root with /usr/bin/X --verbose 6 to get the output.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #56 from Ian Goddard iang@austonley.org.uk 2012-11-29 15:43:26 CST --- (II) intel(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 (==) intel(0): Depth 24, (--) framebuffer bpp 32 (==) intel(0): RGB weight 888 (==) intel(0): Default visual is TrueColor (II) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale (--) intel(0): Chipset: "Arrandale"
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #57 from Stefan Dösinger stefan@codeweavers.com 2012-11-29 16:15:12 CST --- (In reply to comment #56)
(==) intel(0): Depth 24, (--) framebuffer bpp 32
Your graphics card is not the issue, it uses a 32 bit framebuffer as well. The application or some part in Wine doesn't deal correctly with the changed framebuffer depth. Since Enterprise Architect 6.5 was apparently released in 2006, I suspect the latter - by 2006, virtually all GPUs that were still used used a 32 bit framebuffer.
I tried to find a EA 6.5 demo, but could not find any. Do you know a download link where I can find it?
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #58 from Bruno Jesus 00cpxxx@gmail.com 2012-11-29 16:23:57 CST --- This one is 6.5 Trial:
http://web.archive.org/web/20080516050351/http://www.sparxsystems.com/produc...
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #59 from Stefan Dösinger stefan@codeweavers.com 2012-11-29 16:53:19 CST --- I'm impressed by that archive, even the download link worked.
Unfortunately I cannot reproduce this bug though. EA 6.5 starts fine here on MacOS with wine-1.5.18-115-g3709fb8. The drawing is slow, but it renders fine and doesn't crash. I navigated through one of the example files for testing. I'll test it on Linux the next time I boot it.
Ian, do I have to do anything special to trigger the crash?
http://bugs.winehq.org/show_bug.cgi?id=11203
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefandoesinger@gmx.at |
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #60 from Ian Goddard iang@austonley.org.uk 2012-11-29 17:05:25 CST --- Nothing special needed. It has invariably crashed on start-up for me on Ubuntu when I used that or Debian which I've used over the last few years. This on either Intel or Via based systems unless I changed the return value from 32 to 24.
The last time I tried was a year or so ago when I set up the current laptop (Debian 6). I'll try again over the next few days, possibly tomorrow or over the weekend.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #61 from Stefan Dösinger stefan@codeweavers.com 2013-01-06 12:15:56 CST --- EA 6.5 works fine in wine-1.5.21 for me on two Linux systems I tested, one with a Geforce 9600 and the proprietary driver, the other one with a Intel GMA 965 xf86-video-intel 20.2.13. Please retest the application on your machine and report if it works.
W.r.t. the performance issues: There are two regedit instances consuming a lot of CPU time, killing them improves the drawing speed of the application somewhat.
http://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #62 from Stefan Dösinger stefan@codeweavers.com 2013-06-14 04:53:46 CDT --- Can anyone confirm that this is still an issue on modern drivers? If not, I'll close this bug in a few weeks.
http://bugs.winehq.org/show_bug.cgi?id=11203
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |ABANDONED
--- Comment #63 from Stefan Dösinger stefan@codeweavers.com 2013-10-08 04:39:44 CDT --- It's been about 5 months, closing. I assume the bug is fixed (the app works for me), but without anyone to confirm I'll set the resolution to abandoned.
http://bugs.winehq.org/show_bug.cgi?id=11203
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #64 from Stefan Dösinger stefan@codeweavers.com 2013-10-08 04:41:54 CDT --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=11203
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|ABANDONED |WORKSFORME
--- Comment #65 from Austin English austinenglish@gmail.com 2013-10-08 16:43:07 CDT --- (In reply to comment #63)
It's been about 5 months, closing. I assume the bug is fixed (the app works for me), but without anyone to confirm I'll set the resolution to abandoned.
WORKSFORME is more appropriate.
https://bugs.winehq.org/show_bug.cgi?id=11203
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Versions 9.52 & 9.53 throw |Multiple applications crash |page exception on |due to 24bpp display |Enterprise Architect |reported as 32bpp | |(Enterprise Architect 6.x - | |9.x, 16-bit Acrobat Reader | |3.01, TruePiano 1.0.2) CC| |focht@gmx.net Component|-unknown |winex11.drv URL|http://www.sparxsystems.com |https://web.archive.org/web |.au/products/ea_downloads.h |/20110807215145/http://www. |tml |sparxsystems.com/bin/easetu | |p.exe
--- Comment #66 from Anastasius Focht focht@gmx.net --- Hello folks,
adding stable download links to several EA trial versions via Internet Archive for documentation purpose. Also refining the summary since this bug has been used as dupe collector.
===
Enterprise Architect 6.5.806
https://web.archive.org/web/20070614074848/http://www.sparxsystems.com/bin/e...
$ sha1sum easetup.exe c77a3656491bd711af8fd601f104284d249ab255 easetup.exe
$ du -sh easetup.exe 28M easetup.exe
===
Enterprise Architect 9.0.908
https://web.archive.org/web/20110807215145/http://www.sparxsystems.com/bin/e...
$ sha1sum easetup.exe 62fa681d84332f9229105f96580182061f93113d easetup.exe
$ du -sh easetup.exe 39M easetup.exe
===
Enterprise Architect 9.1.910
https://web.archive.org/web/20111005021524/http://www.sparxsystems.com/bin/e...
$ sha1sum easetup.exe 465f81e67336442b81b02e4c468958e1a934b9c8 easetup.exe
$ du -sh easetup.exe 38M easetup.exe
===
Enterprise Architect 9.3.931
https://web.archive.org/web/20120410052148/http://www.sparxsystems.com/bin/e...
$ sha1sum easetup.exe 8272b3d9443c19da4113acf0c5ee5680a03bec02 easetup.exe
$ du -sh easetup.exe 39M easetup.exe
===
Regards
https://bugs.winehq.org/show_bug.cgi?id=11203
--- Comment #67 from Stefan Dösinger stefan@codeweavers.com --- Since I saw the dupe emails, and I closed this bug as WORKSFORME 8 years ago: Are any of the applications listed here still broken due to the 24/32 bit confusion?
-
wine-bugs＠winehq.org -
WineHQ Bugzilla