Perhaps a comment should be added so new people will know about it?
On Jan 21, 2013, at 4:24 AM, Alexandre Julliard wrote:
> "C.W. Betts" writes:
>
>> I noticed in my research that the X11 driver doesn't return true in
>> SystemParametersInfo when handling SPI_SETSCREENSAVEACTIVE. This patch
>>
"C.W. Betts" writes:
> I noticed in my research that the X11 driver doesn't return true in
> SystemParametersInfo when handling SPI_SETSCREENSAVEACTIVE. This patch
> fixes this.
That's on purpose, it also needs to update the registry entry.
--
Alexandre Julliard
julli...@winehq.org
Vincent Povirk wrote:
>> --- keyboard.old2008-11-27 16:53:15.0 +0100
>> +++ keyboard.c2008-11-26 21:19:01.0 +0100
All patches have to be generated from the top of the source tree (if you not
using git). This patch is invalid.
Vitaliy
I don't think "lpBuffer[nSize - 1] = 0;" is safe to remove. If nSize
is too small, the resulting string may not be NULL-terminated.
Patch-sending guidelines are at http://www.winehq.org/site/sending_patches.
Your patch is more likely to be committed if you write a conformance
test (although it ma
_NET_WM_WINDOW_TYPE_NORMAL?
I have tried to trace this through the code, and I wind up at
x11drv/desktop.c, but I don't see any reference to DIALOG there.
Alternatively, perhaps it is set with MAKEINTATOM at the top of
explorer/desktop.c, but I'm not sure how to interpret that constant
Aric Stewart <[EMAIL PROTECTED]> writes:
> @@ -1569,12 +1570,14 @@ BOOL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT
> xDst, INT yDst, INT widthDst,
>
> if (!devSrc->bitmap || GetObjectW( devSrc->bitmap->hbitmap, sizeof(dib),
> &dib ) != sizeof(dib))
> {
> -FIXME("not a dibs
Clinton Stimpson <[EMAIL PROTECTED]> writes:
> Clinton Stimpson wrote:
>> Fix for bug 9875 (There are more details in that bug report if you want).
>> Existance of update regions in the wine server correspond with WM_PAINT
>> existing in queue. Existance of Expose events in the X event queue don
Clinton Stimpson wrote:
> Fix for bug 9875 (There are more details in that bug report if you want).
> Existance of update regions in the wine server correspond with WM_PAINT
> existing in queue. Existance of Expose events in the X event queue don't
> correspond with update regions in the wine se
Vitaliy Margolen wrote:
Tomas Carnecky wrote:
This patch introduces a new registry key, "FocusDesktopWindow", that
can be used to specify whether wine should set the foreground window
to the desktop window after the last wine app looses focus. The
default is enabled (the same behavior as now).
Tomas Carnecky wrote:
This patch introduces a new registry key, "FocusDesktopWindow", that can
be used to specify whether wine should set the foreground window to the
desktop window after the last wine app looses focus. The default is
enabled (the same behavior as now).
This is a bad hack. Th
Hi,
I'm working on a bug in winex11drv/xdnd.c, where file:/// URIs are not
correctly interpreted, resulting in DnD broken most of the time. There
are two parts of that bug:
1) X11DRV_XDND_BuildDropFiles() fails to properly handle absolute unix
paths, which is exactly what you get from file:///, s
Maciej Katafiasz wrote:
+if(GetLastError())
+{
+ TRACE("Can't convert to WCHAR: %d\n", GetLastError());
+ goto clean_wfn;
+}
This is not an appropriate way of testing for an API failure.
What is inappropriate and how should I fix it?
Most APIs don't change GLE on success
On tor, 2007-03-22 at 12:02 +0800, Dmitry Timoshkov wrote:
> Please use the same indentation style as the existing does, i.e. 4 spaces,
> not 2.
Yep, I didn't fix that in that patch, I just forgot to set the indent
style properly, and it's not a patch ready for submission anyway. But
noted.
> > +
Dmitry Timoshkov wrote:
-strcpy(((char*)lpDrop)+lpDrop->pFiles, path);
+memcpy(((char*)lpDrop)+lpDrop->pFiles, (char*)wpath,
fullpathlen * sizeof(WCHAR));
Use lstrcpyW here instead of memcpy.
Why? Maciej has already got the length, so why not do the appropriate
calculation
Maciej Katafiasz <[EMAIL PROTECTED]> wrote:
+ if(!strncasecmp(p, "://localhost/", 13))
+ {
+ i = 12;
+ } else if (!strncasecmp(p, ":///", 4))
+ {
+ i = 3;
+ } else
+ {
+ TRACE("Not a valid file: URI: %s\n", (char*)data);
+ return count;
+ }
P
Hi,
(please ignore the other copy I sent from the wrong address by accident)
I'm working on a bug in winex11drv/xdnd.c, where file:/// URIs are not
correctly interpreted, resulting in DnD broken most of the time. There
are two parts of that bug:
1) X11DRV_XDND_BuildDropFiles() fails to properly
"Roderick Colenbrander" <[EMAIL PROTECTED]> wrote:
This patch removes the DesktopDoubleBuffered option.
Support for this option should be removed from winecfg simultaneously
with this change.
--
Dmitry.
Mike McCormack wrote:
>
> Vitaliy Margolen wrote:
>
>> POINT cursor_pos;
>>
>> +static CRITICAL_SECTION cursor_CritSection;
>
> There's a reference to cursor_pos in dlls/winex11.drv/keyboard.c too,
> and you're missing a critical section around it.
>
Oh thank you. I think it will need a temp
Vitaliy Margolen wrote:
dlls/winex11.drv/mouse.c | 43 +--
...
POINT cursor_pos;
+static CRITICAL_SECTION cursor_CritSection;
There's a reference to cursor_pos in dlls/winex11.drv/keyboard.c too,
and you're missing a critical section around it
This time with a patch.
> Hi,
>
> This is a resubmit of the previous font moving patch against the latest
> cvs/git version. The old version didn't apply anymore to winex11.drv. For the
> rest the patch is the same.
>
> Regards,
> Roderick Colenbrander
> --
> Der GMX SmartSurfer hilft bis zu 70
On 9/20/06, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
Hi,
This is a resubmit of the previous font moving patch against the latest cvs/git
version. The old version didn't apply anymore to winex11.drv. For the rest the
patch is the same.
You forgot to attach the patch.
--
James Hawkin
Ati doesn't advertise GLX_SGIX_fbconfig. They only advertise a GLX client
version of 1.3. Because the Xserver only supports 1.2, the reported version is
also 1.2 (only the client version number is 1.3, the rest not).
Roderick
> Roderick Colenbrander wrote:
> > The issue is that ATI's drivers do
> Roderick Colenbrander wrote:
> > There's this check:
> > if ((!WineGLInfo.glxDirect && !strcmp("1.2",
> WineGLInfo.glxServerVersion)) ||
> > (WineGLInfo.glxDirect && !strcmp("1.2",
> WineGLInfo.glxClientVersion)))
>
>
> This is not the correct way of loading opengl functions or de
Tomas carnecky wrote:
This is not the correct way of loading opengl functions or deciding
whether they are available or not. According to the
GLX_ARB_get_proc_address spec, we need to check _only_
glXQueryExtensionsString() and glXQueryVersion()
The spec: http://www.opengl.org/registry/specs/
Roderick Colenbrander wrote:
There's this check:
if ((!WineGLInfo.glxDirect && !strcmp("1.2", WineGLInfo.glxServerVersion))
||
(WineGLInfo.glxDirect && !strcmp("1.2", WineGLInfo.glxClientVersion)))
This is not the correct way of loading opengl functions or deciding
whether they
On Fri, Sep 01, 2006 at 01:57:24PM +0200, Roderick Colenbrander wrote:
> The way WGL extensions are loaded is different. The old code correctly
> advertised the names of available WGL extensions but the wglGetProcAddress
> code didn't work correctly. Even if an extension wasn't advertised you could
"Roderick Colenbrander" <[EMAIL PROTECTED]> writes:
> The patch adds new WGL extension loading code based on code written
> by an old opengl32 -> x11drv patch written by Tomas Carnacky. The
> code properly advertises WGL extensions and only returns function
> pointe
"Roderick Colenbrander" <[EMAIL PROTECTED]> writes:
> +@ cdecl WGL_CreateContext(long) X11DRV_WGL_CreateContext
> +@ cdecl WGL_DeleteContext(long) X11DRV_WGL_DeleteContext
> +@ cdecl WGL_GetCurrentContext() X11DRV_WGL_GetCurrentContext
> +@ cdecl WGL_GetCurrentDC() X11DRV_WGL_GetCurrentDC
> +@ cde
Yikes, I forgot to add the spec file changes to the patch.
Thanks for noting it,
Roderick
> Message d'origine
> >Date: Tue, 29 Aug 2006 01:39:49 +0200
> >De: "Roderick Colenbrander" <[EMAIL PROTECTED]>
> >A: [EMAIL PROTECTED]
> >
Message d'origine
>Date: Tue, 29 Aug 2006 01:39:49 +0200
>De: "Roderick Colenbrander" <[EMAIL PROTECTED]>
>A: [EMAIL PROTECTED]
>Sujet: X11Drv: import glx context code
>
>Hi,
>
seems you forget to change winex11dvr.spec file no ? :)
Good Job anyway
Regards,
Raphael
> > I did that, I created a new field in the PDEVICE structure and used two
> > new ExtEscape codes (SET_FLAGS/GET_FLAGS), but Alexandre doesn't want to
> > add new ExtEscape codes..
> > That's why I hacked even more on wine and moved the wgl implementation
>
> I did that, I created a new field in the PDEVICE structure and used two
> new ExtEscape codes (SET_FLAGS/GET_FLAGS), but Alexandre doesn't want to
> add new ExtEscape codes..
> That's why I hacked even more on wine and moved the wgl implementation
> to x11drv... a
Roderick Colenbrander wrote:
> If we could set a pbuffer flag in there and retrieve it in wglMakeCurrent it
> would work. I fear that this can only be done in a clean way if it code would
> be in x11drv :(
>
I did that, I created a new field in the PDEVICE structure and used two
n
Hi,
> Problem with WineD3D on top of WGL is that we lost many of usefull APIs
> I think WineD3D on top of x11drv (as WGL on top of x11drv) should a the
> better way
WineD3D on top of WGL has the advantage that we can use our D3D libraries in
windows too. This can be useful for testing
> The biggest issue I had when porting was the OpenGL extensions. All
> extensions
> had to be called through the wgl thunks to get the calling conventions
> right,
> but that isn't hard, just a little extra initial work.
>
> - Aric
>
>
I have done the same a while ago. The calling convention
gt; > can atleast handle windowed rendering. I don't know the code that well to
> > change it.
>
> Problem with WineD3D on top of WGL is that we lost many of usefull APIs
> I think WineD3D on top of x11drv (as WGL on top of x11drv) should a the
> better
> way
Like what API
tension needs to be called to receive a DC for a pbuffer.
> If we could set a pbuffer flag in there and retrieve it in wglMakeCurrent
> it would work. I fear that this can only be done in a clean way if it code
> would be in x11drv :(
An evil way would be to not call SetPixelFormat from wglG
buffer. If we
could set a pbuffer flag in there and retrieve it in wglMakeCurrent it would
work. I fear that this can only be done in a clean way if it code would be in
x11drv :(
> > On irc someone suggested to create a new window for opengl rendering and
> > put it on top of the place
ng
> similar is done on Windows.
Yes i thought about the same :)
But seems ugly to handle on x11drv (2 window for the same => redirect input,
etc...)
> This would solve the issues. I was also thinking about layering WineD3D on
> top of WGL also for the sake of portability and it will
format
> (supported on windows)
>
> So you may restore many of the original problems but fixed the more
> problematic problem of BadMatch :)
>
> What it'll be interesting to do next is to move all low-level GLW/GLX
> utilities calls to x11drv to permit better access
- Original-Message
> Datum: Mon, 14 Aug 2006 17:04:52 +0200
> From: "Roderick Colenbrander" <[EMAIL PROTECTED]>
> To: wine-devel@winehq.org
> Subject: RFC: OpenGL x11drv rewrite (WoW fix)
>
> Hi,
>
For me your patch seems correct
Anyway the problem i
The issue is that the line isn't error in all cases. Most of the time only
iPixelFormat 1 and the offscreen formats are valid values. But for some queries
like how much pixelformats exist a program can pass garbage aswell. This
processing is done at a later stage because of this, it could be cha
Testing with World of Warcraft, the game runs fine, but I see this in
the console:
err:wgl:wglGetPixelFormatAttribivARB Unable to convert iPixelFormat 0 to
a GLX one, expect problems!
tom
WoW hack). I will fix that part
> when you guys think that the patch is correct.
I can't speak about the technical aspects, but placing wgl commands into
x11drv sounds like a good idea if we want better platform independence. We
will need it if we want to port wine 'properly' t
Hi,
Since the WM rewrite we can only use the visual which was created by x11drv at
x11drv initialization. In general this is a simple 32bit RGBA visual or when
that's not available it is some 16bit visual.
The problem is that the opengl code advertises more formats than this single
f
Thanks for this great piece of work !
- Stefan
Hi,
On Fri, Jun 16, 2006 at 11:46:02PM +0900, Dmitry Timoshkov wrote:
> "Andrew Talbot" <[EMAIL PROTECTED]> wrote:
>
> >It seems better to represent international characters with escape
> >sequences,
> >both to increase clarity - especially for those who do not normally use
> >ISO-8859-1 encodin
Dmitry Timoshkov wrote:
> "Andrew Talbot" <[EMAIL PROTECTED]> wrote:
>
>> It seems better to represent international characters with escape
>> sequences, both to increase clarity - especially for those who do not
>> normally use ISO-8859-1 encoding - and to make editing easier for some.
>
> Plea
"Andrew Talbot" <[EMAIL PROTECTED]> wrote:
It seems better to represent international characters with escape sequences,
both to increase clarity - especially for those who do not normally use
ISO-8859-1 encoding - and to make editing easier for some.
Please don't do that. Anyone who wants to e
existing ones with XGetWMHints(...), and sets
class default icon, instead of checking whether another
icon has been set in the meantime.
However, calls to X11DRV_set_wm_hints have been added at
mapping a window and changing window style (see x11drv/winpos.c).
Thus, Wine currently allocates WM hints
Juris Smotrovs <[EMAIL PROTECTED]> writes:
> The defwinproc mismatch itself appears
> because, after solving the WM_SIZE issue, this message --
> correctly -- is sent, so the actual message queue shifts
> relative to the expected message queue, and -- due to
> some messages still missing -- three
Alexandre Julliard wrote:
@@ -1435,9 +1435,19 @@
"%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n",
context, expected->message, expected->lParam,
actual->lParam);
}
- ok_( file, line) ((expected->flags & defwinproc) == (actual
Juris Smotrovs <[EMAIL PROTECTED]> writes:
> @@ -1435,9 +1435,19 @@
>"%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n",
>context, expected->message, expected->lParam,
> actual->lParam);
> }
> - ok_( file, line) ((expected->flags &
t;flags & defwinproc) ? "" : "NOT ");
ok_( file, line) ((expected->flags & beginpaint) == (actual->flags & beginpaint),
"%s: the msg 0x%04x should %shave been sent by BeginPaint\n",
context, expected->message, (expected->flags & be
On Thursday 25 May 2006 20:51, Saulius Krasuckas wrote:
> BTW, now the issue is seen on my box too. Heh, it reminds my of my own
> bugreport [*]. Could this be related, Troy?
>
>
> [*] http://bugs.winehq.org/show_bug.cgi?id=5248
No, your problem is definitely different.
--
Troy Rollo - [EMAIL
On Thursday 25 May 2006 19:47, Huw Davies wrote:
> Nice catch! This should fix it.
Indeed it does.
--
Troy Rollo - [EMAIL PROTECTED]
* On Thu, 25 May 2006, Saulius Krasuckas wrote:
> I'am running wine from a local src tree, so I had to compile this way:
>
> $ tools/winegcc/winegcc -Btools/winebuild/ -B/usr/bin/ -g sysfont.c -Ldlls
> -Llibs -Iinclude -mwindows
Sorry, -B/usr/bin is a leftover from my experiments and isn't neede
On Thu, May 25, 2006 at 04:49:04PM +1000, Troy Rollo wrote:
> The attached sample program demonstrates a bug in font handling that can lead
> to corrupted fonts. Compile with "winegcc -g sysfont.c -lgdi32 -lcomdlg32".
> Run the resulting a.out, and you will see the letter "C" in the top left
> c
* On Thu, 25 May 2006, Troy Rollo wrote:
> The attached sample program demonstrates a bug in font handling that can
> lead to corrupted fonts. Compile with "winegcc -g sysfont.c -lgdi32
> -lcomdlg32".
I'am running wine from a local src tree, so I had to compile this way:
$ tools/winegcc/winegcc
en
the test program calls SetFont it is the new, scalable font (based on Tahoma)
that is found.
The Tahoma font has different glyph codes to the System font, such that 'C' is
glyph code 36 in the System font and 38 in Tahoma. Accordingly, x11drv
identifies the glyph as not having
Phil Krylov wrote:
Messed colors and vertical stripes? Similar to
http://www.froq.net/mirage/mirage1.png ?
No, I get rather like this:
http://newstar.rinet.ru/~phil/Screenshot-StarLing-for-Macintosh.png
The StarLing image may be similar, but I think you're both looking at
different b
On Thu, 20 Apr 2006 00:10:42 +0200
Willie Sippel <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 19. April 2006 22:50 schrieb Eric Frias:
> > I'm trying to debug a problem in which 24-bit .bmps don't display
> > correctly from a winelib application on a big-endian sparc host when
> > displaying on a lit
Am Mittwoch, 19. April 2006 22:50 schrieb Eric Frias:
> I'm trying to debug a problem in which 24-bit .bmps don't display
> correctly from a winelib application on a big-endian sparc host when
> displaying on a little-endian intel PC. In this case, the image is
> garbled, with most of the colors b
On Wed, 19 Apr 2006 16:50:47 -0400
Eric Frias <[EMAIL PROTECTED]> wrote:
> I'm trying to debug a problem in which 24-bit .bmps don't display
> correctly from a winelib application on a big-endian sparc host when
> displaying on a little-endian intel PC. In this case, the image is
> garbled, wi
I'm trying to debug a problem in which 24-bit .bmps don't display
correctly from a winelib application on a big-endian sparc host when
displaying on a little-endian intel PC. In this case, the image is
garbled, with most of the colors being wrong and a pattern of vertical
stripes over the imag
.
dlls/x11drv/clipboard.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
Index: dlls/x11drv/clipboard.c
===
RCS file: /home/wine/wine/dlls/x11drv/clipboard.c,v
retrieving revision 1.51
diff -d -u
<[EMAIL PROTECTED]> wrote:
A couple of suggestions about coding style:
+struct transition_s {
+BYTE wVk;
It would be more logical to use WORD for VK codes as everywhere else.
+BYTE before_state;
+BYTE _todo_wine;
+};
Same for _todo_wine, it should be BOOL.
+
+struct sendinpu
Alexandre Julliard wrote:
> Tomas Carnecky <[EMAIL PROTECTED]> writes:
>
>> This patch doesn't change any logic or C sourcecode, it only moves the
>> X11DRV escape code definition to one common header file. Currently the
>> definitions are spread over several
Tomas Carnecky <[EMAIL PROTECTED]> writes:
> This patch doesn't change any logic or C sourcecode, it only moves the
> X11DRV escape code definition to one common header file. Currently the
> definitions are spread over several C source files, and even there the
> definiti
Willie Sippel wrote:
OK, maybe I got something completely wrong. I'll give you an example to show
the problem I mean:
Traktor DJ Player, by Native Instruments
On Windows:
The main application window has no borders, appears in the taskbar, can be
minimized and moved like any regular window.
with 'no decoration' Motif hints (the
> > way GTK handles borderless windows). The example I found looks easy
> > enough, only a few lines of code, but I was once again reminded that Wine
> > really is way over my head - I have no idea how to hack that in to at
> >
example I found looks easy enough, only a
few lines of code, but I was once again reminded that Wine really is way over
my head - I have no idea how to hack that in to at least test it... :-(
The code is already in dlls/x11drv/window.c and it works well. The
trouble is that managed mode wind
From: "Mike McCormack" <[EMAIL PROTECTED]>
> Yep. Just large enough for people to complain about, and demand that
> somebody else take care of the problem, Now! ;)
One of those things :) Now, don't misunderstand me,
I'm glad Alexandre got around to move the desktop
to the explorer process. My
Dimi Paun wrote:
Problem is that the breakage is not large enough to motivate
people.
Yep. Just large enough for people to complain about, and demand that
somebody else take care of the problem, Now! ;)
Mike
Am Mittwoch, 29. März 2006 15:14 schrieb Marcus Meissner:
> On Wed, Mar 29, 2006 at 02:47:06PM +0200, Willie Sippel wrote:
> ...
>
> > > Isn't it just better to start with a patch that is "right", but will
> > > still show regressions, then fix those regressions, as opposed to
> > > starting with a
From: "Mike McCormack" <[EMAIL PROTECTED]>
> Wouldn't be much motivation for somebody to come up with a real fix if
> there was already a half-baked fix in Wine already, would there?
But neither does the keep-it-borken approach work, does it? :)
Problem is that the breakage is not large enough to
On Wed, Mar 29, 2006 at 02:47:06PM +0200, Willie Sippel wrote:
...
> > Isn't it just better to start with a patch that is "right", but will
> > still show regressions, then fix those regressions, as opposed to
> > starting with a patch that is wrong, and then hacking on it forever
> > trying to sol
Am Mittwoch, 29. März 2006 12:19 schrieb Stefan Dösinger:
> Hello,
>
> > > You announced working on the unmanaged window problem in September 2001
> > > IIRC, but I guess you didn't so far? Wouldn't, for the time being, a
> > > Cedega-like approach be feasible? They seem to ignore 'chromeless'
> >
Mike McCormack wrote:
Willie Sippel wrote:
You announced working on the unmanaged window problem in September
2001 IIRC, but I guess you didn't so far? Wouldn't, for the time
being, a Cedega-like approach be feasible? They seem to ignore
'chromeless' windows and handle them just like regular
Am Mittwoch, 29. März 2006 13:15 schrieb Mike McCormack:
> Willie Sippel wrote:
> > Probably true. But Wine has several problems where a 'real' fix is so
> > very complicated that we won't see something anytime soon, probably for
> > years to come (like the DIB engine, planned for years, but nobody
Willie Sippel wrote:
Probably true. But Wine has several problems where a 'real' fix is so very
complicated that we won't see something anytime soon, probably for years to
come (like the DIB engine, planned for years, but nobody seems to even work
on it). In the recent two years, Wine became
Am Mittwoch, 29. März 2006 11:39 schrieb Mike McCormack:
> Willie Sippel wrote:
> > You announced working on the unmanaged window problem in September 2001
> > IIRC, but I guess you didn't so far? Wouldn't, for the time being, a
> > Cedega-like approach be feasible? They seem to ignore 'chromeless'
Hello,
> > You announced working on the unmanaged window problem in September 2001
> > IIRC, but I guess you didn't so far? Wouldn't, for the time being, a
> > Cedega-like approach be feasible? They seem to ignore 'chromeless'
> > windows and handle them just like regular windows (with window decor
Am Dienstag, 28. März 2006 11:31 schrieb Alexandre Julliard:
> Vitaliy Margolen <[EMAIL PROTECTED]> writes:
> > Ok so now say with Steam and all of it's games - it will be almost 100%
> > unusable! Because we still haven't fixes managed/unmamaged windows. And
> > Steam itself would be on top of eve
Willie Sippel wrote:
You announced working on the unmanaged window problem in September 2001 IIRC,
but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like
approach be feasible? They seem to ignore 'chromeless' windows and handle
them just like regular windows (with window d
fig. With the old code,
> x11drv nicely reported the standard displaymodes 640x480,800x600,... to
> DDraw / opengl / d3d, and could resize the window to that resolutions. Now
> it only supports 1400x2074
Never mind that rant, I must have done something wrong when updating /
recompiling, now
"Jesse Allen" <[EMAIL PROTECTED]> writes:
> Is the explorer.exe program supposed to be in the path somewhere? The
> only place it is installed is in /usr/local/lib/wine/explorer.exe.so.
> That is outside my wine drive letters. I have to copy it in to drive
> C to be able to run and use the /desk
h. All DirectDraw games I've
tested(with the mainline ddraw code any my patches) because they fail to set
the display mode. I have a MergedFB setup with a resolution of 1400x2074, and
I disallow mode changes in my X config. With the old code, x11drv nicely
reported the standard displaymo
b6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f
> >
> > Author: Alexandre Julliard <[EMAIL PROTECTED]>
> > Date: Mon Mar 27 22:43:03 2006 +0200
> >
> > x11drv: Moved desktop mode handling to the explorer process.
> >
> > Per-application desktop mode settings a
Vitaliy Margolen <[EMAIL PROTECTED]> writes:
> Ok so now say with Steam and all of it's games - it will be almost 100%
> unusable! Because we still haven't fixes managed/unmamaged windows. And
> Steam itself would be on top of everything. So the way people were able
> to work-around this is by put
gt;>> http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f
>>>
>>>
>>> Author: Alexandre Julliard <[EMAIL PROTECTED]>
>>> Date: Mon Mar 27 22:43:03 2006 +0200
>>>
>>> x11drv: Moved desktop m
;
Date: Mon Mar 27 22:43:03 2006 +0200
x11drv: Moved desktop mode handling to the explorer process.
Per-application desktop mode settings are no longer supported. Apps
can be launched in a specific desktop window by using:
explorer /desktop=name[,widthxheight] app.exe [args]
If the named d
3 2006 +0200
x11drv: Moved desktop mode handling to the explorer process.
Per-application desktop mode settings are no longer supported. Apps
can be launched in a specific desktop window by using:
explorer /desktop=name[,widthxheight] app.exe [args]
If the named desktop already exists the
add this
> functionality,
> but arguably not the cleanest.
> 2006-03-21 Thomas Kho <[EMAIL PROTECTED]>
> * dlls/x11drv/keyboard.c
> x11drv: recognize VK_LMENU and VK_RMENU in ALT-key combos
I'm sorry but this is further away from native, not closer. I just made
some tests, and native
On Saturday 11 March 2006 14:03, Tomas Carnecky wrote:
> Vitaliy Margolen wrote:
> > Anything wrong with this patch? It does fix the "stuck alt" problem for
> > games I use alt+tab on.
>
> I can confirm that this fixes the bug. This patch is very important for
> me as I don't have to switch back an
Vitaliy Margolen wrote:
> Anything wrong with this patch? It does fix the "stuck alt" problem for
> games I use alt+tab on.
>
I can confirm that this fixes the bug. This patch is very important for
me as I don't have to switch back and forth between desktop and WoW to
un-stuck they alt-key. This
Anything wrong with this patch? According to MSDN ChoosePixelFormat
should pick closest mode, but not fail.
Vitaliy Margolen
Saturday, March 4, 2006, 10:27:11 PM, Vitaliy Margolen wrote:
> ChangeLog:
> x11drv: Fix one case of "glXChooseFBConfig returns NULL" problem.
Using alpha
Anything wrong with this patch? It does fix the "stuck alt" problem for
games I use alt+tab on.
Vitaliy Margolen
Tuesday, February 21, 2006, 10:30:39 PM, Vitaliy Margolen wrote:
> ChangeLog:
> x11drv: One more fix for "stuck" ctrl, shift & alt.
> DInput needs
"Rein Klazes" <[EMAIL PROTECTED]> wrote:
+ srcpixel = (const DWORD*)((int)srcpixel & 0xfffc);
It would be more readable IMO to use ~3 instead of 0xfffc.
--
Dmitry.
es, it was rather optimized for small code ;-)
Here is the result following your suggestion.
Changelog:
dlls/x11drv : dib_convert.c
Avoid unaligned 32 bit reads, and reads beyond the input pixel buffer in
the convert_888_to_0888_* functions.
Rein.
--- wine/dlls/x11drv/dib_convert.c
1 - 100 of 232 matches
Mail list logo
