Re: Coverity doing scans of Wine codebase!
* Dan Kegel <[EMAIL PROTECTED]> [05/04/06, 22:49:13]: > See http://scan.coverity.com/ > They say they've found 830 potential bugs - that's quite a few. > I haven't seen 'em yet, still waiting for my registration to come through. >From the coverity post on the samba-technical list I gather that they'd prefer if only core developer signed up. I'm not sure if they changed their stance. If they didn't, do you think it'd be possible to get an overview? If every wine dev can sign up, we can of course sign up ourselves. Cheers, Kai -- Kai Blin, (blin at gmx dot net) Tallulah Bankhead barged down the Nile last night as Cleopatra and sank. -- John Mason Brown, drama critic
Coverity doing scans of Wine codebase!
See http://scan.coverity.com/ They say they've found 830 potential bugs - that's quite a few. I haven't seen 'em yet, still waiting for my registration to come through. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Invisible fonts regression
Actually it looks like having fontforge installed *causes* the problem. Try removing /usr/local/share/wine/fonts or making it inaccessible. The problem is due to an old version of fontforge. In Debian, version 0.0.20041218-0.1 generates incorrect ascent information for the Windows font header. Version 0.0.20051205-0.1 gets it right. For Debian users, 0.0.20051205-0.1 is only available in testing and higher. Unfortunately 0.0.20051205-0.1 depends on other things from testing (such as libc6 >= 2.3.5-1), so if you want to build on a pure Sarge system you will need to either do without fontforge, build it yourself, or find a backport somewhere. Hi, I have: fontforge-20060125-6.fc5 installed. I also have every other font under the sun installed, as this is an "everything" install. Removing or moving /usr/share/wine/fonts causes wine to refuse to generate .wine, and start up. In order for that to work, it seems wine requires the directory to exist, and for there to be at least one file in it (/usr/share/wine/fonts/* exists). Making a bogus file in there makes it work. I can see fonts in winecfg, and fonts in the GTA installer in a newly created wine root. I haven't yet tried to install Steam in there. Using my old wine root, Steam still does not work. Otoh the GTA works with the old root.
tasklet - sfd2ttf - eliminate dependency on FontForge (for anybody who's interested)
Hi, Wine's build time dependency on FontForge is causing a bit of a problem, as can be seen by browsing the wine-devel archives for the last month. I propose that a small sfd2ttf utility be written and used instead of FontForge to eliminate the dependency, and make everybody a little happier. George Williams, the author of FontForge, is happy for us to use his code under LGPL, providing that we give the correct attributions. He'd probably like to sign off on the final code though. Alexandre agrees with the idea of an sfd2ttf utility, and is likely to accept it into the Wine tree, provided that is small enough (read 1/2 files) and is appropriately cut down. As I'm busy with my day job at the moment, we're only missing somebody to write it. Any volunteers? Mike
Un-subscribe
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Hi, > > Anyways, when starting in Direct3D mode, it goes > to a back window, but > > quickly flashes back to your desktop, with this > debug: > This looks like a DDraw game. I'll look at it, if > there is a demo available. > > Stefan > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Invisible fonts regression
On Thursday 06 April 2006 13:54, Tom Spear (Dustin Booker, Dustin Navea) wrote: > Is there not an option for debian users similar to rpm's --nodeps option > where it doesnt check the dependencies but installs anyways? There is, but it's bad mojo to use it - it will hurt down the track more than it will to build a backport. Given the problems with older fontforge, it would be nice if the configure script verified that the fontforge version in use was recent enough to work. The problem is there are 21 versions between the two versions I have tested, so unless we're willing to just say "20051205 or higher" somebody will have to figure out which of those is the first viable version. -- Troy Rollo - [EMAIL PROTECTED]
Re: Invisible fonts regression
Troy Rollo wrote: On Thursday 06 April 2006 12:31, Troy Rollo wrote: On Thursday 06 April 2006 11:06, Tom Spear (Dustin Booker, Dustin Navea) wrote: I dont know if this will help, but it is worth a shot... Install fontforge from fontforge.sourceforge.net Actually it looks like having fontforge installed *causes* the problem. Try removing /usr/local/share/wine/fonts or making it inaccessible. The problem is due to an old version of fontforge. In Debian, version 0.0.20041218-0.1 generates incorrect ascent information for the Windows font header. Version 0.0.20051205-0.1 gets it right. For Debian users, 0.0.20051205-0.1 is only available in testing and higher. Unfortunately 0.0.20051205-0.1 depends on other things from testing (such as libc6 >= 2.3.5-1), so if you want to build on a pure Sarge system you will need to either do without fontforge, build it yourself, or find a backport somewhere. Is there not an option for debian users similar to rpm's --nodeps option where it doesnt check the dependencies but installs anyways?
Re: Invisible fonts regression
On Thursday 06 April 2006 12:31, Troy Rollo wrote: > On Thursday 06 April 2006 11:06, Tom Spear (Dustin Booker, Dustin Navea) > > wrote: > > I dont know if this will help, but it is worth a shot... Install > > fontforge from fontforge.sourceforge.net > > Actually it looks like having fontforge installed *causes* the problem. Try > removing /usr/local/share/wine/fonts or making it inaccessible. The problem is due to an old version of fontforge. In Debian, version 0.0.20041218-0.1 generates incorrect ascent information for the Windows font header. Version 0.0.20051205-0.1 gets it right. For Debian users, 0.0.20051205-0.1 is only available in testing and higher. Unfortunately 0.0.20051205-0.1 depends on other things from testing (such as libc6 >= 2.3.5-1), so if you want to build on a pure Sarge system you will need to either do without fontforge, build it yourself, or find a backport somewhere. -- Troy Rollo - [EMAIL PROTECTED]
Re: Invisible fonts regression
On Thursday 06 April 2006 11:06, Tom Spear (Dustin Booker, Dustin Navea) wrote: > I dont know if this will help, but it is worth a shot... Install > fontforge from fontforge.sourceforge.net Actually it looks like having fontforge installed *causes* the problem. Try removing /usr/local/share/wine/fonts or making it inaccessible. -- Troy Rollo - [EMAIL PROTECTED]
Re: WINE & Microsoft WGA
On 4/5/06, Scott Ritchie <[EMAIL PROTECTED]> wrote: Is there a way we could ask Microsoft to use "Wine" instead of "WINE"? You just did ;) -Brian
Re: Invisible fonts regression
Ivan Gyurdiev wrote:
I am no longer able to see fonts in:
- the GTA installer - for example on the intial screen ("What language
to use?")
- Steam (*with* Tahoma previously installed and working). When
selecting menus fonts will flash quickly making the menu visible, and
then disappear.
In addition, when re-creating a new clean wine root, I also lose the
ability to see fonts in winecfg.
This is Wine 0.9.11 on Fedora Rawhide x86_64. There is no error output.
The Steam problem was in the last release as well.
What should I do to track down the problem?
I dont know if this will help, but it is worth a shot... Install
fontforge from fontforge.sourceforge.net
Tom
Invisible fonts regression
I am no longer able to see fonts in:
- the GTA installer - for example on the intial screen ("What language
to use?")
- Steam (*with* Tahoma previously installed and working). When selecting
menus fonts will flash quickly making the menu visible, and then disappear.
In addition, when re-creating a new clean wine root, I also lose the
ability to see fonts in winecfg.
This is Wine 0.9.11 on Fedora Rawhide x86_64. There is no error output.
The Steam problem was in the last release as well.
What should I do to track down the problem?
Re: WINE & Microsoft WGA
Is there a way we could ask Microsoft to use "Wine" instead of "WINE"? ;) -Scott Ritchie On Wed, 2006-04-05 at 15:43 +0200, Marcus Meissner wrote: > Hi, > > Just found by random websearch... > > http://www.microsoft.com/genuine/downloads/FAQ.aspx?displaylang=en > > ... > Q: Will systems running WINE pass WGA validation? > A: Wine is an implementation of the Windows 3.x and Win32 APIs on top >of X and Unix. When WGA validation detects WINE running on the system, >it will notify users that they are running non-genuine Windows, and it >will not allow genuine Windows downloads for that system. Users of WINE >should consult the WINE community for WINE updates. It is important >to note that WINE users, and other users of non-genuine Windows, >can continue to download updates for most Microsoft applications from >Microsoft application-specific sites, such as Office Update. > > Ciao, Marcus > >
Re: Starcraft vs. fullscreen
On 4/5/06, Segin <[EMAIL PROTECTED]> wrote: > > > > > Well if the game crashes, even quitting, then it's likely not going to > restore the resolution no matter what. > > > Ahh, that's where the irony is, it does restore resolution. > Oh, I guess it's not crashing then! =p Haha well where that idea comes from is like when Diablo 2 gets the gamma error, it has already resized the resolution, but decides to quit and not resize it back. Not very nice, but games do funny things like that.
Re: NtProtectVirtualMemory
On Wed, 05 Apr 2006 19:06:41 -0400, Segin wrote: > Hmm... Intresting. I am going to assume, from what I have seen, that > emulated Win32 processes have a represenative POSIX process. Is it > possible to implement a lookup table of sorts to make it work cross-process? The wineserver would have to trigger some code in the client, either by having a signal or a generic background thread that could do it on behalf of the other process. Such a scheme has been discussed before for things like CreateRemoteThread and friends.
Re: NtProtectVirtualMemory
Segin wrote:
Robert Shearman wrote:
Segin wrote:
Could someone clue me in to just what this means and why it is:
err:virtual:NtProtectVirtualMemory Unsupported on other process
A quick Google comes up that function is undocumented, so I don't
have much info on it.
From the wine source:
if (!is_current_process( process ))
{
ERR("Unsupported on other process\n");
return STATUS_ACCESS_DENIED;
}
And that's self explanitory, but why is it "Unsupported on other
process"?
The POSIX & Linux equivalent doesn't take a process ID as an
argument, hence it only operates on the current process.
Hmm... Intresting. I am going to assume, from what I have seen, that
emulated Win32 processes have a represenative POSIX process. Is it
possible to implement a lookup table of sorts to make it work
cross-process?
There is already a lookup in the server, but there is no cross-process
syscall for NtProtectVirtualMemory (and in fact for all of the other
virtual memory functions). The cleanest fix is to get the kernel to
support this. One suggested way of fixing this and other cross-process
problems in Wine without kernel support is to change the context of the
target process to set up a call to the relevant function and restore the
registers afterwards. AFAIK, no one has tried to implement this yet.
--
Rob Shearman
Re: NtProtectVirtualMemory
Robert Shearman wrote:
Segin wrote:
Could someone clue me in to just what this means and why it is:
err:virtual:NtProtectVirtualMemory Unsupported on other process
A quick Google comes up that function is undocumented, so I don't
have much info on it.
From the wine source:
if (!is_current_process( process ))
{
ERR("Unsupported on other process\n");
return STATUS_ACCESS_DENIED;
}
And that's self explanitory, but why is it "Unsupported on other
process"?
The POSIX & Linux equivalent doesn't take a process ID as an argument,
hence it only operates on the current process.
Hmm... Intresting. I am going to assume, from what I have seen, that
emulated Win32 processes have a represenative POSIX process. Is it
possible to implement a lookup table of sorts to make it work cross-process?
Re: NtProtectVirtualMemory
Segin wrote:
Could someone clue me in to just what this means and why it is:
err:virtual:NtProtectVirtualMemory Unsupported on other process
A quick Google comes up that function is undocumented, so I don't have
much info on it.
From the wine source:
if (!is_current_process( process ))
{
ERR("Unsupported on other process\n");
return STATUS_ACCESS_DENIED;
}
And that's self explanitory, but why is it "Unsupported on other
process"?
The POSIX & Linux equivalent doesn't take a process ID as an argument,
hence it only operates on the current process.
--
Rob Shearman
NtProtectVirtualMemory
Could someone clue me in to just what this means and why it is:
err:virtual:NtProtectVirtualMemory Unsupported on other process
A quick Google comes up that function is undocumented, so I don't have
much info on it.
From the wine source:
if (!is_current_process( process ))
{
ERR("Unsupported on other process\n");
return STATUS_ACCESS_DENIED;
}
And that's self explanitory, but why is it "Unsupported on other process"?
Re: Starcraft vs. fullscreen
Jesse Allen wrote: On 4/5/06, Segin <[EMAIL PROTECTED]> wrote: Jesse Allen wrote: On 4/5/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: These lines could explain why Starcraft is unable to switch to fullscreen: err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, returning default fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8 fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8 I seem to remember that BPP cannot be changed _at all_ with XRandR, is this correct? If it is, then the obvious thing to do is to leave BPP alone and just change to the correct resolution. What needs fixing here? You need to have 640x480 in your xorg.conf or XF86Config. If not that try capturing a log with WINEDEBUG=+xrandr and see what is wrong. I don't know... All I get is this AFTER StarCraft quits: X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0x0 Serial number of failed request: 124 Current serial number in output stream: 126 Well if the game crashes, even quitting, then it's likely not going to restore the resolution no matter what. Ahh, that's where the irony is, it does restore resolution.
EU CVS server is not up to date
Hello, The EU CVS server is not up to date. The head of the Changelog is 1.110 while on cvs.winehq it is 1.111. $ cvs -n -d:pserver:[EMAIL PROTECTED]:/home/wine -q log ChangeLog | head RCS file: /home/wine/wine/ChangeLog,v Working file: ChangeLog head: 1.110 branch: locks: strict access list: symbolic names: Wine-0_9_10: 1.110 Wine-0_9_9: 1.109 Regards, Berend.
Re: [opengl] Another possible fix for the BadMatch error
Am Dienstag, 4. April 2006 14:49 schrieben Sie: > 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 note that it's only supported on GLX 1.3 and higher. > > tom As I see if you combine this patch with the one-liner I posted it fixes the BadMatch bug in glXMakeCurrent as well as a piece of code that violates the GLX specification and doesn't break anything, so you could try resubmitting it. I'll take a look at your other patches this weekend. Leon pgpeYObuSs3dr.pgp Description: PGP signature
Re: Starcraft vs. fullscreen
On 4/5/06, Segin <[EMAIL PROTECTED]> wrote: > Jesse Allen wrote: > On 4/5/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: > > > These lines could explain why Starcraft is unable to switch to fullscreen: > > err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, > returning default > fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change > screen BPP from 16 to 8 > fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change > screen BPP from 16 to 8 > > I seem to remember that BPP cannot be changed _at all_ with XRandR, is > this correct? > > If it is, then the obvious thing to do is to leave BPP alone and just > change to the correct resolution. > > What needs fixing here? > > > > > > You need to have 640x480 in your xorg.conf or XF86Config. If not that > try capturing a log with WINEDEBUG=+xrandr and see what is wrong. > > > > > I don't know... All I get is this AFTER StarCraft quits: > > X Error of failed request: BadDrawable (invalid Pixmap or Window > parameter) >Major opcode of failed request: 70 (X_PolyFillRectangle) >Resource id in failed request: 0x0 >Serial number of failed request: 124 >Current serial number in output stream: 126 > > > Well if the game crashes, even quitting, then it's likely not going to restore the resolution no matter what.
Re: SimCity 4 and hardware rendering -- Not working.
Hi, > Anyways, when starting in Direct3D mode, it goes to a back window, but > quickly flashes back to your desktop, with this debug: This looks like a DDraw game. I'll look at it, if there is a demo available. Stefan pgpGOb9BtLcSs.pgp Description: PGP signature
Re: Starcraft vs. fullscreen
On Wed, 2006-04-05 at 13:59 -0400, Segin wrote: > Jesse Allen wrote: > I don't know... All I get is this AFTER StarCraft quits: > > X Error of failed request: BadDrawable (invalid Pixmap or Window > parameter) > Major opcode of failed request: 70 (X_PolyFillRectangle) > Resource id in failed request: 0x0 > Serial number of failed request: 124 > Current serial number in output stream: 126 > > I can confirm getting same error when Fallout2 quits, with and without Stefan's ddraw->wined3d patch.
Re: Starcraft vs. fullscreen
Jesse Allen wrote: On 4/5/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: These lines could explain why Starcraft is unable to switch to fullscreen: err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, returning default fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8 fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8 I seem to remember that BPP cannot be changed _at all_ with XRandR, is this correct? If it is, then the obvious thing to do is to leave BPP alone and just change to the correct resolution. What needs fixing here? You need to have 640x480 in your xorg.conf or XF86Config. If not that try capturing a log with WINEDEBUG=+xrandr and see what is wrong. I don't know... All I get is this AFTER StarCraft quits: X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0x0 Serial number of failed request: 124 Current serial number in output stream: 126
SimCity 4 and hardware rendering -- Not working.
As usual, I went out and found something else to test. SimCity 4 Deluxe works, impeckably well, but it only does software rendering (which can literally bring your system to it's knees). I use a patched .exe cause the default one didn't work for me (and this one has a no-cd deal, plus is smaller). Anyways, when starting in Direct3D mode, it goes to a back window, but quickly flashes back to your desktop, with this debug: err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LINEPATTERN (000a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_MONOENABLE (000b) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ROP2 (000c) value : 000d ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_PLANEMASK (000d) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LASTPIXEL (0010) value : 0001 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISIBLE (001e) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EDGEANTIALIAS (0028) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_RANGEFOGENABLE (0030) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EXTENTS (008a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_VERTEXBLEND (0097) value : ! It then resumes loading in software rendering.
Re: Starcraft vs. fullscreen
On 4/5/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: > These lines could explain why Starcraft is unable to switch to fullscreen: > > err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, returning default > fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to > 8 > fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to > 8 > > I seem to remember that BPP cannot be changed _at all_ with XRandR, is > this correct? > > If it is, then the obvious thing to do is to leave BPP alone and just > change to the correct resolution. > > What needs fixing here? > > > You need to have 640x480 in your xorg.conf or XF86Config. If not that try capturing a log with WINEDEBUG=+xrandr and see what is wrong.
WINE & Microsoft WGA
Hi, Just found by random websearch... http://www.microsoft.com/genuine/downloads/FAQ.aspx?displaylang=en ... Q: Will systems running WINE pass WGA validation? A: Wine is an implementation of the Windows 3.x and Win32 APIs on top of X and Unix. When WGA validation detects WINE running on the system, it will notify users that they are running non-genuine Windows, and it will not allow genuine Windows downloads for that system. Users of WINE should consult the WINE community for WINE updates. It is important to note that WINE users, and other users of non-genuine Windows, can continue to download updates for most Microsoft applications from Microsoft application-specific sites, such as Office Update. Ciao, Marcus
Re: Problem cloning wine repository with git...
Mike McCormack wrote: 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 let it run overnight and it seems to have worked. Took quite a while though. I was expecting a download time similar to that of the kernel. I'm using git version 1.0.4. That's a bit old. How about upgrading to GIT 1.2.5 that was released last night? Will do. I installed a .deb I found, and had planned on downloading git and building if from source. Thanks for the help. Cheers, Scott
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
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 driver just writes to a socket. We try to > synchronize to the hardware by using a one-shot timer set to the > expected processing time calculated from the sound card data > format. The problem I see in the esd driver is that we set a > timeout to poll of for example 12 ms but what we really get is > is a 20 ms sleep. We compensate for this by sending as much > data as we can. Using virtualized hardware like alsa dmix just > removes us even further from the hardware we would like to > synchronize to by blocking. Apart from legacy, is there a reason you haven't moved en-masse to alsa? It is the only supported driver in current kernels now. Talking to oss, the oss compatibility module or worse through a sound driver like esd, arts, gstreamer, jack... etc just adds more potential for desynchronisation. Cheers, Con
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
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, 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 does normal scheduling on current ck > > > (2.6.16-ck3) perform with this? > > > > Hmm, difficult :-\ > > I don't have any game candidate here, and frankly I don't even have a > > current Wine install... > > No need for a full-blown game, I use this great free 5.9MB demo to test > audio on Wine: > http://www.pouet.net/prod.php?which=18359 > > Unbearable with regular Wine (kernel 2.6.13/ amd64, gentoo r5 patchset - > can't test with later kernels, as there's a problem with the SCSI-subsystem > as of 2.6.14), just dandy with Mikes patch and realtime-lsm... Interesting but not what we need. We already know that extra patches make it work, but we want to know what is needed to get it working without unnecessary addons. Cheers, Con
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Willie Sippel wrote: No need for a full-blown game, I use this great free 5.9MB demo to test audio on Wine: http://www.pouet.net/prod.php?which=18359 Unbearable with regular Wine (kernel 2.6.13/ amd64, gentoo r5 patchset - can't test with later kernels, as there's a problem with the SCSI-subsystem as of 2.6.14), just dandy with Mikes patch and realtime-lsm... This works 101% perfectly under WINE (CVS HEAD, no special patches), running as a user, kernel 2.4.31, wine-oss sound driver on top of ALSA 1.0.5a's OSS emulation. Frame rate isn't brilliant (750MHz machine) but audio is spotless. My sound hardware is: 0 [Live ]: EMU10K1 - Sound Blaster Live! Sound Blaster Live! (rev.7) at 0xd800, irq 12 FYI my audio experience with this setup has been flawless with wine for as long as I can remember, at least devoid of the stutters and noise that many people seem to experience. Wow, I just tried the demo with wine's 'native' ALSA driver and the audio does break up a lot... --adam
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
On Wednesday 05 April 2006 11:42, Segin 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 -- I don't get it) > > I can use ALSA if I need to, but I prefer the working legacy API It's not a matter of whether the legacy API works or not, it's the fact that using ALSA allows proper blocked threading which means it's the best way to access the sound card without unnecessary cpu usage and substantially increasing the risk of sound stuttering. WineALSA needs to be the default in my opinion and if it's frustrating to set up that probably needs some attention. Cheers, Con
Re: wine / fontforge regression
[ Charset UTF-8 unsupported, converting... ] > [EMAIL PROTECTED] wrote: > > >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 need to use a prepackaged one from a > >>confidential source who knows what is needed and how to resolve the > >>dependencies. > >> > >> > > > > > >Perhaps because there is NO binary available on > >list of http://www.winehq.org/site/download > Then they can check their distributions source package tree (pkgsrc, > ports, etc.) or binary tree (which compliments pkgsrc, ports, etc. and > is compatable.) > > I mean, come on, can it be that hard to look in ports? If distribution is 4 years old, wine is also. Distributions works good enough, but 4 year old is little different. Or have you different opinion?
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
On Wednesday 05 April 2006 21:47, Aneurin Price wrote: > Con Kolivas 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? > Just to reiterate since everybody seems to forget this part: The problem > does *not* occur when using a 2.4 kernel. Oh I'm quite aware of that. I remember a lot of wine spinoffs refused to support 2.6 for 2 years or so. Threading in 2.6 is much more sensitive. > Additionally, I seem to recall > that when I tried compiling a 2.6 kernel without ALSA support (so OSS is > native and not emulated), the problem went away even with the 2.6 kernel > (this was back around 2.6.11ish time), though I may have misremembered > that. Well that's why I suggested about then. It's not alsa vs oss, but changes in the pipe code at about that time changed how tasks waiting on pipes were scheduled due to code by Linus and Ingo. Hence why I'm suggesting testing 2.6.17-rc1 because I noted this could cause scheduling problems and modified the code recently to fix this and it was pushed into 2.6.17-rc1. This should cause an improvement in latency with any tasks that wait on pipes. Cheers, Con
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Con Kolivas 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? Cheers, Con Just to reiterate since everybody seems to forget this part: The problem does *not* occur when using a 2.4 kernel. Additionally, I seem to recall that when I tried compiling a 2.6 kernel without ALSA support (so OSS is native and not emulated), the problem went away even with the 2.6 kernel (this was back around 2.6.11ish time), though I may have misremembered that.
Re: Alexandre Julliard : configure: Filter out garbage from arts-config --libs too.
On Wed, Apr 05, 2006 at 11:45:09AM +0200, Alexandre Julliard wrote: > Marcus Meissner <[EMAIL PROTECTED]> writes: > > > Currently: > > configure:10975: gcc -m32 -o conftest -D_FORTIFY_SOURCE=2 -O2 -Wall > > -I/opt/kde3/include/artsc -I/opt/gnome/include/glib-2.0 -I/opt/gnome/l > > ib64/glib-2.0/include conftest.c -lartsc -L/opt/kde3/lib64 -ldl -lartsc > > -lpthread -L/opt/gnome/lib64 -lgmodule-2.0 -ldl -lgthread-2.0 -l > > glib-2.0 >&5 > > /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: > > skipping incompatible /opt/kde3/lib64/libartsc.so when searchi > > ng for -lartsc > > /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: > > cannot find -lartsc > > > > > > If I remove it, it does not find /opt/kde3/lib/libartsc.so because it is > > not in the search path. > > So we just do not detect it now, and do not detect it after removing it. > > That sounds reasonable. I don't think we want to try to guess the > paths (or if we do, then we should get rid of the config script > completely, that's a broken concept anyway). I agree here. Ciao, Marcus
Re: Alexandre Julliard : configure: Filter out garbage from arts-config --libs too.
Marcus Meissner <[EMAIL PROTECTED]> writes: > Currently: > configure:10975: gcc -m32 -o conftest -D_FORTIFY_SOURCE=2 -O2 -Wall > -I/opt/kde3/include/artsc -I/opt/gnome/include/glib-2.0 -I/opt/gnome/l > ib64/glib-2.0/include conftest.c -lartsc -L/opt/kde3/lib64 -ldl -lartsc > -lpthread -L/opt/gnome/lib64 -lgmodule-2.0 -ldl -lgthread-2.0 -l > glib-2.0 >&5 > /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: > skipping incompatible /opt/kde3/lib64/libartsc.so when searchi > ng for -lartsc > /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: > cannot find -lartsc > > > If I remove it, it does not find /opt/kde3/lib/libartsc.so because it is not > in the search path. > So we just do not detect it now, and do not detect it after removing it. That sounds reasonable. I don't think we want to try to guess the paths (or if we do, then we should get rid of the config script completely, that's a broken concept anyway). -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH] - rewrote toolhelp implementation only on top of ntdll functions
Eric Pouech <[EMAIL PROTECTED]> writes: > +l = min(ldr_mod[i].BaseDllName.Length, sizeof(mod->szModule) - > sizeof(WCHAR)); > +memcpy(mod->szModule, ldr_mod[i].BaseDllName.Buffer, l); > +mod->szModule[l / sizeof(WCHAR)] = '\0'; > +l = min(ldr_mod[i].FullDllName.Length, sizeof(mod->szModule) - > sizeof(WCHAR)); > +memcpy(mod->szExePath, ldr_mod[i].FullDllName.Buffer, l); This can't work, the dll name and path are in the address space of the target process. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Starcraft vs. fullscreen
On 05/04/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: > I seem to remember that BPP cannot be changed _at all_ with XRandR, is > this correct? Yes.
Re: Wined3d/OpenGL question
Just a guess, but could you check the program ids for the vertex/pixel shaders in drawPrimitiveDrawStrided? ie, prgId in http://source.winehq.org/git/?p=wine.git;a=blob;h=be8c038b273f2bffd4cb76ddc31de3b053c2c47b;hb=2136f3271589afca4c78c84fe503c0a83433ed45;f=dlls/wined3d/drawprim.c#l1800 and http://source.winehq.org/git/?p=wine.git;a=blob;h=be8c038b273f2bffd4cb76ddc31de3b053c2c47b;hb=2136f3271589afca4c78c84fe503c0a83433ed45;f=dlls/wined3d/drawprim.c#l1837
Re: XVidMode is required for Gamma Control
Molle Bestefich wrote: > Mouse grabbing is now broken both with and without UseXVidMode. Scratch that. When using a virtual desktop, DXGrab works fine, with UseXVidMode=Y too. It does screw up if the window is placed near the KDE taskbar and you drag the mouse in that direction, but alas..
Starcraft vs. fullscreen
These lines could explain why Starcraft is unable to switch to fullscreen: err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, returning default fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8 fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8 I seem to remember that BPP cannot be changed _at all_ with XRandR, is this correct? If it is, then the obvious thing to do is to leave BPP alone and just change to the correct resolution. What needs fixing here?
Re: d3d: unhandled texture formats
On Wednesday 05 April 2006 04:13, Jason Green wrote: > 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! > > > > Just fix it :) > > > > > I have some native dlls installed, d3dx9_*.dll, mscoree.dll... that > > > have no wine implementation. > > > > yes, no problem. > > > > > According to msdn: > > > D3DFMT_A16B16G16R16 36 64-bit pixel format using 16 bits for each > > > component. > > > > use GL_RGBA16_EXT for that (GL format is GL_RGBA,GL_UNSIGNED_SHORT) > > > > > D3DFMT_L16 81 16-bit luminance only. > > > > use GL_LUMINANCE16_EXT for that (GL format is > > GL_LUMINANCE,GL_UNSIGNED_BYTE) > > On this topic, how about floating point formats such as > D3DFMT_A16B16G16R16F? I have an app that checks for a lot of missing > float formats. It keeps running even though that function returns > false, but there are tons of graphical bugs. There's a comment in the > code about having to do some card-specific stuff to support this in > OpenGL (NV vs. ATI extensions). > > I tried adding those formats in, but just mapping the individual float > colors over to one of the unsigned int formats (thinking that even if > the colors are wrong, they should still show up as *something* instead > of black). However, I didn't notice any difference in the output. > Eventually wine should support these formats obviously, but is there a > simpler test app out there that could display > surfaces/textures/whatever in each color format and see which ones > work or fail? Civ4 takes a minute just to load, and another 30 > seconds to get into the game portion that fails, so it's not the ideal > test app. :) Always play with beautifull samples :) http://www.gamedev.net/reference/articles/article2108.asp http://www.daionet.gr.jp/~masa/rthdribl/ learn more here http://www.debevec.org/) Regards, Raphael pgpzgPku5JMr6.pgp Description: PGP signature
Re: XVidMode is required for Gamma Control
Jesse Allen wrote: > Just set UseXVidMode = Y in HKCU\Software\Wine\X11 Driver and test the game. Ah, crap, someone's broken it completely. Can't exactly blame UseXVidMode though. It's something that happened after upgrading to 0.9.10. It doesn't switch to fullscreen anymore. Mouse grabbing is now broken both with and without UseXVidMode. *Sigh*. Matt Finnicum wrote: > Starcraft's been working very well for me for much longer than that. If you don't pull source via GIT/CVS/SVN, compile/install and nuke your ~/.wine on a regular basis, you don't count :-).
