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)

2007-12-15 Thread Kai Blin
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

2007-12-15 Thread Francois Gouget
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

2007-12-15 Thread Stefan Dösinger
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.

2007-12-15 Thread Vitaliy Margolen
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

2007-12-15 Thread Allan Tong
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

2007-12-15 Thread Shachar Shemesh
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.

2007-12-15 Thread Dmitry Timoshkov
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

2007-12-15 Thread Dmitry Timoshkov
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.

2007-12-15 Thread Vitaliy Margolen
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.

2007-12-15 Thread Dmitry Timoshkov
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.

2007-12-15 Thread James Hawkins
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.

2007-12-15 Thread Dmitry Timoshkov
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.

2007-12-15 Thread James Hawkins
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.

2007-12-15 Thread Vitaliy Margolen
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.

2007-12-15 Thread James Hawkins
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.

2007-12-15 Thread Dmitry Timoshkov
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.

2007-12-15 Thread Vitaliy Margolen
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.

2007-12-15 Thread Vitaliy Margolen
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.

2007-12-15 Thread Dmitry Timoshkov
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.

2007-12-15 Thread James Hawkins
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