wine-devel March 2001

58 participants
94 discussions

Re: OpenGL Visual Management
by lawson_whitney＠juno.com 16 Apr '01

16 Apr '01

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.

2 11

Re: [PATCH] Add Callback for wavemapper -> widOpen
by Alexandre Julliard 09 Apr '01

09 Apr '01

"James Hatheway" <james(a)macadamian.com> writes: > I implemented the callback in a very similar way as the Wave out callback > is implemented. You can see this in the functions wodOpen(), wodOpenHelper(), > and WAVEMAP_DstCallback() , look at the data passed in the wom structure > (in dlls/winmm/wavemap/wavemap.c). I don't see any other way that I will > be able to callback into the app when the WineOSS layer notifies the wavemap > layer. The way it is now (wineoss directly calling the app) > causes my app to crash, and doesn't work that way on waveout. But these other functions are not using the WINE_MLD internal winmm structure, so why do you need it in widOpen()? Couldn't you instead do exactly what wodOpen() does? -- Alexandre Julliard julliard(a)winehq.com

3 5

Re: Nasty Wine/kernel bug, anyone?
by Ulrich Weigand 06 Apr '01

06 Apr '01

> If I were going to make more WAGs (Wild Assed guesses), > I'd hazard a guess that this was due to my Alsa sound system > (running on the AC97 codec on my Asus motherboard). > > I tried to walk the stack back, but didn't get very far > (after the first time of wrongly computing the hex offset > from a .s file, I gave off, stomped off to look > for a better disassembler and gave up). If you have the 'vmlinux' file, try objdump --disassemble vmlinux > My best guess is that we're coming through dentry_open > (xc012e7fe)/ chrdev_open (0xc012f66c) > /soundcore_open (0xc01bbf71). However, I wasn't > seeing a familiar EBP/EIP pattern, so I'm possibly just > pulling random symbols out of the air. Yes, this appears to the proper trace: c0108d7f system_call c012ea2c sys_open c012e732 filp_open c012e7fe dentry_open c012f66c chrdev_open c01bbf71 soundcore_open d0826a42 <module> d087ce3e <module> c0107aa4 __down_failed c010794f __down ........ schedule [I am assuming that you have 256MB main memory. Correct?] Now, the question is still, who is sleeping on that semaphore and why? >From the call trace, it would seem that some sound-related module is loaded, which does a down() on some semaphore in its open() routine. We even know which semaphore: cff267ac. (This does not help much, as this is would appear to be somewhere in kmalloc()ed memory ...) We can continue to track in two directions. First, we can try to locate the point within the Wine application where the open() syscall is performed. >From the trace we see that the system call instruction is located at 40303a24, and the stack pointer points to 405c6638. The system call itself is an open( 41610240, O_WRONLY|O_NDELAY ) [The stack pointer value is rather weird, I'd say ...] This particular open mode occurs in the Wine source only in dlls/winmm/wineoss/audio.c, which confirms the sound hypothesis. The next time you reproduce the bug, could you please add the output of /proc/<pid>/maps for the hanging Wine process? This way, we could further analyse these pointers to Wine user space ... The more promising way to track the problem, however, is to find out which module those d* addresses above reside in. If the modules are still loaded, the output of /proc/ksyms should at least give a hint. For a more refined symbol lookup, it is best to use the 'ksymoops' tool, which correlates the /proc/ksyms output with the ELF symbols read from the object modules themselves. To do so, write this: Call Trace: [<d0826a42>] [<d087ce3e>] to a file and pipe the file through ksymoops. In any case, this would seem to be clearly a bug in that sound module. I don't know, however, why only Wine would trigger that bug ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

2 1

Re: [PATCH] deferred trace
by gerard patel 06 Apr '01

06 Apr '01

At 03:00 PM 14/03/2001 -0800, you wrote: <snip> >that the wine debugger can resolve, it is possible to meet the needs that >have been expressed. Expressed ? What I wanted is something short and simple, so I could help people on the news group. The use of my patch could be explained in *one* line and it would have worked with Wine right 'out of the box' :-)... something the internal debugger does not do anymore since a long time. I am afraid that this thing will be more complex to setup and to use that the debugger - something already too complex for many people. And well, I almost never use the debugger myself because it crashes at the slightest provocation so I don't feel much about saying people to use it. So in short, after all my 'needs' (helping ppl on the news group) are indeed specific :-) Gerard

2 1

RegSetValueEx problem?
by davep 31 Mar '01

31 Mar '01

I've been trying to track down why WineMine does not save my best scores ;-( On exit, WineMine saves the current user settings to the registry with code like this: char data[16]; wsprintf( data, "%d", p_board->pos.x ); RegSetValueEx( hkey, "Xpos", 0, REG_SZ, (LPBYTE) data, sizeof( data )); The problem here is that the 'count' parameter passed to RegSetValueEx is not the string length but the size of the entire buffer. Wine dutifully writes into the registry the entire buffer including the trailing garbage, and also adds a null to the end if there isn't one there. When WineMine tries to read the value back it is now 17 characters long and too big to fit in the 16-byte buffer. Compiling and running Winemine under Windows 95 this problem doesn't occur. Win95 truncates the value at the first null. So RegSetValueEx needs fixing. However there are already comments in there about the differences between 95 and NT in the handling of REG_SZ values, and I don't have an NT system to carry out checks. Can someone with experience propose a solution? -- Dave Pickles

1 0

Sendmessage fix..
by crazney 31 Mar '01

31 Mar '01

Hey, im writing cause i presently use Andreas Mohr's sendmessage fix (titled TEB fix, because it stop the TEB errors).. basically, what the patch does, is clean up after a killed SendMessage if it didnt clean itsself up.. (well something like that, iirc).. anyway, i run the LHL howto page, and this patch is very useful to running Half-Life and several other games/programs.. so itd be nice to have it in CVS.. which it isnt presently.. when Andreas Mohr first wrote the patch, he told me that alexandre denied it, and neither him, ove or myself can work out why.. so yer, i'd just like to know a) why was it refused.. and b) can you put it in now, or write something which does just this now.. thanks in advance ps, can you please email me about this, because im not subscribed to this list. cheers David -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Hammerton aka crazney Victoria, Australia http://crazney.net/ HOWTO maintainer and Linux Half-Life http://lhl.linuxgames.com/ email: http://crazney.net/contact.html -> Note: this email address expires after one week.

1 0

Re: [PATCH] HOOK_CallHook
by David Elliott 30 Mar '01

30 Mar '01

Francois Jacques wrote: > Group, This patch comes from investigation of a bug that was observed in > RedHat 7.0 and not observed in RedHat 6.1. After a debugging session that > involved Stephane and I, we found out that it was a compiler issue (which > I feared from the start, but wasn't considering it seriously... > arghhh). The RedHat 6.1 installation has gcc version 2.91.66 and the > RedHat 7.0 installation has gcc version 2.96-20000731 (RedHat Linux 7.0) > with latest updates from RedHat. What's happening : 1) HOOK_CallHook is > being called (notice wParam and lParam arguments)2) Local variables > wParamOrig and lParamOrig are set to wParam and lParam values3) Mapping > function is called (MapFunc) with the *addresses* of wParam and lParam so > those get changed before we call the hook4) After MapFunc is called, > wParamOrig and lParamOrig values also changed to the new values of wParam > and lParam (!) Explanation : Down to the assembly level code, the compiler > doesn't create wParamOrig and lParamOrig on the stack. Instead, it > directly use wParam and lParam. Fix : add volatile to wParamOrig and > lParamOrig to prevent optimizations on those variables (aka. force their > presence on the stack) This kind of begs the question: how many more places in Wine should the volatile keyword be used? I find it hard to believe that this is the only spot in a large very low-level project like Wine. -Dave

6 9

Re: [PATCH] HOOK_CallHook
by François Jacques 30 Mar '01

30 Mar '01

>OK, I must have misunderstood you then. Sorry ... It's ok :) >I've managed to reduce the problem to a simple testcase, which is >appended below. It fails on RedHat gcc-2.96-69 (as of 12/2000) ... > >Culprit *appears* to be the global common subexpression elimination, >although this is not quite definite. I haven't tracked the problem >down yet. Are you thinking of doing more investigation on that? >However, when switching off GCSE (-fno-gcse), correct code is produced. >I'm not sure I'd like to do a complete Wine build without GCSE though; >this might significantly reduce code quality ... Oh the runtime behavior should not change that much but it's still non-negligeable. I like the "disable-gcse-if-you-probe-that-gcc-version" approach. >I'll write a configure check to switch off gcse, using the testcase >below. We should probably contact RedHat (I think Jacub Jelinek >handles 2.96 bugs ...) to confirm that GCSE is really at fault. If you want to post it with the test program, go ahead :) I never posted to gcc bug list so I'm not sure how much attention would be given to the bug. I think the mailing list should be cc'ed on the postings so everybody can follow up how it turns out. Ciao! Francois

1 0

Re: [PATCH] HOOK_CallHook
by François Jacques 30 Mar '01

30 Mar '01

>To be honest, I didn't read the patch and simply assumed this was a simple case >of forgetting to add volatile and getting bitten by a compiler that optimizes >more agressively. > >Either way it still is a valid point to be concerned about not only compiler >bugs but also new compiler features. 100% agree on this point. The community needs some ways to keep up to date with those new compiler versions. I know it's hard since we work on different projects which usually needs some kind of stability (in the product and in the development process) so we tend to stick with a reference compiler that we know works. However, if we don't keep up to date with those new compiler version, well fall in some intensive bug chasing session... and debugging at the assembly level is not that fun. And it's a cycle, we test the new compiler version, we find bugs, we get an improved compiler which, with a nice side-effect, may solve other bugs. >That would be a good idea. Of course I don't think the volatile keyword in >this case is hurting anything except maybe speed (negligble). Hopefully this >can get fixed soon in gcc. Looking at the gcc project page, it seems that 3.0 >is very close to be done. 3.0 ? That's good news in terms of technology advance... however I fear some late nites chasing bugs generated from that new version :) Cheers! Francois

1 0

Re: controls/edit.c
by lawson_whitney＠juno.com 29 Mar '01

29 Mar '01

On Thu, 29 Mar 2001, Ulrich Czekalla wrote: > I forgot to plug a region leak before I sent the patch in. I have > attached an updated patch. > > /Ulrich > Good day! This message comes to you from Juno-2.0.11 without benefit of junopine: I am composing it with Juno's GUI composer using the new edit.c. Much less flicker. I still can't answer a letter this way: Juno chokes on a SendMessageCallback as soon as it gets anything in its inbox, but that is nothing to do with edit.c It is hot and heavy with ads now and I get some sluggishness because I am contending with the ad engine for the 47 bogoMIPS of the mighty p-120, but really it seems much better. I still don't like GUI though, and Juno might get annoyed if I delete all its ads, which I would have to do to really use this composer, so I will go back to Pine now, but it does seem much better nor it was. Lawson ---cut here Well, not quite without junopine. I hit alt-s meaning to send it, and saved it to the draft folder instead, and tripped on another SendMessageCallback trying to get it out, but I did compose it with a GUI editor. The first patch moved the cursor for each character of the password, but showed no character, but with the revised patch I see the xxxx strikover I am accustomed to see. I think it is an improvement, but I am hardly a GUI guru. First soldier into the minefield, maybe, and still alive. Regards, Lawson ---cut here. Really. "The Rest is Spam." ________________________________________________________________ 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.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2001