December 2005 - Wine-Devel - list.winehq.org

Re: There is no need to offset the source rectangle in the reverse direction before scrolling

by Rein Klazes

On Tue, 13 Dec 2005 23:53:07 +0800, you wrote: >Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > There is no need to offset the source rectangle in the reverse > direction before scrolling. > >--- cvs/hq/wine/dlls/x11drv/scroll.c 2005-11-22 12:41:07.000000000 +0800 >+++ wine/dlls/x11drv/scroll.c 2005-12-13 23:42:15.000000000 +0800 > /* Then clip again to get the source rectangle that will remain in the > * clipping rect */ > rcSrc = rcClip; >- OffsetRect( &rcSrc, -dx, -dy); > IntersectRect( &rcSrc, &rcSrc, &rcClip); In the first place: with this change the IntersectRect call is a no-op I doubt you understand the reason for "to offset the source rectangle in the reverse direction": Scrolling should only occur in the clipping rectangle. When you talk about the *destination* pixels, a clipping with the cliprect is needed. Here we are talking about the *source* pixels, from destination to source is indeed reverse. *that* is what is happening here. If you are not convinced: the change is wrong and clipping fails. I have added a test to confirm that. The test also gives a nice visual idea what goes wrong, just add a Sleep() or two to get the picture. Changelog: dlls/x11drv : scroll.c dlls/user/tests : win.c Restore the previous change to X11DRV_ScrollDC. With a regression test to confirm it was wrong. Rein.

Dec. 14, 2005

Re: josystick driver layer and support of multiple devices of one kind

by Daniel Remenak

On 12/14/05, Christoph Frick <frick(a)sc-networks.de> wrote: > - check also winmm out for the joystick relevant drivers > * see if there is support for both kind of joysticks > * see if there is support for multiple devices WinMM under wine supports only /dev/js devices. It does support multiple devices, with some limitations. Under wine, winmm joysticks are hard mapped as JOYSTICKID1 to /dev/js0 and so on. It's possible to end up with ID1 usable and ID2 not, or vice versa. It's even theoretically possible to end up with neither ID1 nor ID2 usable if your joystick is connected to /dev/js2 or higher, although I'd rate the chances of that actually happening as slim to none. Dinput joysticks are even worse as far as multiple devices, since they just iterate through, take the first working one they find, and call it the "wine joystick". If you want to make multiple joysticks work correctly you'll have to write quite a bit of new code, there's no way around it. > - put all the logic how to access the joystick hardware away from > dinput.dll and utilize winmm > - extend the support for multiple devices, for the parts where it is not > yet working Please be aware that the DInput devices (both abstractly and the current wine implementations) contain significant additional functionality that the multimedia devices do not. Using winmm as a base for dinput is probably not practical without significant reworking; it simply doesn't do enough. Force feedback comes to mind. I'm not sure quite what "stick everything in a single driver, and handle the complexity here" means, but there are a couple things to be aware of: 1. It should be possible to use more than one type of device simultaneously. E.g. I might have a /dev/js* device not registered by /dev/input/*, and a /dev/input/* device not registered by /dev/js*. I should be able to pick between them without hassle (e.g. they should both be reported to the application). DInput does this now, by having two separate drivers for /dev/js* and /dev/input/*. This may be even more important in the future with both joystick capabilities on other platforms (BSD, OSX, whatever), and with other interfaces on the various platforms (XInput, SDL, whatever). 2. The two extant dinput joystick backends are quite similar and have a lot of code duplication...this is what you noticed when you were moving stuff between them. Bear in mind that not all possible joystick backends will share as much code; /dev/js* and /dev/input/* were _designed_ at the kernel level to have similar interfaces. From experience writing code that uses FreeBSD's USB HID for joystick access, there is very little in common between it and the linux interfaces. XInput is even more different. --Daniel Remenak

Dec. 14, 2005

Re: WLDAP32: link to the reentrant version of libldap

by Hans Leidekker

On Wednesday 14 December 2005 01:56, Robert Reif wrote: > >Changelog > > Link to the reentrant version of libldap. > This patch breaks builds on RH9 and appears to be responsible for the > build breakage on http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php Can you send me the build errors and a relevant snippet from config.log, say 20 lines after 'checking for ldap_initialize in -lldap_r'? -Hans

Dec. 14, 2005

Re: josystick driver layer and support of multiple devices of one kind

by Christoph Frick

On Wed, Dec 07, 2005 at 11:02:14PM +0100, Eric Pouech wrote: Thanks Eric for the reply. > >- i this an approach, that would be acceptablefor wine? so if i start on > > something like this, is there a chance it would be submitted to the > > tree - or is there a problem in terms of "wine does not work like this > > and we would ignore such an approach" > > > >- is the sound-system of wine with its lots of implementations a place > > to get ideas for such a change; or is this totally off, because the > > user only chooses one driver to use (instead of: only build the driver > > if appropriate and then let each driver search for hardware) > there are several questions: > - share as much as possible code between dinput and winmm (you have to > choose which one could call the other) > - how to abstract the interfaces: ddk is your friend. for the winmm > part, check the include/mmddk.h, and dlls/winmm/joystick (the joystick > driver). there's in it all what you need (google will help too). > - from the MM experience, don't recreate a separate driver for each > known HW or interface, but rather stick everything in a single driver, > and handle the complexity here if i get you right from what i have now seen in the dinput code it would be best to do the following: - check also winmm out for the joystick relevant drivers * see if there is support for both kind of joysticks * see if there is support for multiple devices - put all the logic how to access the joystick hardware away from dinput.dll and utilize winmm - extend the support for multiple devices, for the parts where it is not yet working thinks that are _no_good_idea_: - create a proper driver (not in the windows driver sense but for internal use only) -- cu

Dec. 14, 2005

Re: [wined3d] Converting Wined3d to use WGL instead of GLX

by Aric Cyr

Raphael <fenix <at> club-internet.fr> writes: > > On Wednesday 14 December 2005 04:53, Aric Cyr wrote: > > 1) should the thunks returned from wglGetProcAddress be causing crashes at > > all? Note that they don't crash right away, but "eventually" usually during > > a call to glDrawArrays it seems (after a call to glSecondaryColor3fEXT). > > The real problem here is "why it crash ?" > It shouldn't as wine gl* calls are only "decorators" calls > Maybe we have a declaration error... Yes that was what I was thinking as well. I haven't looked into it very much yet, but I'll double check the definitions, although since opengl_ext.c is autogenerated I can't imagine why there would be a problem (unless include/wine/wined3d_gl.h has the wrong definitions... I'll have to check that out) Also I'm not sure if calling conventions matter, or what is the correct way to define a function. I'm referring to the WINAPI vs APIENTRY (vs stdcall?) function pointer prefixes. Any pointers (no pun intended) in this area would be much appreciated. > Can you provide more informations: > - WINEDEBUG=+opengl log + winedbg crash log Will do when I get home tonight, but there wasn't any useful info in there. I went through it many times. Also wine doesn't cleanly crash (if there is such a thing), instead it hangs on the backtrace and all I see is the first bt entry like: <debug stuff> 1) memcpy .... <hang> I can kill it with a ctrl-c just fine though. > > 2) what is the reason for wglGetProcAddress to check opengl32.dll before > > libGL.so? Would the reverse logic still be a resonable solution? > > No Ya kinda didn't think so :) Thanks, Aric

Dec. 14, 2005

Re: Wine: DirectDraw over Direct3D

by Aric Cyr

Raphael <fenix <at> club-internet.fr> writes: > > On Tuesday 13 December 2005 09:28, Stefan Dösinger wrote: > > Am Dienstag, 13. Dezember 2005 04:25 schrieb Aric Cyr: > > > What is slow with ATI cards? It seems that you should only need basic 3D > > > acceleration to do what you propose. Is fglrx missing something that > > > would be required for 2D rendering? > > > > Texture upload is very slow. glReadPixels, glWritePixels and friends take > > ages. That means that blt, Lock, and Unlock is really slow. > > There is some hope at least: Xine and Mplayer can play videos over OpenGL > > really fast, maybe we can find out how they do it. Texture upload is not too bad with the ATI drivers, but gl{Read/Write}Pixels will be horribly slow on most any video card. I would hope that DDraw is using textures and not direct framebuffer writes (which I believe is what Roderick mentioned). Especially, glTexSubImage2D() which should be even faster than glTexImage2D(). > for glReadPixels, glWritePixels > you can use the frame buffer object extension (or/with pbuffers) :) while glReadPixels and glWritePixels can be used with FBO, there would be no performance improvment compared with using them on a standard framebuffer. The only potential advantage to using the FBO extension would be if we created the framebuffer to match the ddraw pixel format, but it doesn't seem that paletted framebuffer formats are supported by FBO anyways. For other RGB(A) formats that do not match the current pixel format, it could be a win. For example if the Xserver is running 24 bit colour, we should be able to attach a 16bit colour FBO and use that. This might allow us to work around unsupported colour depths, such as in the ATI driver which only exposes 24bit visuals. With this extension we might be able to get a real 16bit visual. The latest nVidia and ATI drivers both support the FBO extension. Regards, Aric

Dec. 14, 2005

Re: [wined3d] Converting Wined3d to use WGL instead of GLX

by Raphael

On Wednesday 14 December 2005 04:53, Aric Cyr wrote: > Hello all, Hi, > As I mentinoed in a recent post, I have almost completed the GLX->WGL > conversion. Last night I tracked down my last bug that was causing most of > my demo apps to fail. > > It seems that the problem was the conversion from glXGetProcAddress to > using wglGetProcAddress. wined3d uses glXGetProcAddress to get the OpenGL > extension function pointers, which is what wglGetProcAddress also does. > However wglGetProcAddress _first_ checks opengl32.dll for the extension and > returns the thunk function pointer if it exists, and only then falls back > to libGL.so by calling glXGetProcAddress. > So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I > get crashes in most D3D9 applications. If I use glXGetProcAddress in > wined3d everything works fine, but then wined3d is still dependent on glx. > > So my questions: > > 1) should the thunks returned from wglGetProcAddress be causing crashes at > all? Note that they don't crash right away, but "eventually" usually during > a call to glDrawArrays it seems (after a call to glSecondaryColor3fEXT). The real problem here is "why it crash ?" It shouldn't as wine gl* calls are only "decorators" calls Maybe we have a declaration error... Can you provide more informations: - WINEDEBUG=+opengl log + winedbg crash log > 2) what is the reason for wglGetProcAddress to check opengl32.dll before > libGL.so? Would the reverse logic still be a resonable solution? No > Regards, > Aric Regards, Raphael

Dec. 14, 2005

Re: Wine: DirectDraw over Direct3D

by Raphael

On Tuesday 13 December 2005 21:43, Mike Hearn wrote: > On Mon, 12 Dec 2005 21:11:44 +0100, Stefan Dösinger wrote: > > In Wine, there are 2 ways: The first is to use X calls, which is safe, > > but slow. > > What makes you think that? X drawing primitives as well as XRender should > be hardware accelerated even though they aren't OpenGL. No, most of basic X primitives aren't not really hw accelerated XAA is inadequate for recent graphic cards (status http://wiki.x.org/wiki/XorgPerformance) For example, for texturing most of primitives are based on software algorithms (and Mesa do it faster). With EXA it's better but it's not perfect yet (improving little by little) Regards, Raphael

Dec. 14, 2005

Create new mailing list wine-isv?

by Dan Kegel

I used to hate the term ISV (Independent Software Vendor) since it sounded so acronymy compared to 'developer', but it's very commonly used in the industry to refer to outfits which are trying to write and sell off-the-shelf software -- and as monkey-boy said, Microsoft is where it is partly because it worked hard to attract and support those guys. So I've been thinking about how to attract more Windows ISVs to test, support, and promote their apps on Linux with Wine. Part of the problem is a lack of high-level documentation specifically aimed at the ISV. Another is ISVs getting lost in the shuffle on wine-users or wine-devel. I've made a start at the documentation (http://kegel.com/wine/isv) and hope to move that to winehq at some point. Now I'd like to create a discussion forum for ISVs where they will feel more comfortable; the level of discussion would be halfway between that in wine-users and wine-devel, but aimed more at Windows developers than people who are familiar with Linux. How about we create a new mailing list, wine-isv, aimed squarely at ISVs and the Wine community members who want to help them? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 14, 2005

[wined3d] Converting Wined3d to use WGL instead of GLX

by Aric Cyr

Hello all, As I mentinoed in a recent post, I have almost completed the GLX->WGL conversion. Last night I tracked down my last bug that was causing most of my demo apps to fail. It seems that the problem was the conversion from glXGetProcAddress to using wglGetProcAddress. wined3d uses glXGetProcAddress to get the OpenGL extension function pointers, which is what wglGetProcAddress also does. However wglGetProcAddress _first_ checks opengl32.dll for the extension and returns the thunk function pointer if it exists, and only then falls back to libGL.so by calling glXGetProcAddress. So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I get crashes in most D3D9 applications. If I use glXGetProcAddress in wined3d everything works fine, but then wined3d is still dependent on glx. So my questions: 1) should the thunks returned from wglGetProcAddress be causing crashes at all? Note that they don't crash right away, but "eventually" usually during a call to glDrawArrays it seems (after a call to glSecondaryColor3fEXT). 2) what is the reason for wglGetProcAddress to check opengl32.dll before libGL.so? Would the reverse logic still be a resonable solution? Regards, Aric

Dec. 14, 2005