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.c b/dlls/winex11.drv/opengl.c
> in
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
On 05/01/2013 05: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
"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
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 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
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.
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
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
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 need to guard inside Get
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
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 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
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
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 just to please valgrind. I even wonder why
Hello Austin,
Austin Lund wrote:
>
>
> From 07bc18edc35c68c8e0da58a70ccd5c8f03584a1a Mon Sep 17 00:00:00 2001
> From: Austin Lund
> Date: Tue, 10 Aug 2010 13:03:14 +1000
> Subject: [PATCH] winex11.drv: Fix uninitialised val
Damjan Jovanovic writes:
> @@ -300,6 +499,66 @@ static void X11DRV_XDND_ResolveProperty(Display
> *display, Window xwin, Time tm,
> wine_tsx11_unlock();
> }
>
> +/* We get the list of formats in descending order of preference, yet the
> linked
> + * list is a stack so th
Damjan Jovanovic writes:
> +static void SM_Init(void)
> +{
> +CreateThread(NULL, 0, manage_session, NULL, 0, NULL);
> +}
> +#endif /* defined(SONAME_LIBSM) */
You don't want to create a new thread in every process for this. It will
cause lots of trouble.
--
Alexandre Julliard
julli...@wine
Dmitry Timoshkov writes:
> @@ -2541,9 +2541,13 @@ INT CDECL X11DRV_ToUnicodeEx(UINT virtKey, UINT
> scanCode, const BYTE *lpKeyState
> e.state = 0;
> e.type = KeyPress;
>
> -focus = GetFocus();
> -if (focus) focus = GetAncestor( focus, GA_ROOT );
> -if (!focus) focus = Ge
Aric Stewart writes:
> commit 082bc5ccbcc35e2058f1a3cd5c52345edf760631
> Author: Aric Stewart
> Date: Tue Jun 22 16:58:38 2010 +0900
>
> winex11.drv: warn and return when UploadGlyph fails in
> X11DRV_XRender_ExtTextOut
>
> this prevents crashing later when we are assuming that a
On 06/15/2010 05:36 AM, Paul Chitescu wrote:
> Changelog:
> winex11.drv: Post a WM_SYSCOMMAND SC_CLOSE when the Window Manager asks
> to
> close a window
> +GetCursorPos( &pt );
> +PostMessageW( hwnd, WM_SYSCOMMAND, SC_CLOSE, MAKELPARAM( pt.x,
> pt.y ) );
You can't
On 2010-03-13 15:01:47 -0600, Vincent Povirk wrote:
> You should create a WM_CLIENT_LEADER window as described here:
> http://tronche.com/gui/x/icccm/sec-5.html
>
> That way, the windows belonging to a single client can be reliably
> linked together.
>
> I think you can ignore the requirement tha
You should create a WM_CLIENT_LEADER window as described here:
http://tronche.com/gui/x/icccm/sec-5.html
That way, the windows belonging to a single client can be reliably
linked together.
I think you can ignore the requirement that the client leader window
have an id from the session manager. I
On 01/22/2010 03:42 PM, Lauri Kenttä wrote:
>> The SetCursorPos() calls hooks on Wine because Wine has big issue - it
>> doesn't filter pointer move messages that were caused by Wine itself.
>
> The first patch (http://source.winehq.org/patches/data/57569) tries to
> address exactly this. I think
Lauri Kenttä wrote:
> James McKenzie wrote:
>
>> Programming can and is brutal.
>>
>
> Yes, I know. But programming can also be nice and fun. It will be exactly
> what the community makes it. I've seen both kinds, and guess which ones
> have had more active users. This was my point, so do n
Ricardo Filipe wrote:
> see: http://bugs.winehq.org/show_bug.cgi?id=6971
Ok, that really explains something. Thanks a lot, I'll find a game to test.
--
Lauri Kenttä
James McKenzie wrote:
> Programming can and is brutal.
Yes, I know. But programming can also be nice and fun. It will be exactly
what the community makes it. I've seen both kinds, and guess which ones
have had more active users. This was my point, so do not misunderstand:
I'm certainly not saying
2010/1/22 Lauri Kenttä :
>
hi lauri.
i'm glad you take people's comments with a grain of salt. vitaliy was
a bit condescending but he said "please" :D
it's unfortunate but we have to get used to it. i know it's not the
best to entice developers but it's what we have, and it's good, stay
around and
Lauri Kenttä wrote:
> My apologies for bringing up something that is actually none of my
> business, but I think you should pay more attention to the way you write
> your comments. First, even small positive comments are considered
> psychologically very important, but you have given none. Second,
> The SetCursorPos() calls hooks on Wine because Wine has big issue - it
doesn't filter pointer move messages that were caused by Wine itself.
The first patch (http://source.winehq.org/patches/data/57569) tries to
address exactly this. I think XWarpCursor is not a problem, as the event
comes async
Lauri Kenttä wrote:
> The new series of patches has some related changes (including a new test)
> applied before this one.
You have some issues in your test as well. The SetCursorPos() calls hooks on
Wine because Wine has big issue - it doesn't filter pointer move messages
that were caused by Wine
Thanks for your comments, Vitaliy.
At first, I must point out that you're commenting on a patch that has
already been superseded. Not that there's much difference, but the new
series of patches has some related changes (including a new test) applied
before this one.
Vitaliy Margolen wrote:
> Lots
Lauri Kenttä wrote:
> When the cursor position is clipped with ClipCursor, the cursor should be
> confined to that area. This patch fixes cursor position clipping in
> X11DRV_ClipCursor, X11DRV_GetCursorPos, X11DRV_SetCursorPos and
> X11DRV_send_mouse_input and makes the mouse warp to the new posit
Ilya Shpigor wrote:
> +/* Ctrl+Break processing */
> +if ((e->state & ControlMask) &&
> +(e->keycode == 0x7F))
> +return VK_CANCEL;
It's always a good idea to provide some details. Like:
pressing the Pause/Break key alone produces VK_PAUSE vkey, while
pressing Ctrl+Pause
I've taken the following feedback on board and resubmitted the patch.
Andrew Eikum wrote:
This is less important, but you're not following the code conventions
of the surrounding code. The surrounding code does not have spaces
around function parameters, so yours shouldn't either.
The exist
Hi Peter,
I didn't see this patch before because I was away at that time. The
SourceConstantAlpha part looks correct to me. It might make sense to
calculate blendfn.SourceConstantAlpha / 255 before the loop, so that
it isn't recalculated each time.
The other half of your patch is a separate chang
"Yuri Khan" wrote:
+void selection_acquire(void)
Should be 'static'.
+DWORD WINAPI selection_thread_proc(LPVOID lphwnd)
Should be 'static'. What's the purpose of such a parameter name?
'dummy', 'unused' or just 'param' would be better IMO.
+{
+HANDLE handles[1];
+
+selection_acq
Yuri Khan writes:
> @@ -239,6 +239,9 @@ static Bool filter_event( Display *display, XEvent
> *event, char *arg )
> case PropertyNotify:
> case ClientMessage:
> return (mask & QS_POSTMESSAGE) != 0;
> +case SelectionClear:
> +case SelectionRequest:
> +return 1;
>
On Wed, Jul 1, 2009 at 21:07, Alexandre Julliard wrote:
>> This patch achieves this by creating an auxiliary thread that will run
>> in the same process that puts data on the clipboard and handle X
>> selection messages.
> That looks quite inefficient, especially since you create a new thread
> e
Yuri Khan writes:
> This patch achieves this by creating an auxiliary thread that will run
> in the same process that puts data on the clipboard and handle X
> selection messages.
That looks quite inefficient, especially since you create a new thread
every time. You should limit this to the case
Alexandre Julliard ha scritto:
- descr.bits = bits;
+ descr.bits = (BYTE *)bits + widthBytes * (tmpheight > 0 ? (height -
startscan - lines) : startscan);
You shouldn't need to change the bits address.
After a deeper look at it, I think there's no other (simple) way to do it.
Us
Massimo Del Fedele ha scritto:
p.s.: of course, it needs also
widthBytes * (.)
I just shorted it to show the problem :-)
Ciao
Max
Alexandre Julliard ha scritto:
Massimo Del Fedele writes:
- descr.bits = bits;
+ descr.bits = (BYTE *)bits + widthBytes * (tmpheight > 0 ? (height -
startscan - lines) : startscan);
You shouldn't need to change the bits address.
Well, original code was
descr.bits =
Massimo Del Fedele writes:
> diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c
> index 6df4137..42d9082 100644
> --- a/dlls/winex11.drv/dib.c
> +++ b/dlls/winex11.drv/dib.c
> @@ -3927,6 +3927,7 @@ INT CDECL X11DRV_SetDIBits( X11DRV_PDEVICE *physDev,
> HBITMAP hbitmap, UINT start
>
Paul Bryan Roberts wrote:
>
>> You need to generate the patch from the top of the wine directory. You
>> also need to use your real name for copyright-tracking purposes.
>
>"copyright-tracking purposes"
>
That is a way of saying that we need, for legal reasons, to know the originator
of each and
1 - 100 of 239 matches
Mail list logo
