Re: [PATCH] dinput: mouse.c: extracted the warping code into a function, got rid from goto's in alloc_device, and made the code more readable. (no change in functionality)
On Saturday 15 December 2007 10:01:44 Adam Rimon wrote: Yeah, I read it. Can you explain to me the logic behind this decision (In general, not about this specific code)? You mess up the output of e.g. git blame without ever changing the functionality of the code. I think formatting a code is an important thing to do. Yes, but it needs to be done initially, or when the code is touched, not for it's own sake. It makes the code easier to understand for programmers who have never seen the code before, If they want to read the code the way you think it should be read. and makes it also more maintainable. Agreed. In this code, for example, the white spaces and tabs are mixed, the curly braces are sometimes right next to the line before and sometimes in the next line, etc. I think there's no argument about the less than optimal formatting of the code you're talking about. Nevertheless, we're just telling you that it's very unlikely that this patch will be rejected. Alexandre doesn't like patches like that, you'll have to fork or deal with it. People on this list decided to deal with it, so don't be surprised if that's the answer you get again and again. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: [5/5] gdi: Test bitmap depths
On Sat, 15 Dec 2007, Stefan Dösinger wrote: Am Samstag, 15. Dezember 2007 01:19:05 schrieb Francois Gouget: On Wed, 12 Dec 2007, Stefan Dösinger wrote: [...] It is the intention of this patch, and coming ones, to clean up the 24/32 bpp mess, also with regard to 15/16 bpp confusion, although I am missing hardware capable of running X at depth 15 for testing, so it will be mainly about the 24/32 bpp differences which break some games. VNC server supports all depths, including 15bpp. It's ideal for tests. Do you mean the X11 VNC server? Or some Windows server? The X11 one. It's pretty useful for testing Wine, though I admit it won't help you test Windows. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?
Re: ENTER_GL and ActivateContext question
Am Samstag, 15. Dezember 2007 12:19:36 schrieb Alexander Dorofeyev: This seems to be specific to front buffer. Maybe glFlush really should be called in BltOverride (or clearing subroutine) if the target is front buffer? Yes, glFlush() has to be called when writing to the front buffer. SwapBuffers does an implicit flush, so for the back buffer you don't have to do anything, but the front buffer needs a glFlush(). It isn't there yet, so it should be added. Your patch looks quite good, but you should remove the original code from IWineD3DDeviceImpl_Clear() and make it call ClearSurface() as well. The fbo activation you moved is a different problem. It needs to be fixed as well, but it is not as easy as swapping the calls :-( . Essentially, ActivateContext has to be called before the fbo setup, due to multithreading concerns. On the other hand, some things ActivateContext does fail if an fbo is active, so fbos must be set before activatecontext. Essentially we'll have to move fbo setup into ActivateContext, but this has some implications on multiple render targets and depth stencil swapping which need more investigation. OpenGL driver limitations play a role here as well. signature.asc Description: This is a digitally signed message part.
New bugzilla components.
Please add these new components: wine-vdm - Wine 16-bit compatibility layer wine-comdlg - Common dialogs such as open/save/print/font Vitaliy.
Re: wined3d: Bind device framebuffer in ActivateContext
Here's my second attempt at this, this time merging FBO draw buffer
selection into ActivateContext. Could you please review it?
Hopefully I'm going in the right direction. The first patch moves the
call to ActivateContext before the GL calls that setup the blit. This
is needed so the second patch doesn't break stretch_rect_fbo.
The second patch moves FBO draw buffer selection to ActivateContext.
For onscreen rendering, not much changes except binding framebuffer 0.
For offscreen rendering, the behavior depends on the specified
context usage. For BLIT and RESOURCE_LOAD, the target surface is
attached to dst_fbo and used as the draw buffer. For DRAWPRIM and
CLEAR, I simply call apply_fbo_state. This assumes that DRAWPRIM and
CLEAR will always be used with device-render_targets[0].
With these patches, the visual tests in ddraw/d3d8/d3d9 mostly succeed
with FBO offscreen rendering. The newly added alpha blending test
still fails in ddraw, but it still does better than without the
patches.
- Allan
From 13aeb9d1a7d9593761a51912f4afd48c6c79d603 Mon Sep 17 00:00:00 2001
From: Allan Tong [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 22:54:40 -0500
Subject: wined3d: Activate GL context before making any GL calls in
stretch_rect_fbo.
---
dlls/wined3d/device.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 1793ed4..db4c5b4 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -6298,15 +6298,27 @@ void stretch_rect_fbo(IWineD3DDevice *iface,
IWineD3DSurface *src_surface, WINED
break;
}
-/* Attach src surface to src fbo */
src_swapchain = get_swapchain(src_surface);
+dst_swapchain = get_swapchain(dst_surface);
+
+/* Activate GL context for onscreen surface. If there is no onscreen
surface, then just make sure
+ there is a GL context. */
+if (src_swapchain) {
+ActivateContext(This, src_surface, CTXUSAGE_RESOURCELOAD);
+} else if (dst_swapchain) {
+ActivateContext(This, dst_surface, CTXUSAGE_RESOURCELOAD);
+} else {
+ActivateContext(This, This-lastActiveRenderTarget,
CTXUSAGE_RESOURCELOAD);
+}
+
+ENTER_GL();
+
+/* Attach src surface to src fbo */
if (src_swapchain) {
GLenum buffer;
TRACE(Source surface %p is onscreen\n, src_surface);
-ActivateContext(This, src_surface, CTXUSAGE_RESOURCELOAD);
-ENTER_GL();
GL_EXTCALL(glBindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, 0));
buffer = surface_get_gl_buffer(src_surface, src_swapchain);
glReadBuffer(buffer);
@@ -6316,23 +6328,19 @@ void stretch_rect_fbo(IWineD3DDevice *iface,
IWineD3DSurface *src_surface, WINED
src_rect-y2 = ((IWineD3DSurfaceImpl
*)src_surface)-currentDesc.Height - src_rect-y2;
} else {
TRACE(Source surface %p is offscreen\n, src_surface);
-ENTER_GL();
+
bind_fbo(iface, GL_READ_FRAMEBUFFER_EXT, This-src_fbo);
attach_surface_fbo(This, GL_READ_FRAMEBUFFER_EXT, 0, src_surface);
glReadBuffer(GL_COLOR_ATTACHMENT0_EXT);
checkGLcall(glReadBuffer());
}
-LEAVE_GL();
/* Attach dst surface to dst fbo */
-dst_swapchain = get_swapchain(dst_surface);
if (dst_swapchain) {
GLenum buffer;
TRACE(Destination surface %p is onscreen\n, dst_surface);
-ActivateContext(This, dst_surface, CTXUSAGE_RESOURCELOAD);
-ENTER_GL();
GL_EXTCALL(glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, 0));
buffer = surface_get_gl_buffer(dst_surface, dst_swapchain);
glDrawBuffer(buffer);
@@ -6343,12 +6351,6 @@ void stretch_rect_fbo(IWineD3DDevice *iface,
IWineD3DSurface *src_surface, WINED
} else {
TRACE(Destination surface %p is offscreen\n, dst_surface);
-/* No src or dst swapchain? Make sure some context is
active(multithreading) */
-if(!src_swapchain) {
-ActivateContext(This, This-lastActiveRenderTarget,
CTXUSAGE_RESOURCELOAD);
-}
-
-ENTER_GL();
bind_fbo(iface, GL_DRAW_FRAMEBUFFER_EXT, This-dst_fbo);
attach_surface_fbo(This, GL_DRAW_FRAMEBUFFER_EXT, 0, dst_surface);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
--
1.5.2.5
From acfe7545a9425483875412e89f9824f90e4542a3 Mon Sep 17 00:00:00 2001
From: Allan Tong [EMAIL PROTECTED]
Date: Sat, 15 Dec 2007 12:55:11 -0500
Subject: wined3d: Make FBO draw buffer selection in ActivateContext.
---
dlls/wined3d/context.c | 69 ---
dlls/wined3d/device.c |8 +---
dlls/wined3d/drawprim.c|6 ---
dlls/wined3d/wined3d_private.h |3 ++
4 files changed, 68 insertions(+), 18 deletions(-)
diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c
index 140ae6f..1a47513 100644
--- a/dlls/wined3d/context.c
+++ b/dlls/wined3d/context.c
@@ -893,15 +893,72 @@ void
Re: Wine and LD_PRELOAD
Sorry for answering a little late. Lionel Tricon wrote: In fact, we overload a lot of common system call from the standard libc. We have slightly modified the fackechroot library and we need to trap almost all system calls linked to the filesystem. I have just (a couple of weeks ago) started a project called Fakeroot-ng. You can get the (extremely preliminary) sources from SVN on http://sf.net/projects/fakerootng. Fakeroot-ng aims to achieve the same goal as fakeroot and fakechroot, except it uses the ptrace interface rather than the LD_PRELOAD interface, which, as you can see, has lots and lots of problems with non-standard applications. Fakeroot-ng is extremely far from being complete at the moment, but if you will find it useful, then I can use the extra programming skills. Shachar
Re: New bugzilla components.
Vitaliy Margolen [EMAIL PROTECTED] wrote: Please add these new components: wine-vdm - Wine 16-bit compatibility layer wine-comdlg - Common dialogs such as open/save/print/font (it either should be wine-commdlg, or wine-comdlg32 IMO) What's happened to the proposal to remove the wine- prefix from bugzilla components and have the components represent the dlls they belong to? -- Dmitry.
Re: winex11.drv deadkey handling and games
F Capela [EMAIL PROTECTED] wrote: A small fix to those who play games using keyboard layouts with deadkeys. Patch generated against 0.9.51 release. Wine currently don't pass keypress events to the windows executable when the keypress is either a deadkey or follows a deadkey. This makes it impossible to use any of those keys with games that use WM_KEYDOWN events to track keypresses - two examples are Guild Wars and World of Warcraft. This patch modifies dlls/winex11.drv/event.c to send all keypresses to the client, and dlls/winex11.drv/keyboard.c to implement a WM_KEYDOWN translation cache in order to correctly treat them as keys or deadkeys and keep text input with deadkeys working. Only tested with Notepad and Guild Wars. This is my first patch; don't hesitate to point any problems. This hack completely breaks native dead keys support on the X11 side. First thing to do is to write a test case which replicates the behaviour you would like to fix. -- Dmitry.
Re: New bugzilla components.
Dmitry Timoshkov wrote: Vitaliy Margolen [EMAIL PROTECTED] wrote: Please add these new components: wine-vdm - Wine 16-bit compatibility layer wine-comdlg - Common dialogs such as open/save/print/font (it either should be wine-commdlg, or wine-comdlg32 IMO) Doesn't matter they all uniquely identify the part of Wine. I'd like to have comdlg - it corresponds to the dll name without 32 part. What's happened to the proposal to remove the wine- prefix from bugzilla components and have the components represent the dlls they belong to? This would be really nice, however not sure how much work will it take. Don't think bugzilla supports renaming of the components. Might need some custom converter. Vitaliy
Re: Clear padding in the buffer due to alignment.
Robert Shearman [EMAIL PROTECTED] wrote: This isn't done in MIDL, but I think it's desirable both for silencing Valgrind warnings and for security purposes (fixes potential for leaking information to remote computers or other processes). +print_file(file, indent, memset(_StubMsg.Buffer, 0, ((long)_StubMsg.Buffer) 0x%x);\n, alignment - 1); Is it possible to make it 64-bit and Wine/Windows compatible by using ULONG_PTR instead of long? -- Dmitry.
Re: New bugzilla components.
On Dec 15, 2007 10:19 PM, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Vitaliy Margolen [EMAIL PROTECTED] wrote: Please add these new components: wine-vdm - Wine 16-bit compatibility layer wine-comdlg - Common dialogs such as open/save/print/font (it either should be wine-commdlg, or wine-comdlg32 IMO) What's happened to the proposal to remove the wine- prefix from bugzilla components and have the components represent the dlls they belong to? Yes, can someone with sufficient privileges enact what was agreed upon by the majority in this thread: http://www.winehq.org/pipermail/wine-devel/2007-October/059715.html To summarize: * Change all wine-X components to just X. * Remove the following components: - wine-rebar - wine-gui - wine-multimedia - wine-net - wine-patches - test Any bug report listed under the components that are removed would have to be set to wine-misc and eventually relabeled to the correct component (which might need to be added). I'm not a web guy, so I don't know how this would be done, but it would certainly be appreciated. Thanks, James Hawkins
Re: New bugzilla components.
James Hawkins [EMAIL PROTECTED] wrote: Yes, can someone with sufficient privileges enact what was agreed upon by the majority in this thread: http://www.winehq.org/pipermail/wine-devel/2007-October/059715.html To summarize: * Change all wine-X components to just X. * Remove the following components: - wine-rebar - wine-gui - wine-multimedia - wine-net - wine-patches - test Also remove wine-binary, wine-debug, wine-files, wine-gdi (printing), wine-gui, wine-ipc, wine-net, wine-patches, wine-ports, wine-resources, wine-winelib Rename wine-kernel - kernel32, wine-ole - ole32, wine-opengl - opengl32, wine-user - user32 Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component. -- Dmitry.
Re: New bugzilla components.
On Dec 15, 2007 10:45 PM, Dmitry Timoshkov [EMAIL PROTECTED] wrote: James Hawkins [EMAIL PROTECTED] wrote: Yes, can someone with sufficient privileges enact what was agreed upon by the majority in this thread: http://www.winehq.org/pipermail/wine-devel/2007-October/059715.html To summarize: * Change all wine-X components to just X. * Remove the following components: - wine-rebar - wine-gui - wine-multimedia - wine-net - wine-patches - test Also remove wine-binary, wine-debug, wine-files, wine-gdi (printing), wine-gui, wine-ipc, wine-net, wine-patches, wine-ports, wine-resources, wine-winelib Rename wine-kernel - kernel32, wine-ole - ole32, wine-opengl - opengl32, wine-user - user32 Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component. And if there are objections to this approach, I'd like to remind all that we decided to use keywords for generic identification, like we've successfully done with the Installer keyword. -- James Hawkins
Re: New bugzilla components.
Dmitry Timoshkov wrote: Rename wine-kernel - kernel32, wine-ole - ole32, wine-opengl - opengl32, wine-user - user32 Why do you want 32 at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else. Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component. No, please do not add all dlls, listed are fine. That will create huge clutter. Lets do it one at a time, whenever we need it.
Re: New bugzilla components.
On Dec 15, 2007 11:02 PM, Vitaliy Margolen [EMAIL PROTECTED] wrote: Dmitry Timoshkov wrote: Rename wine-kernel - kernel32, wine-ole - ole32, wine-opengl - opengl32, wine-user - user32 Why do you want 32 at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else. It's consistent with the policy: one component per module reported. What do you have against the 32? As opengl32 is a thunk, there shouldn't be any bug reports attributed to that component, and the component shouldn't exist. I'm fine with an opengl keyword if people want it, but as you said, the bug lies elsewhere. Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component. No, please do not add all dlls, listed are fine. That will create huge clutter. Lets do it one at a time, whenever we need it. I'm fine with waiting for the report to add components, but there are bug reports now that need components that do not exist. -- James Hawkins
Re: New bugzilla components.
Vitaliy Margolen [EMAIL PROTECTED] wrote: Rename wine-kernel - kernel32, wine-ole - ole32, wine-opengl - opengl32, wine-user - user32 Why do you want 32 at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else. If the component exists it should be named properly, i.e. represent the DLL it belongs to in order to avoid a possible confusion. -- Dmitry.
Re: New bugzilla components.
James Hawkins wrote: On Dec 15, 2007 11:02 PM, Vitaliy Margolen [EMAIL PROTECTED] wrote: Dmitry Timoshkov wrote: Rename wine-kernel - kernel32, wine-ole - ole32, wine-opengl - opengl32, wine-user - user32 Why do you want 32 at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else. It's consistent with the policy: one component per module reported. What do you have against the 32? As opengl32 is a thunk, there shouldn't be any bug reports attributed to that component, and the component shouldn't exist. I'm fine with an opengl keyword if people want it, but as you said, the bug lies elsewhere. Assigning openGL bugs to user32 or gdi32 doesn't make it any more clear where the problem is. Because in most case that would be somewhere between x11drv, gdi32, user32. There are lots of examples like that all over the place. Don't forget who designed all this... hm not even sure there was any designs actually. Hard assigning bugs to the dll won't make it any better then too generic categories like we have now. Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component. No, please do not add all dlls, listed are fine. That will create huge clutter. Lets do it one at a time, whenever we need it. I'm fine with waiting for the report to add components, but there are bug reports now that need components that do not exist. Then please list them.
Re: New bugzilla components.
Dmitry Timoshkov wrote: Vitaliy Margolen [EMAIL PROTECTED] wrote: Rename wine-kernel - kernel32, wine-ole - ole32, wine-opengl - opengl32, wine-user - user32 Why do you want 32 at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else. If the component exists it should be named properly, i.e. represent the DLL it belongs to in order to avoid a possible confusion. That's the part I'd like to avoid. Unless we want to list most of the subsystems in keywords, that span small parts of multiple dlls.
Re: New bugzilla components.
Vitaliy Margolen [EMAIL PROTECTED] wrote: If the component exists it should be named properly, i.e. represent the DLL it belongs to in order to avoid a possible confusion. That's the part I'd like to avoid. Unless we want to list most of the subsystems in keywords, that span small parts of multiple dlls. In the vast majority of cases a bug belongs to a particular DLL, not a group of DLLs, in very rare cases the keywords are supposed to help with identification of the component. -- Dmitry.
Re: New bugzilla components.
On Dec 15, 2007 11:27 PM, Vitaliy Margolen [EMAIL PROTECTED] wrote: James Hawkins wrote: On Dec 15, 2007 11:02 PM, Vitaliy Margolen [EMAIL PROTECTED] wrote: Dmitry Timoshkov wrote: Rename wine-kernel - kernel32, wine-ole - ole32, wine-opengl - opengl32, wine-user - user32 Why do you want 32 at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else. It's consistent with the policy: one component per module reported. What do you have against the 32? As opengl32 is a thunk, there shouldn't be any bug reports attributed to that component, and the component shouldn't exist. I'm fine with an opengl keyword if people want it, but as you said, the bug lies elsewhere. Assigning openGL bugs to user32 or gdi32 doesn't make it any more clear where the problem is. Because in most case that would be somewhere between x11drv, gdi32, user32. There are lots of examples like that all over the place. Don't forget who designed all this... hm not even sure there was any designs actually. Hard assigning bugs to the dll won't make it any better then too generic categories like we have now. Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component. No, please do not add all dlls, listed are fine. That will create huge clutter. Lets do it one at a time, whenever we need it. I'm fine with waiting for the report to add components, but there are bug reports now that need components that do not exist. Then please list them. As Dmitry already said: ntdl, oleaut32, rpcrt4. Searching through bugzilla: wininet, wintrust, secur32, advpack, hhctrl, imagehlp, mshtml, shlwapi, urlmon. There are probably more, but that's a good starter list. -- James Hawkins
