On 4/4/06, Jesse Allen <[EMAIL PROTECTED]> wrote:
> On 4/4/06, Segin <[EMAIL PROTECTED]> wrote:
> > Although I have ALSA in my kernel, I also use the OSS compatability, and
> > on top of that, use more regulary than ALSA directly. I use OSS in Wine
> > cause the WineALSA driver is fustrating, and w
On 4/4/06, Segin <[EMAIL PROTECTED]> wrote:
> Although I have ALSA in my kernel, I also use the OSS compatability, and
> on top of that, use more regulary than ALSA directly. I use OSS in Wine
> cause the WineALSA driver is fustrating, and wants odd settings
> (something about DirectSound emulation
Scott Bambrough wrote:
$ git clone http://source.winehq.org/git/wine.git wine-git
defaulting to local storage area
Make sure to start the clone in an empty directory (ie. no existing
.git). The clone might take quite a while, so be patient if it doesn't
go as fast as you expect.
I'm usi
On Tue, 2006-04-04 at 13:37 -0400, Jason Green wrote:
> I may be barking up the wrong tree here, but I'm trying to debug the
> cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in
> drawprim.c (line 1251). This is for Civilization 4 using both
> hardware vertex & pixel shaders.
On 4/4/06, Raphael <[EMAIL PROTECTED]> wrote:
> On Tuesday 04 April 2006 12:48, Ivan Gyurdiev wrote:
> > The F.E.A.R and BF2 demos crash immediately after complaining about:
> > fixme:d3d:D3DFmtGetBpp Unhandled fmt(36,WINED3DFMT_A16B16G16R16)
> > fixme:d3d:debug_d3dformat Unrecognized 81 D3DFORMAT!
On 4/4/06, H. Verbeet <[EMAIL PROTECTED]> wrote:
> I think the first thing you should do, is to verify that it's the call
> to glDrawElements() that's generating the errors. glGetError just
> check if an error flag is set, but if an error flag is set it doesn't
> neccesarily mean the call right bef
Robert Reif wrote:
Con Kolivas wrote:
On Wednesday 05 April 2006 09:45, Robert Reif wrote:
One problem that I am seeing is that there is no practical way to
guarantee synchronization between the sound card hardware and the
sound card thread. OSS doesn't support poll/select reliably in
all
Con Kolivas wrote:
On Wednesday 05 April 2006 09:45, Robert Reif wrote:
One problem that I am seeing is that there is no practical way to
guarantee synchronization between the sound card hardware and the
sound card thread. OSS doesn't support poll/select reliably in
all drivers and the esd
Am Mittwoch, 5. April 2006 00:57 schrieb Con Kolivas:
> On Wednesday 05 April 2006 08:27, Willie Sippel wrote:
> > Am Dienstag, 4. April 2006 16:46 schrieb Andreas Mohr:
> > > Hi,
> > >
> > > On Wed, Apr 05, 2006 at 12:36:06AM +1000, Con Kolivas wrote:
> > > > On Wednesday 05 April 2006 00:34, Andr
Andreas Mohr wrote:
Hi,
On Wed, Apr 05, 2006 at 12:10:37AM +1000, Con Kolivas wrote:
On Wednesday 05 April 2006 00:06, Mike Hearn wrote:
I think for now I shall just maintain this patch out of tree so savvy
users can apply it and get glitch-free audio. I have never been
convinced by t
And as i just said, you can easily fix it (using apropriate textures code
extensions and check support for it)
Yes, it did look easy to fix, but since I can't build wine (I don't have
the proper biarch environment set up in x86_64), I thought I'd bother
the list in the hope that someone else w
On Tuesday 04 April 2006 12:48, Ivan Gyurdiev wrote:
> The F.E.A.R and BF2 demos crash immediately after complaining about:
> fixme:d3d:D3DFmtGetBpp Unhandled fmt(36,WINED3DFMT_A16B16G16R16)
> fixme:d3d:debug_d3dformat Unrecognized 81 D3DFORMAT!
Just fix it :)
> I have some native dlls installed,
On Wednesday 05 April 2006 00:46, Phil Krylov wrote:
> This is only true for RichEdit 2.0 - later versions have better table
> support, while our current implementation is approximately at 2.0 level.
Perhaps, but the problem of CHARRANGE being insufficient to describe the start
and end of renderi
Am Dienstag, 4. April 2006 16:46 schrieb Andreas Mohr:
> Hi,
>
> On Wed, Apr 05, 2006 at 12:36:06AM +1000, Con Kolivas wrote:
> > On Wednesday 05 April 2006 00:34, Andreas Mohr wrote:
> > > And this all should work perfectly well with NON-soft-realtime
> > > scheduling, as clearly said before.
> >
http://www.winehq.org/pipermail/wine-devel/2006-April/046196.html
> It's OK that most people don't have fontforge installed, that just
> means that people who can't cope with compiling from source and can't
>satisfy all the required dependencies to create a working binary
> shouldn't do it. They n
On 4/4/06, Lionel Ulmer <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 04, 2006 at 10:42:18AM -0700, Jesse Allen wrote:
> > 1) Allow XVidMode to init for gamma control regardless the setting of
> > UseXVidMode.
> > I already sent a patch for this.
> >
> > 2) Make UseXVidMode default to "Y".
> >
> > 3) Te
On Tue, Apr 04, 2006 at 09:17:24PM +0200, Stefan Dösinger wrote:
> Of course we might want to fix the mouse code sometimes to make the mouse
> stay
> insinde the virtual desktop or the window with XVidMode at all times if
> that's possible at all.
I tried once to do a 'DXGrab' for the virtual d
On Tue, Apr 04, 2006 at 10:42:18AM -0700, Jesse Allen wrote:
> 1) Allow XVidMode to init for gamma control regardless the setting of
> UseXVidMode.
> I already sent a patch for this.
>
> 2) Make UseXVidMode default to "Y".
>
> 3) Tell people to set UseXVidMode manually.
4) do not return an error
On Tue, Apr 04, 2006 at 01:12:26PM +0200, Alexandre Julliard wrote:
> Marcus Meissner <[EMAIL PROTECTED]> writes:
>
> > It also adds -L/opt/kde/lib64 for me, so this will likely not fully work.
> >
> > I would say we just do not configure arts and esd on 64->32 compiles. :/
>
> Hmmm... does it fa
I'm having trouble cloning the wine repository. I attempt to clone it and
never get any files. All I ever see is:
$ git clone http://source.winehq.org/git/wine.git wine-git
defaulting to local storage area
I've followed the instructions found here:
http://wiki.winehq.org/GitWine
I've
> Just set UseXVidMode = Y in HKCU\Software\Wine\X11 Driver and test the
> game.
Gamma control works in opengl and wined3d with this setting. Tested in Jedi
Academy and Gothic 2 with my ddraw patches
Stefan
pgpQSCc6lypHu.pgp
Description: PGP signature
> that's possible at all. It's pretty annoying that KDE re-aranges all windows
> and icons when a game sets the screen res to 640x480.
Yes, this is pretty annoying. Windows end up becoming fullscreen
after the switch to 640x480 and when the res switches back to
1680x1050 the windows apparently sc
Hi,
> I hope these are acceptible results. These are with my patch applied
> of course. I didn't try without DXGrab. I dunno if it's deprecated or
> not.
Yes, they are fine.
Of course we might want to fix the mouse code sometimes to make the mouse stay
insinde the virtual desktop or the window w
On 4/4/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
> Jesse Allen wrote:
> > I think it used to default to Y until the switch-over to the registry,
> > and the setting got lost.
>
> Perhaps that's why Starcraft suddenly started becoming playable?
>
> You use the mouse to scroll the play area in S
I think the first thing you should do, is to verify that it's the call
to glDrawElements() that's generating the errors. glGetError just
check if an error flag is set, but if an error flag is set it doesn't
neccesarily mean the call right before glGetError generated that
error. The easiest way to d
Jan Zerebecki <[EMAIL PROTECTED]> writes:
> --- a/dlls/wined3d/utils.c
> +++ b/dlls/wined3d/utils.c
> @@ -94,7 +94,7 @@ const char* debug_d3dformat(WINED3DFORMA
> FMT_TO_STR(WINED3DFMT_CxV8U8);
> #undef FMT_TO_STR
>default:
> -FIXME("Unrecognized %u D3DFORMAT!\n", fmt);
> +FIXME(
Jesse Allen wrote:
> I think it used to default to Y until the switch-over to the registry,
> and the setting got lost.
Perhaps that's why Starcraft suddenly started becoming playable?
You use the mouse to scroll the play area in Starcraft, it's
completely broken unless the mouse stays within the
Am Dienstag, 4. April 2006 18:54 schrieb Lee Parsons:
> Hello
> I submitted the bug #4541 regarding running the application WinMDI on wine
> in FreeBSD 6.0:
> http://bugs.winehq.org/show_bug.cgi?id=4541
>
> I have begun regression testing on this bug. I have determined that it
> seems to break on
On 4/4/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hm. How does that interact with XRandr? There are still mouse grab issues in
> some games(half-life comes to mind), often because games do not care to grab
> the mouse. In this case using XVidMode will cause the mouse to leave the
> window, wh
On 4/4/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hm. How does that interact with XRandr? There are still mouse grab issues in
I believe that XRandR is preferred in the current code.
> some games(half-life comes to mind), often because games do not care to grab
> the mouse. In this case usi
On 4/4/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > 1) Allow XVidMode to init for gamma control regardless the setting of> > UseXVidMode.
> > I already sent a patch for this.> >> > 2) Make UseXVidMode default to "Y".> > Let me know what any of you think is best. I'd prefer the first one so> >
-- Forwarded message --From: James Trotter <[EMAIL PROTECTED]>Date: Apr 4, 2006 8:16 PM
Subject: Re: Wined3d/OpenGL questionTo: Jason Green <[EMAIL PROTECTED]>On 4/4/06,
Jason Green <[EMAIL PROTECTED]> wrote:
I may be barking up the wrong tree here, but I'm trying to debug thecaus
Con Kolivas wrote:
>
> Ok. This is not a shot in the dark by the way because you mentioned pipes and
> I had a quick look at the wine sound code. I committed some changes to the
> cpu scheduler in 2.6.17-rc1 that change the way it views sleeping on pipes...
>
Works _much_ better with 2.6.17-rc
On 4/4/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> "Jesse Allen" <[EMAIL PROTECTED]> writes:
>
> >
> > 2) Make UseXVidMode default to "Y".
> >
>
> We should probably do both #1 and #2. I don't think there's any reason
> to have it disabled by default.
>
I think it used to default to Y unt
On 4/4/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
"Molle Bestefich" <[EMAIL PROTECTED]> writes:
> We'll just try again:> Why"/usr/local/bin/../lib/../share/wine/fonts/"> instead of "/usr/local/bin/../share/wine/fonts/">> Might this be a bug?Nope.
--Alexandre Julliard[EMAIL PROTECTED]
> > 1) Allow XVidMode to init for gamma control regardless the setting of
> > UseXVidMode.
> > I already sent a patch for this.
> >
> > 2) Make UseXVidMode default to "Y".
> > Let me know what any of you think is best. I'd prefer the first one so
> > that I won't have people scratching their heads
On 4/4/06, MF <[EMAIL PROTECTED]> wrote:
Hi Tom,After make depend, last lines give this message:quoteld: Relocatable linking with relocations from format elf64-x86-64
(/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.UrlAln.o)is not supportedwinebuild: ld -m elf_i386 -r failed with stat
"Jesse Allen" <[EMAIL PROTECTED]> writes:
> There are three ways to fix the problem:
> 1) Allow XVidMode to init for gamma control regardless the setting of
> UseXVidMode.
> I already sent a patch for this.
>
> 2) Make UseXVidMode default to "Y".
>
> 3) Tell people to set UseXVidMode manually.
>
>
I've found that XVidMode is required for gamma control, and that it
defaults to off. There are two bug reports about gamma. One is Diablo
2 as it fails to run at all in D3D mode because of it (and with a
cryptic error too). The other is the gamma slider fails to produce the
effect.
There are three
I may be barking up the wrong tree here, but I'm trying to debug the
cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in
drawprim.c (line 1251). This is for Civilization 4 using both
hardware vertex & pixel shaders. I've only noticed this error when it
is passed GL_TRIANGLES wi
On 4/4/06, Mike Hearn <[EMAIL PROTECTED]> wrote:
> > Audio playback and decoding should not really use much cpu.
>
> I'm not even sure we can control that. Some games seem to set up their
> own mixing threads and such (looking at the SDL Win32 code it calls
> SetThreadPriority itself).
>
Ah, I ha
On Wednesday 05 April 2006 00:46, Andreas Mohr wrote:
> Hi,
>
> On Wed, Apr 05, 2006 at 12:36:06AM +1000, Con Kolivas wrote:
> > On Wednesday 05 April 2006 00:34, Andreas Mohr wrote:
> > > And this all should work perfectly well with NON-soft-realtime
> > > scheduling, as clearly said before.
> > >
On Wednesday 05 April 2006 00:06, Mike Hearn wrote:
> > Is it kernel dependant? Does 2.6.11 for example exhibit the problem or
> > only recent kernels? Or has noone tried an older kernel like that?
>
> I think this has been a problem since time immemorial. Previous
> discussions like this one have
Hello
I submitted the bug #4541 regarding running the application WinMDI on wine
in FreeBSD 6.0:
http://bugs.winehq.org/show_bug.cgi?id=4541
I have begun regression testing on this bug. I have determined that it
seems to break on 20050921, as 0921 works and 0922 does not.
However, I have been
On Wednesday 05 April 2006 00:34, Andreas Mohr wrote:
> Hi,
>
> On Wed, Apr 05, 2006 at 12:10:37AM +1000, Con Kolivas wrote:
> > On Wednesday 05 April 2006 00:06, Mike Hearn wrote:
> > > I think for now I shall just maintain this patch out of tree so savvy
> > > users can apply it and get glitch-fr
On Wednesday 05 April 2006 00:49, Mike Hearn wrote:
> >>> Don't give up now as you will convince everyone else there is no
> >>> solution and only your patch will make games work. Your attitude is
> >>> defeatist because you're convinced that real time scheduling is your
> >>> saviour.
>
> I don't
On Tuesday 04 April 2006 23:29, Mike Hearn wrote:
> > I know I didn't offer a solution, just standard rules for multithreaded
> > application writing. The fact that wine is a compatibility layer rather
> > than its own application is most of your problem. Is there no way wine
> > could have an audi
On Tuesday 04 April 2006 23:46, Mike Hearn wrote:
> > By infinite loop I assume you mean it is sleeping, not burning cpu... But
> > anyway, is this a separate thread or part of a monolithic "wine"?
>
> Right, it blocks on a message pipe. It's a separate thread.
>
> > I think fragile is too harsh a
Am Dienstag, 4. April 2006 14:49 schrieb Tomas Carnecky:
> Leon Freitag wrote:
> >> BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
> >> patch but it was rejected.
> >
> > Well, try to resubmit it :) Or post it here, so that others could test
> > it. Perhaps you could merge th
Am Dienstag, 4. April 2006 14:49 schrieb Tomas Carnecky:
> Leon Freitag wrote:
> >> BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
> >> patch but it was rejected.
> >
> > Well, try to resubmit it :) Or post it here, so that others could test
> > it. Perhaps you could merge th
On Tuesday 04 April 2006 22:42, Mike Hearn wrote:
> > What strikes me is that people are very happy to think that the kernel is
> > going to fix this problem. I have to tell you there will be no more
> > infrastructure put into the kernel anytime soon to help you here.
>
> I'm confused about this p
"Molle Bestefich" <[EMAIL PROTECTED]> writes:
> We'll just try again:
> Why"/usr/local/bin/../lib/../share/wine/fonts/"
> instead of "/usr/local/bin/../share/wine/fonts/"
>
> Might this be a bug?
Nope.
--
Alexandre Julliard
[EMAIL PROTECTED]
Leon Freitag wrote:
> Am Dienstag, 4. April 2006 14:49 schrieb Tomas Carnecky:
>> Leon Freitag wrote:
BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
patch but it was rejected.
>>> Well, try to resubmit it :) Or post it here, so that others could test
>>> it. Perhaps
Molle Bestefich wrote:
* It's a compile-time problem, but you ERR about it at run-time.
* You do not tell in your error message what the ground cause for the ERR is.
Some patches have been applied to Wine that should improve the
situation. We now only warn at configure time.
Mike
> > err:font:ReadFontDir Can't open directory
> > "/usr/local/bin/../lib/../share/wine/fonts/"
> >
> > when fontforge isn't installed.
>
> Missing fontforge means that you don't have Wine builtin fonts
> which leads to the above problems. The solution obviously is to
> install fontforge
Yes, a
Hmm, difficult :-\
I don't have any game candidate here, and frankly I don't even have a current
Wine install...
Getting a new Wine is easier than a new kernel :) The game I played with
is a demo, available here:
ftp://ftp.infogrames.net/demos/imperiumgalactica2/ig2_english.zip
It's a rea
Hi,
On Tue, Apr 04, 2006 at 03:49:56PM +0100, Mike Hearn wrote:
> So in this case either the CPU time goes way high when the 3D scene
> first appears, or maybe my 3D driver (nvidia) is not allowing
> pre-emption enough.
nvidia... nvidia... Hrmmm... might this just be caused by the recent
annoyi
Don't give up now as you will convince everyone else there is no solution
and only your patch will make games work. Your attitude is defeatist
because you're convinced that real time scheduling is your saviour.
I don't want to do that! If there are other [robust] solutions I'm all
ears. The pa
On Tue, 4 Apr 2006 11:46:18 +1000
Troy Rollo <[EMAIL PROTECTED]> wrote:
> + * *** Notes on tables ***
> + *
> + * The CHARRANGE structure passed in the FORMATRANGE structure is not
> + * sufficient to deal with tables, where we would need information on the
> + * start position for text in each co
Hi,
On Wed, Apr 05, 2006 at 12:36:06AM +1000, Con Kolivas wrote:
> On Wednesday 05 April 2006 00:34, Andreas Mohr wrote:
> > And this all should work perfectly well with NON-soft-realtime scheduling,
> > as clearly said before.
> > Well, in theory, at least...
>
> Andi just out of interest, how d
Hi,
On Wed, Apr 05, 2006 at 12:10:37AM +1000, Con Kolivas wrote:
> On Wednesday 05 April 2006 00:06, Mike Hearn wrote:
> > I think for now I shall just maintain this patch out of tree so savvy
> > users can apply it and get glitch-free audio. I have never been
> > convinced by this sacred devotion
Hi Troy,
any chance you can also provide a conformance test,
however trivial?
(Also, from reading
http://discuss.fogcreek.com/joelonsoftware3/default.asp?cmd=show&ixPost=97326&ixReplies=5
http://support.microsoft.com/default.aspx?scid=kb%3Ben%3B129860
http://www.codeproject.com/printing/richeditpr
Is it kernel dependant? Does 2.6.11 for example exhibit the problem or only
recent kernels? Or has noone tried an older kernel like that?
I think this has been a problem since time immemorial. Previous
discussions like this one have always gone around in the same circle -
it needs root what do
By infinite loop I assume you mean it is sleeping, not burning cpu... But
anyway, is this a separate thread or part of a monolithic "wine"?
Right, it blocks on a message pipe. It's a separate thread.
I think fragile is too harsh a way to describe it. You're not after 100%
realtime guarantee, j
I know I didn't offer a solution, just standard rules for multithreaded
application writing. The fact that wine is a compatibility layer rather than
its own application is most of your problem. Is there no way wine could have
an audio thread that does nothing but the compatibility component betw
Hi,
On Tue, Apr 04, 2006 at 01:13:09AM +0200, MF wrote:
> I reattach the config.log
Whoa, that's 838kB, could you *please* gzip it before attaching?
(probably like 50kB or so then)
I don't have any trouble with large mails, but many other people do.
What about the wine-devel mail size limit? I r
Leon Freitag wrote:
>> BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
>> patch but it was rejected.
>
> Well, try to resubmit it :) Or post it here, so that others could test it.
> Perhaps you could merge this one-liner into it and then resubmit it.
>
Yep, here it is. But
What strikes me is that people are very happy to think that the kernel is
going to fix this problem. I have to tell you there will be no more
infrastructure put into the kernel anytime soon to help you here.
I'm confused about this point. You say the kernel won't be changing
anytime soon - do
Dmitry Timoshkov wrote:
I'd suggest to add freetype and fontforge to the optional support
libraries
list in the README file and be done with this "regression".
I am all for this listing in README, however this one causes many hard
to explain problems. Until I read this thread I was
On Tue, 4 Apr 2006 01:47 am, Andreas Mohr wrote:
> Hi,
>
> [sneaked in another CC, JFYI ;]
Oh hi! This is the first time this thread has been brought to my attention.
> On Mon, Apr 03, 2006 at 04:29:43PM +0100, Mike Hearn wrote:
> > And even then, SCHED_ISO is a long way off and may never be merg
> The BadMatch in X_GLXCreateGLXPixmap is another problem.. here you
> should get a BadMatch in X_GLXMakeCurrent.
That's true, this patch should only fix the BadMatches in glXMakeCurrent.
> BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
> patch but it was rejected.
Well, tr
MF wrote:
Tom, Robert,
First and above all thanks for your kind answers. First time I post for
help (I usually get myself out of trouble by reading other people's q&a)
and I was touched by the "net magic"...
Installing the ia32-libs-dev package and running the uninstall / install
procedure supr
Marcus Meissner <[EMAIL PROTECTED]> writes:
> It also adds -L/opt/kde/lib64 for me, so this will likely not fully work.
>
> I would say we just do not configure arts and esd on 64->32 compiles. :/
Hmmm... does it fail to link if you simply remove the -L/opt/kde/lib64?
And if it fails, does config
On Tue, Apr 04, 2006 at 05:37:44AM -0500, Alexandre Julliard wrote:
> Module: wine
> Branch: refs/heads/master
> Commit: 197a7d0422b2dd60009e405bc254ca616327fbf0
> URL:
> http://source.winehq.org/git/?p=wine.git;a=commit;h=197a7d0422b2dd60009e405bc254ca616327fbf0
>
> Author: Alexandre Julliard
The F.E.A.R and BF2 demos crash immediately after complaining about:
fixme:d3d:D3DFmtGetBpp Unhandled fmt(36,WINED3DFMT_A16B16G16R16)
fixme:d3d:debug_d3dformat Unrecognized 81 D3DFORMAT!
I have some native dlls installed, d3dx9_*.dll, mscoree.dll... that have
no wine implementation.
According
"James Hawkins" <[EMAIL PROTECTED]> writes:
> Changelog:
> * Rewrite get_parameter so that it can handle empty parameters.
You are still parsing the whole string for every parameter, this is
O(n^2) which isn't very nice. What you want is a strtok-style
function to retrieve parameters sequentially
76 matches
Mail list logo
