March 2007 - Wine-devel - list.winehq.org

Driver/os bug test app
by Stefan Dösinger 25 Mar '07

25 Mar '07

Hi, Some other thread got into a sub-discussion of how to deal with driver issues. I think it is a slightly bigger issue, so I start a seperate thread about it. First of all, we will never get rid of driver bugs. Even if all bugs are fixed in drivers there will be old driver versions around, and there will be misconfiguration. My experince with supporting CrossOver users, and (older) memories of #winehq shows that many people run into problem which are caused by missing 3D drivers. The usual procedure is to isolate the issue, then write a seperate test app and report the issue to the driver developer. Thats perfectly fine I'd say. My suggestion is to collect those test cases in a Wine driver test suit somewhere, a seperate application(in the wine tree or not) which users can run to test their systems for known issues. This would make dealing with bugs easier, when a user complains why wow is terribly slow tell him to check his system with that test app, or if a user reports a bug with simmilar issues tell him to test the driver too. The test app reports detected issues to the user and can store links to bug reports(if publically available) and the driver version which has the bug fixed(if any). That test app should be a native Linux / MacOS app, not an application running in wine to exclude wine bugs. If that idea is not accepted, I can set up a git repositority for collecting individual driver tests so we have them archived somewhere at least. Bugs are not limited to 3D drivers of course, some kernel versions are known to have issues too, so the whole proposal is not limited to 3D stuff.

1 0

Road to 1.0 (graphics driver architecture)
by Rolf Kalbermatter 25 Mar '07

25 Mar '07

Alexandre Julliard wrote: >I'm also hoping we can make some progress on the x11drv factorisation >before the freeze, so that we don't need to change the interface too >much to add the quartz driver later on, we'll see how that goes. Have you some specific ideas about what you want to do in that area? While the current apporach certainly works fine as far as invoking the DC specific functions without a lot of checking about the type of DC that is involved and therefore has a straightforward interface in GDI32 I think the matching of the actual driver interface with the actual GDI functions adds a lot of overhead into the driver itself that could much more easily be done once in GDI and left out of the driver completely. However changing the driver interface to match the let's say W2K driver would be quite a bit of work although it would seem to me at least an idea. Coming up with yet a different Wine specific interface would first require some architectural design work too but maybe you have done something in that direction already. Rolf Kalbermatter

2 1

Another win32 implementation: hiweedlayer?
by Dan Kegel 25 Mar '07

25 Mar '07

http://hiweed.com/node/798 offers "hiweedlayer" for download. It is supposedly a Windows layer like Wine. Running strings on their single executable, I see messages like %s is being traced! location has changed! abnormal behavior! shell has changed! %s has expired! Please contact your provider which look like they're from this little bit of malware: http://forums.fedoraforum.org/archive/index.php/t-25441.html but perhaps they're just trying to keep people from reverse-engineering their code (or finding out that they have Wine code inside?). Using google language tools to translate the page, http://translate.google.com/translate?u=http%3A%2F%2Fhiweed.com%2Fnode%2F79… it looks like somebody already asked them if they were related to wine, but they didn't really answer. Can somebody fluent in Chinese make contact with them and see what their story is with regard to wine? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 4

Re: Game road to 1.0
by Alessandro Pignotti 25 Mar '07

25 Mar '07

Hi, I'm actually working on DirectPlay implmentation, i'm first fixing a bit of thing around dplayx, so that we can use native dpwsockx (the dplay service provider) with builtin dplayx. After that i'm going to reimplement dpwsockx from scratch using the info from Kai Blins work on the protocol. Regards, Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome

1 0

Re: WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders
by Ivan Gyurdiev 25 Mar '07

25 Mar '07

> From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Fri, 23 Mar 2007 19:03:58 +0100 > Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders > Isn't there a function to handle modifiers? "get_modifier_line"...

4 6

Re: [2/3] WineD3D: Implement bem shader instruction
by H. Verbeet 25 Mar '07

25 Mar '07

On 25/03/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > With the glsl suggestions from Henri :-) > >+ shader_addline(arg->buffer, "(%s.xy + bumpenvmat * %s.xy)%s);\n", >+ src0_param.reg_name, src1_param.reg_name, dst_mask); MSDN states that the source parameters can have swizzles and modifiers. Unless, you can prove that's not true, the code should become: void pshader_glsl_bem(SHADER_OPCODE_ARG* arg) { glsl_src_param_t src0_param, src1_param; shader_glsl_append)dst(arg->buffer, arg); shader_glsl_add_src_param(arg, arg->src[0], arg->src_addr[0], WINED3DSP_WRITEMASK_0|WINED3DSP_WRITEMASK_1, &src0_param); shader_glsl_add_src_param(arg, arg->src[1], arg->src_addr[1], WINED3DSP_WRITEMASK_0|WINED3DSP_WRITEMASK_1, &src1_param); shader_addline(arg->buffer, "%s + bumpenvmat * %s);\n", src0_param.param_str, src1_param.param_str); } Normally you would have to take the destination write mask into account as well, but for this instruction it's always .xy.

1 0

Fwd: DirectDrawRenderer - opengl non power of 2 windows
by Nathan Williams 24 Mar '07

24 Mar '07

Oh sorry, my misunderstanding! It is called from: flush_to_framebuffer_drawpixels http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/surface.c;hb=H… On 3/25/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Samstag 24 März 2007 23:59 schrieb Nathan Williams: > > It crashes at: > > dlls/wined3d/surface.c > > d3dfmt_convert_surface: > > 1593 *dest++ = table[color][0]; > Yes, but from where is this called? d3dfmt_convert_surface: gets a height > parameter, and this parameter is incorrect. > -- Nathan

1 0

DirectDrawRenderer - opengl non power of 2 windows
by Nathan Williams 24 Mar '07

24 Mar '07

I'm working on fixing the menus in carmageddon and I have a question. I have set the DirectDrawRenderer to opengl and it all crashes (where it works under gdi, just displays incorrectly). Now I traced the problem down to: dlls/wined3d/surface.c d3dfmt_convert_surface The loop at: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/surface.c;h=1f… loops over the surface height and width, the only problem is that the surface height appears to be scaled up to the next power of 2. As carmageddon runs in 320x200 the loop tries to iterate over 320x256 and subsequently crashes with a page fault in winedbg. Is there anyway to get the original window's dimensions and perhaps feed that to the function & hence loop, instead? Or should I just accept that carmageddon will forever be restricted to the gdi renderer? :P -- Nathan

2 5

re: SoC Idea: Improve bultin WordPad
by Dan Kegel 24 Mar '07

24 Mar '07

Alex wrote: >> > closest I have gotten is some patches for Wine's WordPad implementation. >> >> Granted, it's less sexy than games, but you could learn more about C and >> Wine by building on that experience. There are lots of small and easy >> improvements that can be done get Wordpad up to par with native. Then come >> back next year to fix the games! > >That i s a good idea. :) > >I think I will go for it, unless anyone has objections to it. Sounds good to me. Suggestion: spend a day or two filing bugs or enhancement requests now for a bunch of things you'd like to fix / improve in wordpad. (I might even suggest broadening your proposal to include notepad; maybe there are a couple low-hanging fruit there.) - Dan

3 2

re; [Resend][Corrected] gdi32:widenpath partial implementation
by Dan Kegel 24 Mar '07

24 Mar '07

I think it might help to a) create a bug in bugzilla with a link to Navigation, and a screenshot of the problem, and a recipe to reproduce b) think about how to implement a conformance test. Even a simple one might help. These suggestions were already made back in http://www.winehq.org/pipermail/wine-devel/2007-January/053457.html - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0