On 06/30/2013 11:29 PM, Ričardas Barkauskas wrote:
> ---
> dlls/winex11.drv/opengl.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
>
> 0001-winex11.drv-When-skipping-unknown-attribute-also-skip-.txt
>
>
> diff --git a/dlls/winex11.drv/opengl
Christopher Cope writes:
> Can someone provide some follow up on this? There is a problem with
> the current code. The way I fixed it allows the end user to set the
> mode with xinput. That seems preferable to having to apply a patch to
> wine if the mouse in use doesn't work.
I'd suggest to fil
Can someone provide some follow up on this? There is a problem with the current
code. The way I fixed it allows the end user to set the mode with xinput. That
seems preferable to having to apply a patch to wine if the mouse in use doesn't
work.
Christopher Cope wrote:
>The way I set it was to
The way I set it was to enable with the original labels or absolute label with
relative mode. My mouse has absolute labels, but with relative mode set. My
mouse won't work correctly without this patch. Relative and absolute mode can
be set relatively easily.
Alexandre Julliard wrote:
>Christo
Christopher Cope writes:
> @@ -286,8 +286,10 @@ static void enable_xinput2(void)
> class->number, class->min, class->max, class->resolution,
> class->mode,
> XGetAtomName( data->display, class->label ));
> if (class->label == x11drv_atom( Rel_
On 05/01/2013 07:38 AM, Christopher Cope wrote:
On 05/01/2013 07:21 AM, Christopher Cope wrote:
I am unsure how the "enum x11drv_atoms" in the file
dlls/winex11.dev/x11drv.h works. My /usr/include/Xatom.h defines
XA_LAST_PREDEFINED as 68. Presumably, therefore XATOM_Rel_X and
XATOM_Rel_X shoul
On 05/01/2013 05:38 AM, Christopher Cope wrote:
On 05/01/2013 07:21 AM, Christopher Cope wrote:
I am unsure how the "enum x11drv_atoms" in the file
dlls/winex11.dev/x11drv.h works. My /usr/include/Xatom.h defines
XA_LAST_PREDEFINED as 68. Presumably, therefore XATOM_Rel_X and
XATOM_Rel_X shou
On 05/01/2013 07:21 AM, Christopher Cope wrote:
I am unsure how the "enum x11drv_atoms" in the file
dlls/winex11.dev/x11drv.h works. My /usr/include/Xatom.h defines
XA_LAST_PREDEFINED as 68. Presumably, therefore XATOM_Rel_X and
XATOM_Rel_X should be 81 and 82 respectively. However, when I dump
is
appreciated thank you.
I've written a quick C program to print those enums (it's attached;
compile with "gcc -o xatomdump xatomdump.c -I wine/dlls/winex11.drv -I
wine/include") and I get this output:
FIRST_XATOM=69
XATOM_Rel_X=81
XATOM_Rel_Y=82
So, your guess is ri
I am unsure how the "enum x11drv_atoms" in the file
dlls/winex11.dev/x11drv.h works. My /usr/include/Xatom.h defines
XA_LAST_PREDEFINED as 68. Presumably, therefore XATOM_Rel_X and
XATOM_Rel_X should be 81 and 82 respectively. However, when I dump the
values I get 195 and 196. I am attempting t
"Cope, Christopher Edward" wrote:
> @@ -1638,16 +1636,14 @@ static void X11DRV_RawMotion( XGenericEventCookie
> *xev )
> if (XIMaskIsSet( event->valuators.mask, class->number ))
> {
> double val = *values++;
> -if (class->label == x11drv
Simon Lipp writes:
> @@ -389,6 +389,10 @@ static int process_events( Display *display, Bool
> (*filter)(Display*, XEvent*,XP
> count++;
> if (XFilterEvent( &event, None ))
> {
> +KeySym keysym = 0;
> +XLookupString(&event.xkey, NULL, 0, &keysym,
> > > Wine should never generate WM_DEADCHAR message, it relies in the
> > > driver to handle dead keys and generate final events.
> >
> > I’m sorry but I fail to see any incompatibility between the two
> > alternatives. Wine can generate WM_DEADCHAR messages AND let X/input
> > method handle the
Simon Lipp wrote:
> > That's how it's supposed to work.
>
> But it doesn’t work that way under Windows. Shouldn’t Wine try to stick
> to Windows behavior as close as possible ?
It depends.
> > Wine should never generate WM_DEADCHAR message, it relies in the
> > driver to handle dead keys and
On Apr 16, 2013, at 3:43 AM, Simon Lipp wrote:
>> That's how it's supposed to work.
>
> But it doesn’t work that way under Windows. Shouldn’t Wine try to stick
> to Windows behavior as close as possible ?
>
>> Wine should never generate WM_DEADCHAR message, it relies in the
>> driver to handle
> That's how it's supposed to work.
But it doesn’t work that way under Windows. Shouldn’t Wine try to stick
to Windows behavior as close as possible ?
> Wine should never generate WM_DEADCHAR message, it relies in the
> driver to handle dead keys and generate final events.
I’m sorry but I fail
Simon Lipp wrote:
> + * Moreover, let dead chars be processed or we will never have
> + * WM_DEADCHAR events
That's how it's supposed to work. Wine should never generate WM_DEADCHAR
message, it relies in the driver to handle dead keys and generate final
events. X11 even h
On Sun, Dec 16, 2012 at 2:31 PM, Austin English wrote:
> --
> -Austin
Wrong macro, please ignore.
--
-Austin
On 1 August 2012 17:47, Patrick Rudolph wrote:
> Am 01.08.2012 15:42, schrieb Henri Verbeet:
>> Mostly for reference, what driver are you using? Have you explicitly
>> configured a primary display at all (either through the xorg.conf
>> "Primary" option for the monitor, or with the xrandr utility)
Am 01.08.2012 15:42, schrieb Henri Verbeet:
On 30 July 2012 22:05, wrote:
As far as I understood CRTC 0 is disabled, because it is only
capable of
generating analog video signals. I'm using a HDMI monitor, which is
controlled by CRTC 1. To use multihead (not clone), you have to
connect a
ana
On 30 July 2012 22:05, wrote:
> As far as I understood CRTC 0 is disabled, because it is only capable of
> generating analog video signals. I'm using a HDMI monitor, which is
> controlled by CRTC 1. To use multihead (not clone), you have to connect a
> analog (VGA) and digital monitor (in my case
C and each CRTC will show a different part of the same screen. With this in mind every active CRTC should be listed as "native Windows monitor".Regards,PatrickVon: "Henri Verbeet" An: "Alexandre Julliard" Cc: "Patrick Rudolph" , "wine-devel@winehq.org"
On 30 July 2012 20:13, Alexandre Julliard wrote:
> This clearly needs a helper function.
>
I'm not sure if this really makes sense to begin with. CRTC 0 is
supposed to be the primary display. With proper multihead support we'd
be able to enumerate the other display as well, and change modes on
the
Patrick Rudolph writes:
> @@ -279,15 +279,34 @@ static int xrandr12_get_current_mode(void)
> return 0;
> }
>
> -if (!resources->ncrtc || !(crtc_info = pXRRGetCrtcInfo( gdi_display,
> resources, resources->crtcs[0] )))
> +if (!resources->ncrtc)
> {
> pXRRFree
Dmitry Timoshkov wrote:
> > Windows always generates VK_DECIMAL for Del/. on a keypad while some
> > X11 keyboard layouts generate XK_KP_Separator instead of XK_KP_Decimal
> > in order to produce a locale dependent numeric separator.
> >
> > X11 handles XK_KP_Separator same way as XK_KP_Decimal
Dmitry Timoshkov wrote:
> Windows always generates VK_DECIMAL for Del/. on a keypad while some
> X11 keyboard layouts generate XK_KP_Separator instead of XK_KP_Decimal
> in order to produce a locale dependent numeric separator.
>
> X11 handles XK_KP_Separator same way as XK_KP_Decimal for all te
Vitaliy Margolen writes:
> On 03/27/2012 08:04 AM, Alexandre Julliard wrote:
>> Vitaliy Margolen writes:
>>
>>> Dinput needs to talk to x11drv directly to get xi2 events. Same for
>>> requests to clip cursor in exclusive mode. The current method of using
>>> hooks can stay for backwards compatib
On 03/27/2012 08:04 AM, Alexandre Julliard wrote:
Vitaliy Margolen writes:
Dinput needs to talk to x11drv directly to get xi2 events. Same for
requests to clip cursor in exclusive mode. The current method of using
hooks can stay for backwards compatibility.
I'm not at all convinced that this
Vitaliy Margolen writes:
> Dinput needs to talk to x11drv directly to get xi2 events. Same for
> requests to clip cursor in exclusive mode. The current method of using
> hooks can stay for backwards compatibility.
I'm not at all convinced that this would be an improvement, particularly
since you
On 03/27/2012 02:29 AM, Alexandre Julliard wrote:
Vitaliy Margolen writes:
If you have suggestions on how to do this differently please explain
them.
Dinput needs to talk to x11drv directly to get xi2 events. Same for requests
to clip cursor in exclusive mode. The current method of using hoo
Vitaliy Margolen writes:
> If Dmitry fixes a real bug that means dinput shouldn't depend on
> broken behavior. And I'm questioning that exact behavior which
> shouldn't have been there in the first place. Dinput's exclusive mode
> works regardless of what ClipCursor is set to.
Of course the beha
On 03/26/2012 08:15 AM, Alexandre Julliard wrote:
Vitaliy Margolen writes:
On 03/26/2012 06:14 AM, Alexandre Julliard wrote:
Dmitry Timoshkov writes:
This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass
on a system without XInput2.
It will break dinput, we rely on t
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> > Is that a way how dinput detects xinput2 support? Or is that a general
>> > approach to detect if a driver supports mouse clipping? How did it work
>> > before?
>>
>> It's used to detect that xinput2 is not supported.
>
> Apparently di
Alexandre Julliard wrote:
> > Is that a way how dinput detects xinput2 support? Or is that a general
> > approach to detect if a driver supports mouse clipping? How did it work
> > before?
>
> It's used to detect that xinput2 is not supported.
Apparently dinput shouldn't rely on this, but I don
Dmitry Timoshkov writes:
> Is that a way how dinput detects xinput2 support? Or is that a general
> approach to detect if a driver supports mouse clipping? How did it work
> before?
It's used to detect that xinput2 is not supported.
--
Alexandre Julliard
julli...@winehq.org
Vitaliy Margolen writes:
> On 03/26/2012 06:14 AM, Alexandre Julliard wrote:
>> Dmitry Timoshkov writes:
>>
>>> This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass
>>> on a system without XInput2.
>>
>> It will break dinput, we rely on the clip rectangle being reset.
>>
> I
On 03/26/2012 06:14 AM, Alexandre Julliard wrote:
Dmitry Timoshkov writes:
This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass
on a system without XInput2.
It will break dinput, we rely on the clip rectangle being reset.
I'd say it again, dinput should not warp mouse u
Alexandre Julliard wrote:
> > This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass
> > on a system without XInput2.
>
> It will break dinput, we rely on the clip rectangle being reset.
Is that a way how dinput detects xinput2 support? Or is that a general
approach to detect
Dmitry Timoshkov writes:
> This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass
> on a system without XInput2.
It will break dinput, we rely on the clip rectangle being reset.
--
Alexandre Julliard
julli...@winehq.org
Aric Stewart wrote:
> + TRACE("found scan=%04x keyc=%u keysym=%04lu
> modified_string=%s\n",
> + scanCode, keyc, keys, debugstr_an(name,idx-name));
Please keep printing a keysym in hex, printing it in decimal (especially with
leading zeros) is not useful
Aric Stewart wrote:
> That is why I am questioning, The one in the TRACE statement
>
> 1) is the same as used later in the code, so retains consistency.
> 2) generates a compiler warning if i remove it so appears to be useful.
For sure there are other ways to avoid compiler warnings, one of th
That is why I am questioning, The one in the TRACE statement
1) is the same as used later in the code, so retains consistency.
2) generates a compiler warning if i remove it so appears to be useful.
-aric
On 12/01/20 10:57, Dmitry Timoshkov wrote:
Aric Stewart wrote:
which cast are you fin
Aric Stewart wrote:
> which cast are you finding to be unneccessary?
Are there that many of them? I see only one.
--
Dmitry.
which cast are you finding to be unneccessary?
-aric
On 12/01/20 10:26, Dmitry Timoshkov wrote:
Aric Stewart wrote:
The problem is that there is no XK keycode for just Shift, Control or
Menu so X11DRV_MapVirtualKeyEx maps them to Shift_L, etc. As a result
the string XKeysymToString returns i
Aric Stewart wrote:
> The problem is that there is no XK keycode for just Shift, Control or
> Menu so X11DRV_MapVirtualKeyEx maps them to Shift_L, etc. As a result
> the string XKeysymToString returns is a string with a _L or _R at the
> end, even if the "don't care" bit is set.
>
> try4: For
Aric Stewart wrote:
> +char* idx = strrchr(name,'_');
> +if (idx)
> +{
> +if (strcasecmp(idx,"_r")==0 || strcasecmp(idx,"_l")==0)
> +{
> +INT rc = 0;
> +TRACE("found scan=%04x keyc=%u keysy
On 1/17/12 10:18 PM, Vitaliy Margolen wrote:
On 01/17/2012 09:32 AM, Aric Stewart wrote:
The problem is that there is no XK keycode for just Shift, Control or Menu
so X11DRV_MapVirtualKeyEx maps them to Shift_L, etc. As a result the string
XKeysymToString returns is a string with a _L or _R at
On 01/17/2012 09:32 AM, Aric Stewart wrote:
>
> The problem is that there is no XK keycode for just Shift, Control or Menu
> so X11DRV_MapVirtualKeyEx maps them to Shift_L, etc. As a result the string
> XKeysymToString returns is a string with a _L or _R at the end, even if the
> "don't care" b
On Thu, Oct 13, 2011 at 06:08, Daniel wrote:
> Fixes on-screen portion of http://bugs.winehq.org/show_bug.cgi?id=26091
You should configure your mail/git config so your real name appears in
patches, and not just your first name "Daniel"
Daniel writes:
> @@ -42,29 +42,23 @@ HPEN X11DRV_SelectPen( PHYSDEV dev, HPEN hpen )
> X11DRV_PDEVICE *physDev = get_x11drv_dev( dev );
> LOGPEN logpen;
> int i;
> +EXTLOGPEN *elp = NULL;
> +INT size = GetObjectW( hpen, 0, NULL );
>
> -if (!GetObjectW( hpen, sizeof(lo
On Mon, Oct 10, 2011 at 22:46, wrote:
> ---
> dlls/winex11.drv/keyboard.c | 563
> ++-
> 1 files changed, 499 insertions(+), 64 deletions(-)
Please follow patch submission rules from
http://wiki.winehq.org/SubmittingPatches
Hi developers,
I've just sent my first patch I would like to see in mainline. I did quite
some efforts to verify that my patch is correct by doing extensive compares
with Windows, the wine before and the patched wine as well as a special
testing version of wine.
I want to fix this bug http://b
On Jun 14, 2011, at 12:40 AM, Vincent Povirk wrote:
>> Is it necessary to test QS_HOTKEY in dlls/winex11.drv/event.c:filter_event,
>> where QS_KEY is currently tested? If somebody calls
>> MsgWaitForMultipleObjectsEx with QS_HOTKEY but not QS_KEY, shouldn't
>>
Scott Talbert writes:
> Hello,
>
> The below patch resolves an issue (BZ# 27473) where the window manager
> removes window decorations and Wine restores them. The code in the
> patch checks to see whether the window decorations have been modified
> and if so,
> it does not modify them further.
On Jun 13, 2011, at 2:07 PM, Vincent Povirk wrote:
> <0005-winex11.drv-Grab-registered-hotkeys-in-the-X-server.txt>
Is it necessary to test QS_HOTKEY in dlls/winex11.drv/event.c:filter_event,
where QS_KEY is currently tested? If somebody calls
MsgWaitForMultipleObjectsEx with QS_H
Dmitry Timoshkov writes:
> This patch reverts a part of 61e50e15ba45ad54655f98619f5ef33917033165 and
> fixes the regression reported in the bug 26670.
This will cause spurious task bar entries in many apps.
--
Alexandre Julliard
julli...@winehq.org
The first part of the patch was fine, the only concern is the error
code. Since there is no WGL standard, the error codes thrown by
different drivers can be inconsistent :( I'm not sure if it is better
to set an error code at all or not. I'm not sure what I would
prefer...
Roderick
On Tue, Mar 29
On Tue, Mar 29, 2011 at 5:58 PM, Matteo Bruni wrote:
> 2011/3/29 Roderick Colenbrander :
>> The fact that a pixel format is not set on the physDev doesn't
>> necessarily mean it is invalid, it just means SetPixelFormat wasn't
>> called on it. Though slightly earlier in wglMakeCurrent we already
>>
2011/3/29 Roderick Colenbrander :
> The fact that a pixel format is not set on the physDev doesn't
> necessarily mean it is invalid, it just means SetPixelFormat wasn't
> called on it. Though slightly earlier in wglMakeCurrent we already
> catch that situation when compare the pixel format of the c
2011/3/29 Roderick Colenbrander :
> I'm not sure if the only value error wglMakeCurrent should return is
> INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid
> context? The return value may be similar, but don't remember for sure.
>
> Roderick
Practically speaking it seems to be ve
The fact that a pixel format is not set on the physDev doesn't
necessarily mean it is invalid, it just means SetPixelFormat wasn't
called on it. Though slightly earlier in wglMakeCurrent we already
catch that situation when compare the pixel format of the context and
the hdc.
Is there not somethin
I'm not sure if the only value error wglMakeCurrent should return is
INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid
context? The return value may be similar, but don't remember for sure.
Roderick
On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni wrote:
>
>
>
>
>
On Wednesday, March 23, 2011 9:00:25 PM Joshua Beck wrote:
> This patch was made against the origin, so if you've applied my previous
> patch, remove that one before applying this one.
> This patch makes the error message use ERR_(winediag) instead of just
> ERR and is closer in style to the other
Hi Joshua,
Was about to submit a similar patch (had a few tiny fixes in my tree
left), but this patch is mostly fine with me. Except I would print to
'winediag' like some of the other errors for software / indirect
rendering are doing. So do something like 'Unable to active OpenGL
context, like so
On 03/22/2011 05:55 AM, Henri Verbeet wrote:
On 22 March 2011 08:59, Joshua Beck wrote:
What do you think?
Does the pglXMakeCurrent() call a few lines above succeed? We should
probably check the result of that call.
It doesn't succeed. I added some FIXMEs to the code to get output f
On 22 March 2011 08:59, Joshua Beck wrote:
> What do you think?
>
Does the pglXMakeCurrent() call a few lines above succeed? We should
probably check the result of that call. Nevertheless, this means
something is broken with your GL setup, so while the error handling
could be improved, it's not go
[Please do not omit wine-devel@winehq.org when replying]
Joshua Beck wrote:
> > What OpenGL driver are you using? glGetString(GL_EXTENSIONS) returning NULL
> > might be a driver bug.
> >
> I'm using an nvidia binary driver (260.36.19 I think). Thing is I'm
> running Debian amd64 and I compi
Joshua Beck wrote:
> 350: str = (const char *) pglGetString(GL_EXTENSIONS);
> 351: WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0,
> strlen(str)+1);
>
>
> From this it's obvious that pglGetString is returning a null pointer.
What OpenGL driver are you using? glGetStri
ion: page fault on read access to 0x in 32-bit code
(0xf748c110).
...
Backtrace:
=>0 0xf748c110 in libc.so.6 (+0x74110) (0x0032e670)
1 0x7e59fae9 X11DRV_WineGL_InitOpenglInfo+0x353()
[/home/jb/programs/wine-git/dlls/winex11.drv/opengl.c:351] in winex11
(0x0032e670)
On 01/03/11 17:13, John Klehm wrote:
Nice find on this code path being able to run without loading xinput.
It was as a result of a user sending me some crash logs. I never managed
to reproduce this issue. I don't even have access to a tablet to test.
My patch was pretty much a result of "NUL
On Mon, Feb 28, 2011 at 8:50 PM, Peter Urbanec wrote:
> ---
> dlls/winex11.drv/wintab.c | 13 ++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
>
Nice find on this code path being able to run without loading xinput.
I have a couple comments:
You don't nee
Daniel writes:
> @@ -54,11 +56,13 @@ HPEN CDECL X11DRV_SelectPen( X11DRV_PDEVICE *physDev,
> HPEN hpen )
> elp = HeapAlloc( GetProcessHeap(), 0, size );
>
> GetObjectW( hpen, size, elp );
> -/* FIXME: add support for user style pens */
> +
> logpen.lopnStyle
OK, actually it looks like the problem is already in X11DRV_SelectPen
and is unlikely to occur, so my patches are good.
Still, I'm thinking that if GetObjectW fails
(http://source.winehq.org/source/dlls/winex11.drv/pen.c#L45) then we
should immediately exit the function returning zero rather
grr, please disregard previous patches. I've discovered a problem that
can lead to use of un-initialized values.
Daniel
On 02/15/2011 01:09 AM, Daniel wrote:
> Clean up per Vitaliy's direction. Also found a FIXME comment that needed
> to be removed.
>
> Daniel
>
>
>
On 02/14/2011 03:55 AM, Daniel wrote:
Hello all. This only covers the screen. Support still needs to be added
to printers.
+ case PS_USERSTYLE: {
+for(i = 0; i < physDev->pen.dash_len ; i++) {
Please follow file style - curly braces on separate line. No braces for
single lin
13.02.2011 00:06, Alexandre Julliard writes:
Alexander Lakhin writes:
I've checked XWMHints just before XMapWindow call and received the correct
initial_state (IconicState) and flags (StateHint set) there.
But the window still displayed not in a minimized state. To isolate the issue I
tried
Alexander Lakhin writes:
+data->iconic = (new_style& WS_MINIMIZE) != 0;
+
if (!data->embedded)
{
update_net_wm_states( display, data );
sync_window_style( display, data );
wine_tsx11_lock();
XMapWindow( display, data->whole_window );
+
Alexander Lakhin writes:
> I've checked XWMHints just before XMapWindow call and received the correct
> initial_state (IconicState) and flags (StateHint set) there.
> But the window still displayed not in a minimized state. To isolate the issue
> I tried the following code snippet:
> ...
> XW
Alexander Lakhin writes:
> +data->iconic = (new_style & WS_MINIMIZE) != 0;
> +
> if (!data->embedded)
> {
> update_net_wm_states( display, data );
> sync_window_style( display, data );
> wine_tsx11_lock();
> XMapWindow( display, data->whole_window
I'm not entirely sure on how to do this properly. Making it an ERR
would be too loud for applications that never use s3tc textures, as a
WARN it's never going to be seen unless you look at the debug channel.
Printing a message in wined3d in CreateSurface() would probably work,
but the resulting ch
On 3 February 2011 01:00, Tobias Jakobi wrote:
> *bumping*
>
> This patch never went into master, although it's _very_ important. Wine
> users see a lot of D3D problems (mostly missing textures) since mesa drivers
> don't support s3tc "out-of-the-box" (libtxc_dxtn needs to be available).
> This le
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> > I looks like the default clip region created by ExtSelectClipRgn() uses
>> > the dimensions of the selected bitmap, and it's not large enough.
>>
>> That's a window DC, it doesn't have a selected bitmap.
>
> You are right. The app crea
Alexandre Julliard wrote:
> > I looks like the default clip region created by ExtSelectClipRgn() uses
> > the dimensions of the selected bitmap, and it's not large enough.
>
> That's a window DC, it doesn't have a selected bitmap.
You are right. The app creates very large child window to fit th
Dmitry Timoshkov writes:
> I looks like the default clip region created by ExtSelectClipRgn() uses
> the dimensions of the selected bitmap, and it's not large enough.
That's a window DC, it doesn't have a selected bitmap.
--
Alexandre Julliard
julli...@winehq.org
Alexandre Julliard wrote:
> > If there is no current clipping region ExtSelectClipRgn(hdc, hrgn, RGN_DIFF)
> > creates its own default clipping region which in most cases doesn't match
> > neither a visible region nor the window extents attached to the DC.
>
> It will get intersected with the vi
Dmitry Timoshkov writes:
> If there is no current clipping region ExtSelectClipRgn(hdc, hrgn, RGN_DIFF)
> creates its own default clipping region which in most cases doesn't match
> neither a visible region nor the window extents attached to the DC.
It will get intersected with the visible regio
Alexandre Julliard wrote:
> > -ExcludeUpdateRgn( hdc_dst, data->hwnd );
> > +if (!parent || !(GetWindowLongW( parent, GWL_STYLE ) &
> > WS_CLIPCHILDREN))
> > +ExcludeUpdateRgn( hdc_dst, data->hwnd );
>
> I don't see what the parent clipping has to do with this. Could you
> pleas
On 01/27/2011 07:42 PM, Alexander Scott-Johns wrote:
+FIXME("Called to synthesize unknown format 0x%08x\n",
wFormatID);
Formats defined as decimal, so you should print it as decimal.
+if ((lpSource = X11DRV_CLIPBOARD_LookupData(CF_ENHMETAFILE)) &&
lpSource->hDa
Dmitry Timoshkov writes:
> @@ -1624,7 +1624,8 @@ static void move_window_bits( struct x11drv_win_data
> *data, const RECT *old_rect
> hdc_src = hdc_dst = GetDCEx( data->hwnd, 0, DCX_CACHE );
> }
>
> -ExcludeUpdateRgn( hdc_dst, data->hwnd );
> +if (!parent || !(GetWindowLo
Le mardi 25 janvier 2011 à 19:10 +0100, Henri Verbeet a écrit :
> 2011/1/25 André Hentschel :
> > http://austinenglish.com/logs/clang_analyzer/report-dRpLpZ.html#EndPath
> > then the if condition is reliable
> I don't think that can happen unless hwnd is NULL and top is non-NULL,
> which looks like
2011/1/25 André Hentschel :
> http://austinenglish.com/logs/clang_analyzer/report-dRpLpZ.html#EndPath
> then the if condition is reliable
I don't think that can happen unless hwnd is NULL and top is non-NULL,
which looks like invalid input to me.
On Sun, 14 Feb 2010, James McKenzie wrote:
> Please take time to read through the remainder of the posts here, even
> though you've been here for a while. It is NOT possible to build Wine
> without some sort of X on the build computer right now.
Yep, I know. Which is why I wondered that configu
Henri Verbeet writes:
> On 7 September 2010 11:23, Alexandre Julliard wrote:
>> Nothing says that winediag messages have to be ERR. If it's not an
>> important failure that all users have to see, it can be a WARN or a
>> TRACE. The hypothetical diagnostic GUI tool can then display those
>> diffe
On 7 September 2010 11:23, Alexandre Julliard wrote:
> Nothing says that winediag messages have to be ERR. If it's not an
> important failure that all users have to see, it can be a WARN or a
> TRACE. The hypothetical diagnostic GUI tool can then display those
> differently.
>
Things like not usin
Henri Verbeet writes:
> Note that personally I don't think it's appropriate for "winediag" to abuse
> the __WINE_DBCL_ERR debug class for diagnostic messages.
Nothing says that winediag messages have to be ERR. If it's not an
important failure that all users have to see, it can be a WARN or a
TR
On 08/16/2010 01:06 PM, Rafał Miłecki wrote:
It's prehistoric thread already, but issue still isn't solved. I
wanted to rework that old patch but I noticed set_key_state was
already changed and it doesn't change single key state, but instead
sets whole array at every call.
This was I can not use
On Tue, Aug 10, 2010 at 4:28 PM, Dan Kegel wrote:
> That's for http://bugs.winehq.org/show_bug.cgi?id=20335 , right?
>
> Alexandre's reply to that was
> "It sounds like it's hashing padding bytes. Probably should be reported to the
> X.org folks."
FWIW, I reported it here:
https://bugs.freedeskto
Hi Alexandre,
W dniu 11 września 2009 13:22 użytkownik Alexandre Julliard
napisał:
> Rafał Miłecki writes:
>
>> @@ -1250,6 +1250,21 @@ void X11DRV_send_keyboard_input( WORD wVk, WORD
>> wScan, DWORD event_flags, DWORD
>> key_state_table[wVkStripped] = key_state_table[wVkL] |
>> ke
That's for http://bugs.winehq.org/show_bug.cgi?id=20335 , right?
Alexandre's reply to that was
"It sounds like it's hashing padding bytes. Probably should be reported to the
X.org folks."
X is old code, and I don't think anyone has cleaned it up for valgrind yet.
That's why I use suppression fil
Hello Austin,
Austin Lund wrote:
> On 10 August 2010 18:05, Michael Stefaniuc wrote:
>> Hello Austin,
>>
>> Austin Lund wrote:
>>>
>
>> both functions are heavily used and you don't want to waste time
>> HEAP_ZERO_MEMORY ju
1 - 100 of 341 matches
Mail list logo
