Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com>
---
This fixes test failures on Win7, Geforce 9600.
The MS doc I am referring to is https://support.microsoft.com/en-us/topic/screen-refresh-rate-in-windows-do….
---
dlls/ddraw/tests/ddraw2.c | 3 ++-
dlls/ddraw/tests/ddraw4.c | 3 ++-
dlls/ddraw/tests/ddraw7.c | 11 ++++++++++-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/dlls/ddraw/tests/ddraw2.c b/dlls/ddraw/tests/ddraw2.c
index 00c8f820edb..8a6c4b41ac1 …
[View More]100644
--- a/dlls/ddraw/tests/ddraw2.c
+++ b/dlls/ddraw/tests/ddraw2.c
@@ -15114,8 +15114,9 @@ static HRESULT CALLBACK find_different_mode_callback(DDSURFACEDESC *surface_desc
if (U1(U4(*surface_desc).ddpfPixelFormat).dwRGBBitCount != registry_mode.dmBitsPerPel)
return DDENUMRET_OK;
+ /* See comment in ddraw7 about the frequency. */
if (surface_desc->dwWidth != param->old_width && surface_desc->dwHeight != param->old_height &&
- surface_desc->dwRefreshRate != param->old_frequency)
+ !compare_uint(surface_desc->dwRefreshRate, param->old_frequency, 1))
{
param->new_width = surface_desc->dwWidth;
param->new_height = surface_desc->dwHeight;
diff --git a/dlls/ddraw/tests/ddraw4.c b/dlls/ddraw/tests/ddraw4.c
index a8b68b8a20b..c229ab66341 100644
--- a/dlls/ddraw/tests/ddraw4.c
+++ b/dlls/ddraw/tests/ddraw4.c
@@ -18151,8 +18151,9 @@ static HRESULT CALLBACK find_different_mode_callback(DDSURFACEDESC2 *surface_des
if (U1(U4(*surface_desc).ddpfPixelFormat).dwRGBBitCount != registry_mode.dmBitsPerPel)
return DDENUMRET_OK;
+ /* See comment in ddraw7 about the frequency. */
if (surface_desc->dwWidth != param->old_width && surface_desc->dwHeight != param->old_height &&
- surface_desc->dwRefreshRate != param->old_frequency)
+ !compare_uint(surface_desc->dwRefreshRate, param->old_frequency, 1))
{
param->new_width = surface_desc->dwWidth;
param->new_height = surface_desc->dwHeight;
diff --git a/dlls/ddraw/tests/ddraw7.c b/dlls/ddraw/tests/ddraw7.c
index f4388296702..18ebf849391 100644
--- a/dlls/ddraw/tests/ddraw7.c
+++ b/dlls/ddraw/tests/ddraw7.c
@@ -18417,8 +18417,17 @@ static HRESULT CALLBACK find_different_mode_callback(DDSURFACEDESC2 *surface_des
if (U1(U4(*surface_desc).ddpfPixelFormat).dwRGBBitCount != registry_mode.dmBitsPerPel)
return DDENUMRET_OK;
+ /* Windows will advertise 59hz (for 59.94) and 60hz (for proper 60hz) on monitors that support
+ * only one of the two (usually 59.94). If an application requests 60hz windows will apply 59.94.
+ * Thus if we think we found a different refresh rate, we get 59hz instead of the 60hz we
+ * requested.
+ *
+ * The same is true of other 1% slowed-down TV compatible refresh rates according to a Microsoft
+ * support document: 23.976 vs 24, 30, 48, 72 and 120 hz. It can be reproduced by attempting to
+ * set 60hz in the advanced display properties manually. Usually the restriction to one refresh
+ * rate applies to laptop panels. */
if (surface_desc->dwWidth != param->old_width && surface_desc->dwHeight != param->old_height &&
- surface_desc->dwRefreshRate != param->old_frequency)
+ !compare_uint(surface_desc->dwRefreshRate, param->old_frequency, 1))
{
param->new_width = surface_desc->dwWidth;
param->new_height = surface_desc->dwHeight;
--
2.34.1
[View Less]
We no longer link to mingwex.
Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>
---
dlls/user32/user_main.c | 5 -----
1 file changed, 5 deletions(-)
update_travellog() in order to clear forward history calls free_travellog_entry() to
invalidate forward history entries, and when later an entry gets reused entry->stream
contains a no longer valid pointer.
This is an alternative patch that fixes a crash while navigating html help file
that I have here.
Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru>
---
dlls/ieframe/dochost.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/dlls/ieframe/dochost.c b/dlls/…
[View More]ieframe/dochost.c
index 042417b5b17..1ba31c552ed 100644
--- a/dlls/ieframe/dochost.c
+++ b/dlls/ieframe/dochost.c
@@ -384,9 +384,12 @@ static LRESULT WINAPI doc_view_proc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM l
static void free_travellog_entry(travellog_entry_t *entry)
{
- if(entry->stream)
+ if(entry->stream) {
IStream_Release(entry->stream);
+ entry->stream = NULL;
+ }
heap_free(entry->url);
+ entry->url = NULL;
}
static IStream *get_travellog_stream(DocHost *This)
--
2.34.1
[View Less]
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com>
---
Still not sure what the difference between ncacn_np and ncalrpc is, but
this seems to just work. The services manager also uses ncacn_np instead
of ncalrpc. I don't think we want to rely on rpcss.exe, for these PnP
notifications, as it creates an additional service dependency which is
going to be hard to solve.
FWIW, relying on rpcss.exe also causes some prefix shutdown issues, as
the PnP device removal involves sending some …
[View More]notifications. As rpcss.exe
usually exits at the same time, plugplay.exe is then waiting on it and
may block if it's not responding anymore.
This was resolved for a while by wineserver killing and reaping the
services after its shutdown timeout, but caused an additional 1s delay,
and later with 7f749d58d9cbb0b3d54f2db75dbd88695b20901a, by the service
manager terminating all the service processes on shutdown instead.
For proper service shutdown, the manager should instead wait for the
services to exit, and in this case not relying on rpcss.exe will help
plugplay exit itself quickly.
dlls/ntoskrnl.exe/pnp.c | 2 +-
dlls/sechost/service.c | 2 +-
include/wine/plugplay.idl | 1 +
programs/plugplay/main.c | 2 +-
4 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/dlls/ntoskrnl.exe/pnp.c b/dlls/ntoskrnl.exe/pnp.c
index 6d53d79267e..8d3481b2a72 100644
--- a/dlls/ntoskrnl.exe/pnp.c
+++ b/dlls/ntoskrnl.exe/pnp.c
@@ -1084,7 +1084,7 @@ void pnp_manager_start(void)
{
static const WCHAR driver_nameW[] = {'\\','D','r','i','v','e','r','\\','P','n','p','M','a','n','a','g','e','r',0};
WCHAR endpoint[] = L"\\pipe\\wine_plugplay";
- WCHAR protseq[] = L"ncalrpc";
+ WCHAR protseq[] = L"ncacn_np";
UNICODE_STRING driver_nameU;
RPC_WSTR binding_str;
NTSTATUS status;
diff --git a/dlls/sechost/service.c b/dlls/sechost/service.c
index e6f4eb75db0..4dfb40b4bac 100644
--- a/dlls/sechost/service.c
+++ b/dlls/sechost/service.c
@@ -1988,7 +1988,7 @@ struct device_notify_registration
static DWORD WINAPI device_notify_proc( void *arg )
{
WCHAR endpoint[] = L"\\pipe\\wine_plugplay";
- WCHAR protseq[] = L"ncalrpc";
+ WCHAR protseq[] = L"ncacn_np";
RPC_WSTR binding_str;
DWORD err = ERROR_SUCCESS;
struct device_notify_registration *registration;
diff --git a/include/wine/plugplay.idl b/include/wine/plugplay.idl
index 8123b733ad1..a3e7b04bf30 100644
--- a/include/wine/plugplay.idl
+++ b/include/wine/plugplay.idl
@@ -20,6 +20,7 @@ import "wtypes.idl";
[
uuid(57c680ac-7bce-4f39-97fd-ffea566754d5),
+ endpoint("ncacn_np:[\\pipe\\wine_plugplay]"),
implicit_handle(handle_t plugplay_binding_handle)
]
interface plugplay
diff --git a/programs/plugplay/main.c b/programs/plugplay/main.c
index 1156cb9f036..366be9c2b46 100644
--- a/programs/plugplay/main.c
+++ b/programs/plugplay/main.c
@@ -200,7 +200,7 @@ static DWORD WINAPI service_handler( DWORD ctrl, DWORD event_type, LPVOID event_
static void WINAPI ServiceMain( DWORD argc, LPWSTR *argv )
{
unsigned char endpoint[] = "\\pipe\\wine_plugplay";
- unsigned char protseq[] = "ncalrpc";
+ unsigned char protseq[] = "ncacn_np";
SERVICE_STATUS status;
RPC_STATUS err;
--
2.34.1
[View Less]
Crosstests are compiled with MinGW and linked against msvcrt, which
doesn't necessarily support ANSI stdio format modifiers like "ll".
Still, MinGW headers default to emit "ll" for format macros like
PRIu64, which is wrong and triggers a lot of warnings in recent enough
versions of GCC.
Signed-off-by: Giovanni Mascellani <gmascellani(a)codeweavers.com>
---
I am not completely sure that the explanation is correct and the solution
is the best possible, but, at least in my setup, no …
[View More]warnings are emitted
and I64 is generated (which is probably the most compatible choice when
linking against msvcrt), so I believe the result is correct.
Provided that my explanation is correct, I'd wish to directly solve the
problem in MinGW headers, but at this point I am still too confused by
the GCC/MinGW ecosystem to understand what is to be done.
---
Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index a3ec6850..4c1911bb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -386,7 +386,7 @@ dummy-vkd3d-version:
## Cross-compile tests
cross_implibs = crosslibs/d3d12
CROSS_CPPFLAGS = -I$(srcdir)/include -I$(srcdir)/include/private -I$(builddir)/include
-CROSS_CFLAGS = -g -O2 -Wall -municode ${CROSS_CPPFLAGS}
+CROSS_CFLAGS = -g -O2 -Wall -municode ${CROSS_CPPFLAGS} -D__USE_MINGW_ANSI_STDIO=0
EXTRA_DIST += $(cross_implibs:=.cross32.def) $(cross_implibs:=.cross64.def)
if HAVE_CROSSTARGET32
--
2.34.1
[View Less]
Does that mean just because no person has made an bugreport about it yet,
it isn't needed now? and then in the future people with the issue will have
to wait however many months for a full patch?
seems a bit asinine and silly... Im thinking its time to fork wine into a
less strict development enviroment where developers can code more freely
not only deal with bugs releasted to games.. which linux shoulndt be used
for anyway.
On Tue, Jan 25, 2022 at 3:42 PM Marvin <testbot(a)winehq.org…
[View More]> wrote:
> Thank you for your contribution to Wine!
>
> This is an automated notification to let you know that your patch has
> been reviewed and its status set to "Rejected".
>
> This means that the patch has been rejected by a reviewer. You should
> have received a mail explaining why it was rejected. You need to fix
> the issue and resend the patch, or if you are convinced that your
> patch is good as is, you should reply to the rejection message with
> your counterarguments.
>
> If you do not understand the reason for this status, disagree with our
> assessment, or are simply not sure how to proceed next, please ask for
> clarification by replying to this email.
>
[View Less]