Re: Wined3d being used with VirtualBox D3D
> All, > > An interesting piece from Phoronix about new VirtualBox Direct3D > support; which apparently uses WineD3D in the backend. I haven't > noticed anything in particular but has Sun been filing bugs / sending > patches? > > http://www.phoronix.com/scan.php?page=news_item&px=NzAyNA > > --Zach > A couple of months ago when VirtualBox received opengl support I contacted some of their developers using irc and told them how to run WineD3D on Windows and gave them some test dlls. It seems they picked it up. They are just using stock WineD3D (with two or three hacks to work around bugs in their GL implementation). Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
Re: DIB Engine - Separated in small patches
> As requested I separated the engine in small patches, trying to keep > original authors when possible. > As the post didn't appear here (problem with zipped files, maybe ?), > I've put it on bug 421 page. > I whish to know if it can be ok for including on wine tree. > > Ciao > > Max Getting large patches into Wine takes time especially drastic changes like the DIB engine. Recently I aksed him about this DIB work on IRC and while he didn't check the patches in much detail yet he has huge doubts whether the chosen design is the good one. (Allen his design wasn't good; Huw his design was better) I would recommend to invite all the people interested in a DIB engine (Alexandre, Allen, Huw and perhaps others) for a meeting on IRC to discuss the current design and how to proceed. Roderick -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
Re: 1.1.15 failing to build -- what changed?
> 1.1.15 fails to build using an identical layout to 1.1.14, which means
> something has changed with either the build dependencies or the way
> configure is working.
>
> Here's the build failure I'm getting on amd64, but it fails on all
> arches:
> http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_1.1.15~winehq0~ubuntu~8.10-0ubuntu1_FAILEDTOBUILD.txt.gz
>
> I'm going to sleep now, but hopefully I'll figure this out Valentine's
> day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages
> just yet.
>
> Thanks,
> Scott Ritchie
>
A packager of a debian based distro reported the same issue. They are doing:
CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" ./configure
--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info $(CONFFLAGS)
Where the two DEB_* variables are:
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
When building 32-bit packages DEB_HOST_GNU_TYPE is set to i486-linux-gnu and
this results in 'i486-linux-gnu-as not found'.
Personally I consider it a misconfigured build system. It can be fixed by
installing the proper binutils package for this architecture which I'm sure
debian has. The same should be done for your ubuntu packages. You can't expect
apps to build if you only have one half of the build apps (the compiler).
Roderick
--
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
> I don't want to be rude, but I have better things to do than > propagandize my solution. We can live without such library in Wine, it > would just require us to maintain separate libraries for different > libc or wine versions. Having it in wine distribution would solve this > problem smoothly, reducing our task only to maintain native Linux > shared lib for hardware access. If anything changes in your position, > let me know, I am willing to help with it. > > Martin > So now and then things come by which would be useful for some Wine users / developers but which aren't suited for inclusion in Wine. Nonetheless I think we need a place where such things can be stored. Perhaps that should be done on the Wine wiki (not sure if we can upload files to there). I can imagine that we should put a porting page there and mention winelib and winegate. Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
Re: Win to Lin Library Wrapper
> I had an interesting thought the other day, and that is to having some > built > in support for forwarding windows dlls to linux .so's. A while back, I had > worked on the CUDA wrapper, which basically just transfers the calls from > the dll to so. At that point I didn't work on a CAL wrapper because there > was not linux support from ATI with CAL. Now there is, and has been and > someone has requested a CAL wrapper for fold...@home. I've started the > work > on it but I have been thinking, that I think it might be benifical to have > some sort of built in support in wine for this. A method for automatically > sending calls made to a .dll to the linux counterpart .so, if one exist. > The > work involved with making a wrapper for CUDA or CAL isn't that much, it's > fairly simple in the grand scheme of things. However I'm sure there must > be > a lot of 3rd party, non-microsoft libraries that have windows and linux > counter parts, that both expect the same inputs and. I know wine already > does a lot of this, but some sort of automation in the process, in which > if > a call is made to cudart.dll, wine sees it, and transfers the calls to > cudart.so. The list of .dlls and respective .so s could simply be kept in > the registry for easy editing, and adding of libraries without the need to > recompile wine. > > Hopefully I've put my idea across clearly. What are everyone's thoughts? > > Thanks, > > Seth Shelnutt Years ago we had this functionality is Wine. Next to 'builtin', 'native' we had an option 'so'. It worked for glide2x/glide3x but for the rest not for much other libs. It was dropped during some debugging rewrite if I rememeber correctly. I don't remember if it was due to maintenance issues or because of some technical issue. Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
Re: Win to Lin Library Wrapper
> On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson > wrote: > > > On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote: > > > I had an interesting thought the other day, and that is to having some > > > built in support for forwarding windows dlls to linux .so's. > > > > IIRC, this kind of thing is generally discouraged, except in cases where > > needed (eg. opengl32). Part of the problem is internal differences.. for > > example, what would a Linux .so do if it's given a Win32 filename path? > > Other > > problems would be if the Linux equivalent wants a Window for a function > > argument and the DLL wants an HWND instead, or if the DLL has > > more/different > > functions (eg. CUDA on Win32 has functions for dealing with D3D objects; > > CUDA > > on Linux doesn't, and it wouldn't be straight forward to even implement > > them > > through wined3d). > > > > Something like OpenGL, and even OpenAL to some degree, would directly > > benefit > > from having the DLLs forwarded to their host equivalents as it provides > > better > > access to the hardware and better integration with the host system. > > Something > > like zlib or ogg/vorbis and stuff wouldn't though, since the code should > > largely be the same, and save for some bugs/inefficiencies in Wine > (which > > should be fixed), would work identically. > > > > > > > Does Wine yet have the capability to interface with HAL for Win32 hardware > access similar to NT? It looks like it doesn't from all this talk of > forwarding DLLs. What we should do instead of trying to forward DLLs, > which > is asking for more trouble than its worth, is try to get the NT layer to > connect to UNIX HAL so that DLLs can link directly to HAL and operate the > hardware. This can't be done. You would be writing your own operating system and hardware can't be shared. It is not that hard to write wrapper libraries. Second even if libraries look similar between OSes take for instance Cuda it does offer OS-specific functionality like e.g. Direct3D integration. Roderick -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
How to enable font anti-aliasing in Wine?
Hi, This weekend I was reading the 'Dutch slashdot' (tweakers.net) about Wine 1.1.17 and a user was wondering when Wine would finally support font anti-aliasing. I said we have been supporting this for ages. I also thought I was using it on my own Debian system. When asking more and more users about it in #winehackers (Chris, Detlef, Marcus, Stefan ..) only Stefan had it working on a Wine 1.1.0 build he still had around on his system (he didn't have a newer normal Wine copy) on his Gentoo. Further nobody on Debian, Fedora, Gentoo or Suse had it working except someone on a old 1.0 Wine. For the record when anti-aliasing is around Winecfg should look like: http://stud4.tuwien.ac.at/~e0526822/winecfg.png (this on Stefan his 1.1.0). What is so special about Wine why anti-aliasing isn't working for most users? (it could be a regression) In Stefan his case it started working after installing a Windows tahoma.ttf. What is so special about this font? A modern Linux system has dozens or hundreds of fonts installed and both GNOME/KDE can use each font AA'ed without issues. Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
Re: How to enable font anti-aliasing in Wine?
> 2009/3/15 Roderick Colenbrander : > > > What is so special about Wine why anti-aliasing isn't working for most > users? (it could be a regression) In Stefan his case it started working > after installing a Windows tahoma.ttf. What is so special about this font? A > modern Linux system has dozens or hundreds of fonts installed and both > GNOME/KDE can use each font AA'ed without issues. > > > I recently reinstalled this system with Ubuntu 8.10 and its inbuilt > Wine 1.0.1. I then added the budgededicated.com repo to get the > fortnightly snapshots. A string of registry changes enabled smoothed > fonts for me: > > http://forum.winehq.org/viewtopic.php?p=20061&sid=6fbbcf362e44a66b310ef88f631c83f5 > > However, it's deeply problematic that I had to do this at all instead > of it Just Working when Wine was updated. This is just broken. > > > - d. > For Stefan (and some others who tried 1.0) I believe it worked on a PLAIN wine config without any registry settings. Where these options added after 1.0? (I think the subpixel one was) Perhaps these options should appear in winecfg or perhaps even be turned on by default and let users disable it in there if needed. Thanks, Roderick -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
Re: How to enable font anti-aliasing in Wine?
> Roderick Colenbrander wrote: > >> 2009/3/15 Roderick Colenbrander : > >> > >>> What is so special about Wine why anti-aliasing isn't working for most > >> users? (it could be a regression) In Stefan his case it started working > >> after installing a Windows tahoma.ttf. What is so special about this > font? A > >> modern Linux system has dozens or hundreds of fonts installed and both > >> GNOME/KDE can use each font AA'ed without issues. > >> > >> > >> I recently reinstalled this system with Ubuntu 8.10 and its inbuilt > >> Wine 1.0.1. I then added the budgededicated.com repo to get the > >> fortnightly snapshots. A string of registry changes enabled smoothed > >> fonts for me: > >> > >> > http://forum.winehq.org/viewtopic.php?p=20061&sid=6fbbcf362e44a66b310ef88f631c83f5 > >> > >> However, it's deeply problematic that I had to do this at all instead > >> of it Just Working when Wine was updated. This is just broken. > >> > >> > >> - d. > >> > > > > For Stefan (and some others who tried 1.0) I believe it worked on a > PLAIN > > > wine config without any registry settings. Where these options added after > 1.0? (I think the subpixel one was) Perhaps these options should appear in > winecfg or perhaps even be turned on by default and let users disable it > in > there if needed. > > > There is already a bug for that: > http://bugs.winehq.org/show_bug.cgi?id=16729 > > It's back to the discussion of people just breaking stuff and never > following up to fix it. Because they don't care or it's not their problem. > > Vitaliy > Thanks I hadn't seen the bug report. As far as I understand it, the only issue left is the lack of a default registy settings in wine.inf (and winecfg support) ? Roderick -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
Re: SoC: DirectShow/Gstreamer
> Hi, > > I'm interested in applying for a GSoC project related to wine. I am > looking at doing the DirectShow/Gstreamer idea that is listed in the > wiki (http://wiki.winehq.org/SummerOfCode). From the idea description > there are a number of factors that would make this an ideal solution. > The description mentions the availability of legal codecs (from > fluendo) plus the ability to use the codecs already exposed to > gstreamer (ie. install a codec and native/wine applications instantly > get support). > > Recently GStreamer has added some pipeline elements targeted at > integrating with other frameworks (appsrc/appsink) which allow sending > data down a gstreamer pipeline and/or recieving it. Prior to these > you had to write your own element (this wasn't too much work either > depending on your needs and may still be preferred for more > compatibility). > > I am quite familiar with both C and GStreamer. I have never looked at > DirectShow though from what i know they are similar in concept. > GStreamer does have some DirectShow filters that allow it to use > directshow elements inside GStreamer (on windows anyway). > > My experience with wine has been limited to my own experiments. I've > played around with audio drivers for wine. I wrote one that used > GStreamer and later adjusted this to use pulseaudio instead. I never > got time to clean them up to the point of submitting them. > > I have a few questions in regard to this idea. Do you think this > project would provide adequate work to occupy the SoC timeframe? I > would have to learn DirectShow which I don't believe would be too > difficult. I've worked with DirectSound/DirectX and would expect it > to require a similiar amount of work. I've also spent a fair amount > of time inside wine's source code looking into various bugs. > > I welcome any comments, suggestions or idea related to this. I'd love > any feedback so I know this is an idea that is wanted (i would like > it...i use wine quite often) and so my application is as good as it > can be. > > Cheers, > Trevor Davenport > Hi Trevor, I was the one who put this project suggestion on the wiki. Personally I think it should be a fine soc project. The project would be quite flexible. I expect that the project is too broad and initially should be confined to some widely used audio / video codecs and some widely used rendering methods (rgb / yuv). There will likely be bugs enough to fix ;) Further I would define one or more apps you want to get working. If I remember correctly some games want to use mpeg or divx for movie playback (Warcraft III uses another codec). The ultimate app to get working using wine's quartz + gstreamer would of course be Windows Media Player ;) Though an open source media player like Media player classic which can use the same codecs is likely easier because you have the source. Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
Re: GSoC Idea: D3DXMesh
> Just an idea I came up with for Google's summer of code is perhaps > implementing some of the D3DXMesh header files and functions so that > we can get on with implementing functions such as D3DXCleanMesh which > I believe Assassin's Creed needs. > > I have no intention of applying for GSoC however it's an idea I'd like > to put into the pot. > D3DXMesh is a small part of D3DX. Unfortunately just implementing this class won't help much games since most games mainly use d3dx for the hlsl compiler. Sure they might also use it for this and other stuff (e.g. matrix calculations and so on) but it isn't its main use. Parts of d3dx could be put up for GSoc but implementing the full dll is a huge job. I'm not sure if there are people motivated to work on this for months during GSoc. Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
Re: GSoC Idea: D3DXMesh
> Your email left me confused because you say implementing D3DXMesh is > small however towards the end of your email say it is a large job. > Surely having something small is good for SoC projects, no? > D3DX is huge and D3DXMesh is a small part of it but I meant that just implementing D3DXMesh isn't that useful as it won't get apps running. All serious apps which use D3DX at least use it for the shader compiler. Roderick -- Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal geschützt? Jetzt absichern: https://homebanking.gmx.net/?mc=m...@footer.hb
Re: libwine: Only partially reserve memory beyond 0x80000000 on FreeBSD.
Original-Nachricht > Datum: Wed, 18 Mar 2009 20:31:35 +0100 > Von: Tijl Coosemans > An: Francois Gouget > CC: wine-devel@winehq.org, wine-patches , Alex > Kozlov > Betreff: Re: libwine: Only partially reserve memory beyond 0x8000 on > FreeBSD. > On Wednesday 18 March 2009 16:36:29 Francois Gouget wrote: > > Tijl Coosemans a écrit : > >> After enabling the memory reservation code on FreeBSD last week, > >> several games either suffer a performance loss or simply crash, > >> often with GL_OUT_OF_MEMORY errors or similar out of memory errors > >> from X libs. (Tested with nvidia driver and opensource r300 dri > >> driver.) > > > > Which games can be used to reproduce this issue? Is one of them > > freely downloadable? Even better, can this issue be reproduced with a > > non-game application? > > Puzzle Quest is a game that starts up slowly and locks up before > getting to the game menu. > > http://www.infinite-interactive.com/puzzlequest.php?page=demo > > Alex Kozlov (CCed) can give you more examples. He mentioned StarWolves, > Warlords4, Erherlords, Soldier of Fortune Gold, Fall: Last Days og > Gaia, Dominions3... > > Normal applications all seem to work. > > > Also, won't this patch be obsolete once Alexandre completes his > > current OpenGL memory allocation work? That is, doesn't it just hide > > the problem rather than solving it? > > I don't know what Alexandre's work involves, but the problem here are > malloc(3) and mmap(2) calls in code outside Wine. On FreeBSD mmap > allocates upwards starting after the location of the executable + some > malloc heap space. With everything above 0x8000 reserved and the > wine executable located at 0x7bf0, there's only about 64MiB of > address space left of which about 32MiB is currently designated malloc > heap (loader/main.c:RLIMIT_DATA). The 32MiB that is left is just enough > to contain all unix and Wine libs, and a 32MiB malloc heap seems to be > enough for all normal applications. I attached a typical layout. > > >> It also causes other problems like: > >> http://bugs.winehq.org/show_bug.cgi?id=17718 > > > > This bug mentions the following error: > > Fatal error 'Cannot allocate red zone for initial thread' at line 384 > > in file /usr/src/lib/libthr/thread/thr_init.c (errno = 2) > > > > It would be nice to figure out how we get in init_main_thread(). > > Apparently there are only two possible cases: > > * 1) Some thread routines have detected that the library hasn't yet > > * been initialized (_thr_initial == NULL && curthread == NULL), > or > > * > > * 2) An explicit call to reinitialize after a fork (indicated > > * by curthread != NULL) > > > > I don't really understand why we would reallocate the stack in the > > first case so my guess is this happens through a fork. > > I've never been able to reproduce this and haven't looked at it very > closely because the problem went away with this patch, but my best > guess is case 1. The threading lib is only initialized when actually > needed. And then perhaps it fails to allocate the red zone for the main > process stack because that page has already been reserved. That doesn't > explain why I can't reproduce it though. > > >> This patch only partially reserves memory, enough for the shared > >> heap, virtual heap and wine top-down allocations, and leaves the > >> majority unreserved. > > > > Isn't the memory reservation supposed to prevent Unix libraries from > > being mapped in this memory range? If so, won't leaving holes open us > > to this sort of trouble again? > > > > Also, besides FreeBSD's braindead stack allocation routines, why > > should this patch only be used on FreeBSD? If it's supposed to help > > with OpenGL memory allocation then shouldn't it be used on Linux too > > (which has the same issue with OpenGL)? > > The memory reservation is needed on Linux because mmap allocates > downwards from the end of address space, so without reservation all > libs end up far beyond 0x8000 close to the stack. On FreeBSD mmap > allocates upwards so the layout in the attached file for instance looks > the same with or without reservation. On FreeBSD the memory reservation > doesn't really solve any problem. > > What exactly is the issue with OpenGL on Linux? Under OpenGL we have the same issue these days for both Nvidia and Ati hardware. Check http://bugs.winehq.org/show_bug.cgi?id=13335 which contains an early version of Alexandre his patch. There are still some issues with it (some threading one if I remember correctly) and most importantly on 64-bit Nvidia systems there are huge slowdowns. I have some Nvidia employee looking at that but haven't heard back. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
Re: SOC 2009: Application Test Suite
Hi Austin, Not sure if you are aware of it but there is also cxtest which was written by codeweavers under the gpl. See http://cxtest.ifne.eu:82/ it seems they (still?) use it regulary to track regressions. I haven't looked at it and don't know that autohotkey stuff but how do both differ? Wouldn't it be better to continue with cxtest? Or perhaps it would be better to use autohotkey (assuming it is a widely used app) and extend it so that cxtest can be dropped. Roderick On Wed, Mar 25, 2009 at 12:33 AM, Austin English wrote: > Howdy, > > I'm planning on applying for Google Summer of Code 2009. I'm pretty > sure most people reading this list already know me, but for those that > don't, I frequently triage bugs in Bugzilla, help users on the forum, > and a few other things. I've also done quite a bit of work testing > wine on more obscure OS's (OpenSolaris, FreeBSD, OS X, NetBSD, > OpenBSD). > > I'd like to implement an application test suite. It's something that's > been discussed for Wine for quite a while, but has never been put into > place. I took a bit of time a while back and hacked couple a couple > quick scripts as a test, and got a script to automatically install > Firefox 3 in Wine using AutoHotKey (http://www.autohotkey.com/). I've > made a couple more scripts as well, but they don't match Windows > behavior because of bug (http://bugs.winehq.org/show_bug.cgi?id=10147) > hint, hint (disclaimer, I haven't tested that script in a while, been > busy with exams, so that bug might be fixed...I don't think it has > though). > > My plan to implement it is to make a script, that can be used > standalone, in conjunction with Patchwatcher, or any other script, to > test wine against several real world applications. I make a very quick > proof of concept (attached), which is based off of winetricks. It's > _REALLY_ rough at the moment, (I haven't had time to mess with it > lately), but demonstrates the idea. The script setups a clean > WINEPREFIX, installs autohotkey, removes the Z: symlink for braindead > installers that search the entire hard drive, and sets up a link to > it's install cache (essentially winetrickscache). From there, it makes > a copy of this prefix, so on subsequent installers/applications, we > can restore the clean prefix and save a few seconds. > > From there, so far, it only installs firefox3. The plan is to add > several dozen different tests, for various functions of wine. > Obviously, I'd like to start with platinum rated applications, to > prevent regressions. From there, the current list of > applications/functions to target are: > 1. Firefox3 - useful for testing lots of other things, e.g., > java/flash, etc. Easy to test. > 2. Microsoft Office - We've broken this a few times in recent months, > so adding a test in daily git for it would help catch regressions > sooner. > 3. World of Warcraft - I don't play, but A) It's really popular, and > B) also gives us a chance to test wininet for regressions. > 4. iTunes - this installers been broken a couple times. The bonjour > service should allow for testing services related regressions. > 5. Adobe suite - there haven't been too many regressions here that I > can remember, but it's definitely an area we should watch out for. > > Of course, we don't want to only test the installer's keystrokes/mouse > inputs, so SHA1 checksumming of installed files would verify against > corrupted files/setupapi regressions/etc. Once a few installer tests > are in and working well, I plan to extend the tests further to test > running the application, e.g, for photoshop by opening a file, > inserting a circle, and saving it. This is a bit harder to pull off in > Autohotkey in a way that's portable, so I'm saving that sort of thing > for later. > > Also interesting would be a real application's test suite. Dan > suggested using Google Chrome's, since it's squeaky clean after using > lots of Valgrind and Purify. That would be good, but I'd put that > after getting the test suite to pass in Wine. > > This should be very doable using Autohotkey's scripting functionality > (pretty extensive - http://www.autohotkey.com/docs/Functions.htm, > http://www.autohotkey.com/docs/Variables.htm) and good old fashioned > shell scripting. I'm very familiar with bourne scripting, and > currently maintain winetricks while Dan's taking a Wine vacation. I'm > currently working on a build script to build Wine on several OS's, as > well as running and submitting the conformance tests > (http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh). [I > got tired of maintaining the script over several different > OS's/computers]. The upside is it would be easy to add on appinstall > to this daily script. I typically set it running before leaving home > for work/school. It spends an hour or so building wine and running the > tests in a few different configurations. Adding appinstall would allow > my computer to daily test several applications for installation, > running
Re: User forum thread: "how can we improve WINE?"
I'm not a favor of adding options as we try to autodetect everything. Users shouldn't touch them using winecfg in general. If you check lets say appdb you see a lot of tutorials recommending certain options while the authors have no idea what the options do and I have seen various tutorials where recommended registry options make things worse. GLSL is enabled by default and it should only be disabled in very rare cases, the same for various of the other options. Roderick On Sun, Apr 5, 2009 at 6:27 PM, Warren Dumortier wrote: > Here's what i done for now: > http://img227.imageshack.us/img227/8531/winecfgnew.png > > Before continuing, i would like to know if it is acceptable? > Sorry is in french, but "Options avancées" means "Advanced options". A > dialog will then pop up and let the user choose advanced options (video > memory size, rendering mode...). > > I do not find how to create a dialog with the callback, but i'll find! ;) > Also, someone knows how to launch wine in another language? (System var?). > Thanks. > > 2009/4/5 David Gerard > > http://forum.winehq.org/viewtopic.php?t=4403 >> >> Some highly impractical ideas, but certainly having the users throw >> ideas around should inspire wine-devel (and Codeweavers) :-) >> >> >> - d. >> >> >> > > > >
Re: [2/3] wined3d: Use OpenGL for default description and OpenGL vendor for driver.
Hi John, Unfortunately this patch isn't correct. If we report a different string we have to report the right strings like in case of the vendor the right driver name e.g. for Nvidia that is 'nv4_disp.dll'. In case of the board name we also need to report the right string (the name of the board we emulate). It is quite a bit more work to get this all right. Roderick
Re: [1/3] wined3d: Registry override for driver and description.
Hi John, Some suggestions (I think I also told Mirek at the time). Initialize the strings to NULL in wined3d_main.c where the wined3d_settings struct is initialized. Roderick On Tue, Apr 7, 2009 at 8:02 AM, John Whitlock wrote: > This patch is from Mirek Slugen . See > http://www.winehq.org/pipermail/wine-patches/2009-March/070766.html > > This patch set is for bug 15839 > > > > > > > > >
Re: wined3d: Use OpenGL vendor and renderer to pick driver and description.
Hi John, First of all this are basically two changes in one patch. Keep the vendor one separated from the device string. Second the opengl renderer string shouldn't be directly returned. In short d3d apps can query the pci id and opengl doesn't expose it (we aren't allowed to use /proc for card detection or so) and for that reason we 'estimate' what card is used based on the gpu capabilities (supported opengl extensions) and later on also the renderer string to refine the result a bit. For this reason the renderer string doesn't have to be the same as the pci id that we report. There are still some changes I have to make to the code and add a device string database. Roderick On Wed, Apr 8, 2009 at 8:40 AM, John Whitlock wrote: > Use the OpenGL renderer for the device description > Use the OpenGL vendor to pick an appropriate XP device driver > Fixes bug 15839 > > The registry overrides seemed to make devs uncomfortable, so I'm trying > submitting without them. They are easy enough to add on top of this > change, > if the need arises in the future. > > > > >
Re: Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
On Fri, Apr 17, 2009 at 9:34 PM, Joel Holdsworth wrote: > Hi, > > Apologies if you've already read this - I've been having trouble > getting the message to go through. > > I just had a play around with Tango-ifying Wine. The end result was > quite pleasing. There aren't too many icons to deal with, so it's not a > long job. > > All I've done here is swap out the shell32 icons, but I think the > experience is definitely improved (see > http://www.airwebreathe.org.uk/shell32.png ). Is it worth me submitting > the patch? > > http://www.airwebreathe.org.uk/0001-Replaced-shell32-icons-with-Tango-icons.patch.txt > > I tried doing the same for user32 MessageBox icons, but the end result > was less pleasing. These larger icons suffer from Wine's lack of alpha > channel support when it comes to icon rendering. Semitransparent areas > are rendered in black which looks yucky. > > I'm quite interested in pursuing this. I've been following wine for a > long time, but I've never worked on the code. How hard is it likely to > be for me, a wine newbie, to patch for icon alpha support? > > Joel > I wouldn't be against having these patches in Wine. Half a year or so ago I was also looking at this but at that time this icon set was still under the creative commons license. The developers were willing to relicense the icons under the LGPL (they also mentioned that eventually the icons would become public domain but at that time it looked to happen months away). I'm glad that they are public domain now. Roderick
Re: Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
On Fri, Apr 17, 2009 at 11:51 PM, Warren Dumortier wrote: > 2009/4/17 Roderick Colenbrander : >> On Fri, Apr 17, 2009 at 9:34 PM, Joel Holdsworth >> wrote: >>> Hi, >>> >>> Apologies if you've already read this - I've been having trouble >>> getting the message to go through. >>> >>> I just had a play around with Tango-ifying Wine. The end result was >>> quite pleasing. There aren't too many icons to deal with, so it's not a >>> long job. >>> >>> All I've done here is swap out the shell32 icons, but I think the >>> experience is definitely improved (see >>> http://www.airwebreathe.org.uk/shell32.png ). Is it worth me submitting >>> the patch? >>> >>> http://www.airwebreathe.org.uk/0001-Replaced-shell32-icons-with-Tango-icons.patch.txt >>> >>> I tried doing the same for user32 MessageBox icons, but the end result >>> was less pleasing. These larger icons suffer from Wine's lack of alpha >>> channel support when it comes to icon rendering. Semitransparent areas >>> are rendered in black which looks yucky. >>> >>> I'm quite interested in pursuing this. I've been following wine for a >>> long time, but I've never worked on the code. How hard is it likely to >>> be for me, a wine newbie, to patch for icon alpha support? >>> >>> Joel >>> >> >> I wouldn't be against having these patches in Wine. Half a year or so >> ago I was also looking at this but at that time this icon set was >> still under the creative commons license. The developers were willing >> to relicense the icons under the LGPL (they also mentioned that >> eventually the icons would become public domain but at that time it >> looked to happen months away). I'm glad that they are public domain >> now. >> >> Roderick >> >> >> > > Congrats, it looks very nice and i hope it'll be included in the near future. > Are there plans to support transparency? I hate to see a black > background with icons... > We do support transparency. Fancy alpha blending effects might not work but this should work I think. It might depend on the file type which was used and perhaps the setting of a color key in a palette (look for other wine apps which uses, some of them must be using transparency). Further apps like Office 2007 must also be using it and the app looks fine. Roderick
Re: Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
On Sat, Apr 18, 2009 at 8:50 PM, Joel Holdsworth wrote: >> Making the icon(s) configurable would be a bonus. > > Yes I'm not this will be possible in the first instance, because icons > have to be compiled into the DLL resources at compile time. In the long > run, it might be possible for some of our dialogs to use theme icons > instead, but we'll still need a no-theme fallback of some kind. Also, > the end result will likely be a mixed because even if our dialogs use > themes, app code will often still load icons by parsing DLL resources, > which can't be dynamic. Making the icon(s) configurable is not that hard but it should be done the Windows way. Windows XP has one set of stock icons compiled into the shell / commond dialog dlls or so but all (?) icons can be overridden by theme files (.msstyles). That's the way it should work on Wine as well. I would prefer to have the Tango icons be the stock icons. Roderick
Re: Article on wine development strategy
On Sun, Apr 19, 2009 at 12:31 AM, Remco wrote: > On Sat, Apr 18, 2009 at 11:36 PM, Henri Verbeet wrote: >> 2009/4/18 Ben Klein : >>> >>> Right now, there's one thing bugging me: bug 14939. If Dan (or others) >>> would like to implement a method of deferring S3TC texture >>> decompression to the appropriately licensed GPU, assuming there are no >>> legal issues with this, I'd be ecstatic. But I'm sure the D3D devs >>> have better things to do. :) >>> >> The sad thing is that S3TC decompression is just plain trivial. >> >> >> > > Maybe that could be solved in the same way as the patented Freetype > code: disable it by default, but let commercial Wine packagers (and > individual users obviously) have the choice of compiling it in. > Something like ./configure --paid-for-patents. > > Remco > > > Most drivers offer it these days and I believe also Mesa by default but you need to enable it using driconf or so. Roderick
Re: The DIB engine... does anyone know how to get it into Wine?
Hi, Massimo demonstrated the need for a DIB engine for Autocad but the way it is implemented is not fully correct. We already talked a bit about that on IRC. He is right that it should be implemented inside gdi32 and that it should be done in small steps (where possible). His idea is to add his 'DIB engine' and then fix the rest of the code and let everything converge in the end to the 'right' design. Part of the right design is that winex11.drv shouldn't work directly on DIBs anymore. Alexandre hasn't commented on the design except for saying that he didn't think that Massimo his current patches would converge to the 'right' design. Personally I think that the initial work for a DIB engine should focus on moving the DIB code away from winex11.drv. This is not a simple task and will likely require large patches. When all DIB code is abstracted away from winex11.drv adding a DIB engine will be a lot easier. Roderick
Re: The DIB engine... does anyone know how to get it into Wine?
On Tue, Apr 28, 2009 at 5:45 PM, Jesse Allen wrote: > On Tue, Apr 28, 2009 at 8:13 AM, Massimo Del Fedele wrote: >> 2) when winedib.drv is working good enough, wanted to "detach" it from >> winex11.drv, so make another "driver" comprising DDB parts of wineX11 >> and all optimizations needed. > > > This detaching thing is a little worrying. How will winex11 be called > after detaching? Through winedib or gdi again? The first would not > change functionality at all. The second is like the two driver > method. It sounds like we ought to stick to the two separate drivers > as a basis in development so we don't end up with something that can't > be unglued easily. > > > We shouldn't introduce a temporary driver. I can't speak for Alexandre but I think he would prefer to let winex11.drv not directly touch DIBs and move it to gdi32 and I guess in a second step also move the conversion code over to gdi32 and work with some capability flags which the display driver uses to tell whether it can render at a certain depth or not. Depending on that gdi32 should execute the current conversion code. In a next step the DIB engine can be added. Roderick
Re: The DIB engine... does anyone know how to get it into Wine?
On Tue, Apr 28, 2009 at 7:48 PM, Massimo Del Fedele wrote: > Roderick Colenbrander ha scritto: > >> >> We shouldn't introduce a temporary driver. > > Why ? > > I can't speak for Alexandre >> >> but I think he would prefer to let winex11.drv not directly touch DIBs >> and move it to gdi32 > > Me too > > and I guess in a second step also move the >> >> conversion code over to gdi32 > > agree too > > and work with some capability flags >> >> which the display driver uses to tell whether it can render at a >> certain depth or not. Depending on that gdi32 should execute the >> current conversion code. > > perfect > > In a next step the DIB engine can be added. >> > which next step ? then you'd already have the engine :-) > No then you don't have the engine yet. In my proposal you would first make winex11.drv not depend on DIBs (the conversion code would still be in winex11.drv), then you move the conversion code over (you would still perform 8bit drawing using X by converting it to 24bit but this conversion would be done inside gdi32). In the third step you would add software based drawing functions, so the actual DIB engine. Roderick
Re: The DIB engine... does anyone know how to get it into Wine?
On Wed, Apr 29, 2009 at 10:34 AM, Luke Benstead wrote: > It would be nice to see what Alexandre's opinion of the options > discussed in this thread is, as he's ultimately the one who will > decide. > > From an observer's point of view, I'd say that moving the current DIB > code out of wineX11 first before replacing it with Max's DIB code > sounds like the cleanest idea, because then if any bugs are introduced > it will be directly from the migration of the code, not the logic of > the DIB stuff itself. But obviously, from reading the discussion, it's > not as clean cut as just moving the code. > > Luke. > > > Yesterday there was a discussion on IRC about the DIB engine. To summarize it someone with a deep understanding of gdi32 should write the DIB engine and the only one right now who he think is capable of that is Huw. But he has no time to work on it right now (if there was funding for lets say half a year or so there might be time). Another solution might be (although I'm not sure if Huw is interested in that) is for him to mentor some people in working on the DIB engine. He would document how the DIB engine should be implemented and how it should interact with other parts of Wine. Roderick
Re: Wine + Mono + application = library not found?
On Fri, May 1, 2009 at 1:36 AM, Seth Shelnutt wrote: > Hello all, > > I'm trying to see if I can get a folding monitor, > http://code.google.com/p/hfm-net/ working in Wine. I've installed the latest > wine, 1.1.20, and the latest mono for windows 2.4. It seems however that > either mono or Wine, I think wine, is not seeing the library file from gtk. > However it is in my lib folder. Does anyone have any idea where wine is > looking for the lib to be at? This is on a Debian "testing" (Squeeze I > guess, but I keep my repos under the "testing" and no name, I use the wine > "sid" repo) install. > > > sheln...@k-server:~/Downloads/HFM Release 0.1.1.10$ wine HFM.exe > > Unhandled Exception: System.TypeInitializationException: An exception was > thrown by the type initializer for System.Windows.Forms.MimeIconEngine ---> > System.DllNotFoundException: libgdk-x11-2.0.so.0 > at (wrapper managed-to-native) > System.Windows.Forms.GnomeUtil:gdk_init_check (intptr,intptr) > at System.Windows.Forms.GnomeUtil.Init () [0x0] > at System.Windows.Forms.GnomeUtil.GetIcon (System.String icon, Int32 size) > [0x0] > at System.Windows.Forms.GnomeHandler.AddGnomeIcon (System.String > internal_mime_type, System.String name) [0x0] > at System.Windows.Forms.GnomeHandler.CreateUIIcons () [0x0] > at System.Windows.Forms.GnomeHandler.Start () [0x0] > at System.Windows.Forms.MimeIconEngine..cctor () [0x0] > --- End of inner exception stack trace --- > at System.Windows.Forms.WinFileSystem..ctor () [0x0] > at System.Windows.Forms.MWFVFS..ctor () [0x0] > at System.Windows.Forms.FileDialog..ctor () [0x0] > at System.Windows.Forms.OpenFileDialog..ctor () [0x0] > at (wrapper remoting-invoke-with-check) > System.Windows.Forms.OpenFileDialog:.ctor () > at HFM.Forms.frmMain.InitializeComponent () [0x0] > at HFM.Forms.frmMain..ctor () [0x0] > at (wrapper remoting-invoke-with-check) HFM.Forms.frmMain:.ctor () > at HFM.Program.Main (System.String[] argv) [0x0] > > sheln...@k-server:~/Downloads/HFM Release 0.1.1.10$ locate > libgdk-x11-2.0.so.0 > /home/shelnutt/opt/gps/lib/libgdk-x11-2.0.so.0 > /usr/lib/libgdk-x11-2.0.so.0 > /usr/lib/libgdk-x11-2.0.so.0.1600.1 > > > Thanks, > > Seth Shelnutt > > > > > When using win32 mono it should be using win32 gtk / gdk. I believe those dlls have about the same names as the linux ones. Make sure that win32 moni is really used. Second win32 mono only works for a limited number of apps for most things you need ms .net. I would suggest to try it using native mono first. Since the source is also around it would also be easy to locate mono bugs (hopefully the app doesn't make any win32 calls). Roderick
Re: Giving up for now
On Sat, May 2, 2009 at 6:55 PM, Joel Holdsworth wrote: > Hi All, > > I've hit a bit of a wall with alpha blended icons. CreateIcon is working > fine for icon creation, but ExtractIcon and LoadIconFromResource etc. > are all proving more of a problem. All of these use various GDI DIB > functions to coerce the icon bitmap to the correct colour depth and > size. The problem is that preserving the alpha channel through these DIB > functions seems to be impossible because they go via X11, so until the > dib engine is merged (after hell freezes over) I'm not sure I can go > much further. > > Joel > > > > > If you say X11 might be problematic note that more and more display drivers are offering visuals with alpha, so 32-bit ones instead of 24-bit. You could force the selection of such a visual in winex11.drv for testing. Roderick
Re: Giving up for now
On Sat, May 2, 2009 at 8:57 PM, Joel Holdsworth wrote: > On Sat, 2009-05-02 at 20:38 +0200, Roderick Colenbrander wrote: >> On Sat, May 2, 2009 at 6:55 PM, Joel Holdsworth >> wrote: >> > Hi All, >> > >> > I've hit a bit of a wall with alpha blended icons. CreateIcon is working >> > fine for icon creation, but ExtractIcon and LoadIconFromResource etc. >> > are all proving more of a problem. All of these use various GDI DIB >> > functions to coerce the icon bitmap to the correct colour depth and >> > size. The problem is that preserving the alpha channel through these DIB >> > functions seems to be impossible because they go via X11, so until the >> > dib engine is merged (after hell freezes over) I'm not sure I can go >> > much further. >> > >> > Joel >> > >> > >> > >> > >> > >> >> If you say X11 might be problematic note that more and more display >> drivers are offering visuals with alpha, so 32-bit ones instead of >> 24-bit. You could force the selection of such a visual in winex11.drv >> for testing. >> >> Roderick > > Is that right? I simply assumed it would screw it up. If the problem can > be solved with fixes to user32 or gdi32, then I can probably find the > solution. If it involves work on winex11, then I'm not really the right > guy for the job. > > > Why again did you need this specific alphablend method? The icon can't be converted to use some basic color keying for transparency or so?
Re: Giving up for now
On Sun, May 3, 2009 at 2:44 AM, Ben Klein wrote: > 2009/5/3 Joel Holdsworth : >> On Sat, 2009-05-02 at 22:56 +0200, Roderick Colenbrander wrote: >>> Why again did you need this specific alphablend method? The icon can't >>> be converted to use some basic color keying for transparency or so? >> >> The reason is that the outlines will look aliased, and there will be no >> drop-shadows - without alpha the Tango icons won't look better than the >> current set. Also, I figured that icon rendering should be fixed for the >> sake of wine as a whole - which I think it should. It seems like a good >> little task for a wine beginner, and indeed I've made a lot of progress >> - I'm just a bit stuck. >> >> The culprit is a transfer through StretchDIBits in user32 which strips >> the alpha channel. I can't see a way round it - using StretchBlt doesn't >> help, and neither does GdiTransparentBlt. >> >> Another insentive: I suspect fixing this would also fix bug #201 which >> is now over 8 years old! > > What format are your Tango icons in? Are you converting them to .ICO > files as you go, or leaving them in PNG/some other known alpha channel > supporting format? > > > We do support some alpha support using XRender, can't you use this too? I think that's the general method for using alpha at the moment on X. Roderick
Re: Giving up for now
On Sat, May 2, 2009 at 11:18 PM, Joel Holdsworth wrote: > On Sat, 2009-05-02 at 22:56 +0200, Roderick Colenbrander wrote: >> On Sat, May 2, 2009 at 8:57 PM, Joel Holdsworth >> wrote: >> > On Sat, 2009-05-02 at 20:38 +0200, Roderick Colenbrander wrote: >> >> On Sat, May 2, 2009 at 6:55 PM, Joel Holdsworth >> >> wrote: >> >> > Hi All, >> >> > >> >> > I've hit a bit of a wall with alpha blended icons. CreateIcon is working >> >> > fine for icon creation, but ExtractIcon and LoadIconFromResource etc. >> >> > are all proving more of a problem. All of these use various GDI DIB >> >> > functions to coerce the icon bitmap to the correct colour depth and >> >> > size. The problem is that preserving the alpha channel through these DIB >> >> > functions seems to be impossible because they go via X11, so until the >> >> > dib engine is merged (after hell freezes over) I'm not sure I can go >> >> > much further. >> >> > >> >> > Joel >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> >> If you say X11 might be problematic note that more and more display >> >> drivers are offering visuals with alpha, so 32-bit ones instead of >> >> 24-bit. You could force the selection of such a visual in winex11.drv >> >> for testing. >> >> >> >> Roderick >> > >> > Is that right? I simply assumed it would screw it up. If the problem can >> > be solved with fixes to user32 or gdi32, then I can probably find the >> > solution. If it involves work on winex11, then I'm not really the right >> > guy for the job. >> > >> > >> > >> >> Why again did you need this specific alphablend method? The icon can't >> be converted to use some basic color keying for transparency or so? > > The reason is that the outlines will look aliased, and there will be no > drop-shadows - without alpha the Tango icons won't look better than the > current set. Also, I figured that icon rendering should be fixed for the > sake of wine as a whole - which I think it should. It seems like a good > little task for a wine beginner, and indeed I've made a lot of progress > - I'm just a bit stuck. > > The culprit is a transfer through StretchDIBits in user32 which strips > the alpha channel. I can't see a way round it - using StretchBlt doesn't > help, and neither does GdiTransparentBlt. > > Another insentive: I suspect fixing this would also fix bug #201 which > is now over 8 years old! > > > I just looked a little more into it. As you mentioned StretchDIBits in user32 removes the alpha channel. According to this post at MSDN (http://msdn.microsoft.com/en-us/library/dd145023(VS.85).aspx) the function got extended in Vista to include PNG support because PNG is used for most icons in Vista. It might be useful to check that out. The page mentions it was meant for printers but most likely they also use this for icon rendering. I think it can be used in cooperation with XRender (there are various xrender examples for dealing with alpha). Roderick
Re: Giving up for now
On Sun, May 3, 2009 at 6:28 PM, Roderick Colenbrander wrote: > On Sat, May 2, 2009 at 11:18 PM, Joel Holdsworth > wrote: >> On Sat, 2009-05-02 at 22:56 +0200, Roderick Colenbrander wrote: >>> On Sat, May 2, 2009 at 8:57 PM, Joel Holdsworth >>> wrote: >>> > On Sat, 2009-05-02 at 20:38 +0200, Roderick Colenbrander wrote: >>> >> On Sat, May 2, 2009 at 6:55 PM, Joel Holdsworth >>> >> wrote: >>> >> > Hi All, >>> >> > >>> >> > I've hit a bit of a wall with alpha blended icons. CreateIcon is >>> >> > working >>> >> > fine for icon creation, but ExtractIcon and LoadIconFromResource etc. >>> >> > are all proving more of a problem. All of these use various GDI DIB >>> >> > functions to coerce the icon bitmap to the correct colour depth and >>> >> > size. The problem is that preserving the alpha channel through these >>> >> > DIB >>> >> > functions seems to be impossible because they go via X11, so until the >>> >> > dib engine is merged (after hell freezes over) I'm not sure I can go >>> >> > much further. >>> >> > >>> >> > Joel >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> >>> >> If you say X11 might be problematic note that more and more display >>> >> drivers are offering visuals with alpha, so 32-bit ones instead of >>> >> 24-bit. You could force the selection of such a visual in winex11.drv >>> >> for testing. >>> >> >>> >> Roderick >>> > >>> > Is that right? I simply assumed it would screw it up. If the problem can >>> > be solved with fixes to user32 or gdi32, then I can probably find the >>> > solution. If it involves work on winex11, then I'm not really the right >>> > guy for the job. >>> > >>> > >>> > >>> >>> Why again did you need this specific alphablend method? The icon can't >>> be converted to use some basic color keying for transparency or so? >> >> The reason is that the outlines will look aliased, and there will be no >> drop-shadows - without alpha the Tango icons won't look better than the >> current set. Also, I figured that icon rendering should be fixed for the >> sake of wine as a whole - which I think it should. It seems like a good >> little task for a wine beginner, and indeed I've made a lot of progress >> - I'm just a bit stuck. >> >> The culprit is a transfer through StretchDIBits in user32 which strips >> the alpha channel. I can't see a way round it - using StretchBlt doesn't >> help, and neither does GdiTransparentBlt. >> >> Another insentive: I suspect fixing this would also fix bug #201 which >> is now over 8 years old! >> >> >> > > I just looked a little more into it. As you mentioned StretchDIBits in > user32 removes the alpha channel. According to this post at MSDN > (http://msdn.microsoft.com/en-us/library/dd145023(VS.85).aspx) the > function got extended in Vista to include PNG support because PNG is > used for most icons in Vista. It might be useful to check that out. > The page mentions it was meant for printers but most likely they also > use this for icon rendering. I think it can be used in cooperation > with XRender (there are various xrender examples for dealing with > alpha). > > Roderick > Have you also tried to use the GDI AlphaBlend function? This is the one which should be used I think and we back it by XRender .. Roderick
Re: [4/5] WineD3D: Work around a bad crash in fglrx
On Wed, May 6, 2009 at 3:52 PM, Ben Klein wrote: > 2009/5/6 Francois Gouget : >> I have a feeling that Wine is the only 'application' that really tests >> the Unix OpenGL drivers, by virtue of being the only application to run >> the really complex vertex and pixel shaders that are found only in >> Windows games. Maybe I am wrong, but if I am right it means that the >> driver developpers would do well to take Wine seriously, and probably >> use it as a matter of course, if they want to produce quality code. > > I've been in contact with developers at Linux Game Publishing for a > while (and am now in fact a Junior Developer for them :D), and from > what I gather, regular OpenGL apps on Linux implement hacks to work > around bugs/shortcomings in ATI/AMD drivers. Wine is a special case > where it's been decided that hacks for specific drivers is a bad idea > except in extreme cases, and that there should be generalised > solutions for everything (which is, by the way, the whole point of > OpenGL :) ). > > As a result, the question of hacks in Wine comes up quite often > (ATI/AMD card owners want their games to work!) and it's (almost?) > always rejected. With any luck, we'll see some sensible, functional, > open-source radeonhd drivers coming soonish, so the issue of hacks at > the application level can be minimised. > > > Actually ATI/AMD is quite interested in Wine. I have been in contact with them for joining their developer program and helping them fix issues. I didn't have time to fill out all the info yet. I could get them look at it then. Roderick
Re: DIB Engine : Almost 100% working
On Sun, May 10, 2009 at 5:07 PM, Massimo Del Fedele wrote: > James McKenzie ha scritto: > >> >> Good work. Have you started to think about how to get this into Wine >> where AJ will approve? >> >> James McKenzie >> > > Ah, I'm not very optimistic that it'll ever enter on wine tree :-) > Nor have I time to adopt the "trial and error" way up to it's > approved. > The easiest way I see by now is to add it to wine drivers as an > "alternative" driver in parallel to X11 one. > That could be done in less then 5 minutes and with no regressions :-) > > As I said before, to include it as replacement of actual driver would > mean to make an half rewrite of both gdi32 and winex11. > BTW, my engine has still space for a 3 optimizations that could speed > it up even a lot more : > > 1) Font caching - shouldn't be too difficult > 2) Access DDB directly for blit - not too difficult, and could bring > a speed gain of 100% on mixed DDB/DIB operations > 3) xxxBlt are not very optimized I would expect another 50-100% speed > gain on blitting with few codelines more. > > Ciao > > Max > > > > Unfortunately getting this code into Wine is not really possible (Alexandre would like to see Huw finishing the design and all the work but no time has been assigned to him for this) BUT I think work on this DIB engine even if it won't make it in Wine isn't wasted. This DIB engine even if not correct shows us what apps can benefit and by how much from the dib engine (before we only had guesses). If running photoshop on Wine is significantly faster using the DIB engine (it might be useful to do tests for that, there are ways to benchmark photoshop) Codeweavers might work on it. Roderick
Re: DIB Engine : Almost 100% working
On Sun, May 10, 2009 at 8:03 PM, Massimo Del Fedele wrote: > Roderick Colenbrander ha scritto: > >> >> Unfortunately getting this code into Wine is not really possible >> (Alexandre would like to see Huw finishing the design and all the work >> but no time has been assigned to him for this) BUT I think work on >> this DIB engine even if it won't make it in Wine isn't wasted. This >> DIB engine even if not correct shows us what apps can benefit and by >> how much from the dib engine (before we only had guesses). If running >> photoshop on Wine is significantly faster using the DIB engine (it >> might be useful to do tests for that, there are ways to benchmark >> photoshop) Codeweavers might work on it. >> >> Roderick >> > > I'm (and not just me, afaik) still very, very but really very curious to > know *which* > would be the "correct" design > BTW, I made my design because I needed it, and I'm happy if it'll be useful > for some > other people, quite probable stuff having seen the amount of words wasted > about the > subject from year 2002. > Anyways, if instead of having it as an "alternative" solution inside wine > tree > (which would make stuffs easier for people needing it, for example cad > users) we want > to let it hanging on bug 421's page hoping to have the "right" solution in a > bit less > than another 7 years, ok :-) > > Max > Interpreting Alexandre his words Huw his design was the right way to continue (according to Jeremy he had worked on this for 4-5 months) but even for Huw it would take a similar amount of time to finish it. They didn't know well if continuing with the work was worth it for the apps they had to get working and during a discussion at Wineconf they also weren't certain for which apps it would help and more important by how much (e.g. time is also fixing a lot issues as we are getting faster CPUs all the time). With your patches (even if they aren't clean and won't 100% correctly) we see how much a DIB engine (even unoptimized) can already help. Basically a lot of users should test it using different programs. We need benchmark results e.g. photoshop benchmarks and others. If the DIB engine appears to do wonders for lots of apps (e.g. photoshop, office ...) then some company might sponsor Codeweavers to work on this. Roderick
Re: DIB Engine : Almost 100% working
> Office won't benefit at all, I'm afraid. Photoshop, maybe. > If sponsorship will be based on those apps, I guess we'll wait > forever :-) > > Max > > Photoshop is quite important for Wine (remember for 1.0 getting photoshop working was one of our main goals). There is still no serious Photoshop replacement for most companies which use Linux. Note that there are also others for obtaining the sponsoring and there is one about which I have been taking a lot but clear goals would need to be formulated for it and that would be a Wine fund raiser. We would raise money to get sponsorship for areas like this which else stay unfixed for years but money can also be used for Wineconf, buying hardware for patchwatcher, buying software for use on test machines, . Roderick
Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)
On Wed, May 13, 2009 at 9:15 PM, Daniel Santos wrote: > Steven, sorry for the slow response, I got tied up in some other stuff. But > now back to fun. =) And thanks for your response! > > The application is Lord of the Rings Online. They don't use normal version > numbers, so this bug actually started with "Book 14". In Book 14, the > problem would manifest as a crash. The current version is "Mines of Moria" > and now I will get either a crash (segfault) or a hang, but the result is a > hang 6 times out of 7 (or so). > > However, I've run into a more serious problem that I have yet to resolve, > and I'll post it in a new thread. This problem is related to what is > considered acceptable behavior and what is not and what is considered > "reverse engineering". I mentioned that I had the program in winedbg and > was examining the threads when I was informed that I was reverse engineering > and any patch I came up with doing this would not be accepted. I found this > rather confounding to say the least!! > > Anyway, the hang or crash may occur immediately (under 50 milliseconds) > after switching to the LOTRO window or it may only occur after I start > moving around. It will always occur within 10 or 20 seconds of having > switched to the window, usually within 4 or 5. So if I start playing after > swithcing to the window and I make it 30 seconds, I'm confident that it wont > crash that time. > > If you want to install this app, I have recently written up a pretty install > script to do some enviroment setup and posted it on the appdb here: > > http://appdb.winehq.org/objectManager.php?sClass=version&iId=14566 > > You can even create a trial account for testing. Unfortunately, it's a 7GB > download. One of my shortcomings in troubleshooting this is that I've never > done directx or direct3d, so I don't understand all of the implications of > these window events from that perspective (or direct input). I'm going to > play more with this today as well. > > Daniel > > --- On Sat, 5/9/09, Steven Edwards wrote: > > From: Steven Edwards > Subject: Re: Dynamically adding debug channels > (__wine_dbg_set_channel_flags) > To: daniel.san...@pobox.com > Date: Saturday, May 9, 2009, 3:16 PM > > On Sat, May 9, 2009 at 3:44 PM, Daniel Santos > wrote: >> Additionally, as far as I can tell, there is no mechanism to change it for >> all channels. This is actually what I need to do since I do not know >> where >> the specific problem is that I'm troubleshooting and I don't even know for >> certain that it isn't a bug in the 3rd party software. What I do know is >> that it does not occur on windows and I suspect it's a case of the 3rd >> party >> app entering "undefined results" territory and that on windows, this >> result >> is consistent and does not cause a problem. >> >> When I attempt to run the app with WINEDEBUG=+all, it appears to enter >> some >> type of deadlock state before I can even get to the point where the bug >> normally happens. This hang is probably due to poor timing management in >> the app and may indeed be another expression of the same core problem. >> >> Speaking of the wine task manager, where is that? (or which executable is >> it)? > > Its taskmgr in the source tree as wine/programs/taskmgr. > > You might try doing something like +relay,+seh,+tid for your channels > to isolate the problem down. I might be able to help you isolate the > problem but I doubt I can fix it for you even if we are able to find > it but that's at least a start. What software are you trying to get to > work? Can you describe the exact nature of the problem? Sorry I must > confess I've not been following the thread very closely. > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > > > > > You might also want to check the debug patch in here: http://wiki.winehq.org/InterestingPatches It allows you to enable debugging when you need it by ahttp://wiki.winehq.org/InterestingPatches keypress. E.g. WINEDEBUG=+some_channel (except for +all) WINEDELAY=enable wine app.exe Roderick
Re: Wine policy question: What is considered "reverse engineering"/what is acceptable?
On Wed, May 13, 2009 at 10:02 PM, Jerome Leclanche wrote: > I thought reverse engineering was only relevant to MS code? As in > reverse engineering of windows dlls and so on; another application > would be irrelevant. > > That's what I understood from it anyway. First of all I'm not a lawyer ;) Correct you should avoid looking at windows code. Regarding Microsoft code we only allow black box reverse engineering, so you feed the dll with some input and check the outcome without looking what happens inside (so without checking debug logs of MS dlls). Looking at Microsoft debug traces should be avoided as it is similar to disassembling a program IF it is for the purpose of figuring out what the black box is doing. Looking at debug traces of programs is fine and as I said it is similar to looking at the output of a disassembler. Sure it can happen that you are looking at calls made by Microsoft code since some Microsoft dlls are being used but you are not aware of that and you are not trying to reverse engineer the particular Microsoft dll, so that would also be fine (though it is a gray area). Roderick
Re: wined3d: Updated NVIDIA mobile GT GPUs
Hi,
In order to not let the card database become too long I group a lot of
boards together. That should be doable for the 96xx / 97xx / 98xx
boards you added below and then I use the lowest number of video
memory (512MB). This should be fine for apps as they only need a
reasonable estimate of the card. Further we can't use all video memory
anyway. In the near future I plan to add a better mechanism which will
detect the actual card using nv-control.
Roderick
2009/5/13 Łukasz Wojniłowicz :
> ---
> dlls/wined3d/directx.c | 42 ++
> dlls/wined3d/wined3d_gl.h | 7 +++
> 2 files changed, 49 insertions(+), 0 deletions(-)
>
> diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
> index f5d4d3e..989ab7f 100644
> --- a/dlls/wined3d/directx.c
> +++ b/dlls/wined3d/directx.c
> @@ -1112,11 +1112,46 @@ static BOOL IWineD3DImpl_FillGLCaps(WineD3D_GL_Info
> *gl_info) {
> gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800GT;
> vidmem = 512;
> }
> + /* Geforce9800M GTX - highend */
> + else if(strstr(gl_info->gl_renderer, "9800M GTX")) {
> + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800MGTX;
> + vidmem = 1024; /* The 9800M GTX has 1024MB */
> + }
> + /* Geforce9800M GTS - highend */
> + else if(strstr(gl_info->gl_renderer, "9800M GTS")) {
> + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800MGTS;
> + vidmem = 1024; /* The 9800M GTS has 1024MB */
> + }
> + /* Geforce9800M GT - highend */
> + else if(strstr(gl_info->gl_renderer, "9800M GT")) {
> + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9800MGT;
> + vidmem = 512; /* The 9800M GT has 512MB */
> + }
> /* Geforce9 - midend */
> else if(strstr(gl_info->gl_renderer, "9600")) {
> gl_info->gl_card = CARD_NVIDIA_GEFORCE_9600GT;
> vidmem = 384; /* The 9600GSO has 384MB, the 9600GT has
> 512-1024MB */
> }
> + /* Geforce9700M GTS - midend */
> + else if(strstr(gl_info->gl_renderer, "9700M GTS")) {
> + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9700MGTS;
> + vidmem = 512; /* The 9700M GTS has 512MB */
> + }
> + /* Geforce9700M GT - midend */
> + else if(strstr(gl_info->gl_renderer, "9700M GT")) {
> + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9700MGT;
> + vidmem = 512; /* The 9700M GT has 512MB */
> + }
> + /* Geforce9650M GT - midend */
> + else if(strstr(gl_info->gl_renderer, "9650M GT")) {
> + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9650MGT;
> + vidmem = 512; /* The 9650M GT has 512-1024MB */
> + }
> + /* Geforce9600M GT - midend */
> + else if(strstr(gl_info->gl_renderer, "9600M GT")) {
> + gl_info->gl_card = CARD_NVIDIA_GEFORCE_9600MGT;
> + vidmem = 512; /* The 9600M GT has 512-1024MB */
> + }
> /* Geforce9 - midend low / Geforce 200 - low*/
> else if(strstr(gl_info->gl_renderer, "9500") ||
> strstr(gl_info->gl_renderer, "GT 120") ||
> @@ -3991,7 +4026,14 @@ static const struct driver_version_information
> driver_version_table[] = {
> {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9400GT, "NVIDIA GeForce 9400
> GT", 7, 15, 11, 8044 },
> {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9500GT, "NVIDIA GeForce 9500
> GT", 7, 15, 11, 8044 },
> {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9600GT, "NVIDIA GeForce 9600
> GT", 7, 15, 11, 8044 },
> + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9600MGT, "NVIDIA GeForce
> 9600M GT", 7, 15, 11, 8044 },
> + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9650MGT, "NVIDIA GeForce
> 9650M GT", 7, 15, 11, 8044 },
> + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700MGT, "NVIDIA GeForce
> 9700M GT", 7, 15, 11, 8044 },
> + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700MGTS, "NVIDIA GeForce
> 9700M GTS", 7, 15, 11, 8044 },
> {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800GT, "NVIDIA GeForce 9800
> GT", 7, 15, 11, 8044 },
> + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800MGT, "NVIDIA GeForce
> 9800M GT", 7, 15, 11, 8044 },
> + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800MGTS, "NVIDIA GeForce
> 9800M GTS", 7, 15, 11, 8044 },
> + {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800MGTX, "NVIDIA GeForce
> 9800M GTX", 7, 15, 11, 8044 },
> {VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GTX260,
Re: Fix ATI HD4800 being reported as ATI 9500
I would recommend to add a new if-statement for hd48xx cards (detect the 4830, 4850, 4870, 4890) and set those cards to the pci id of the 4830 and set the video memory to let say 512MB for now. Roderick On Thu, May 14, 2009 at 7:08 AM, Robert Key wrote: > Changelog: > * Add HD4800 series to be detected in graphics card table. > This makes it so that the ati dx9 quirks aren't applied. > > Also added the pci id of HD4850 to wined3d_gl.h > > > >
Re: (try2)Fix ATI HD4800 being reported as ATI 9500
The patch itself is correct but the comment regarding the X2 4800 is
incorrect. Those cards indeed have 2GB of video memory (and the PR
people mention that to you) but the boards contain two GPUs and both
need a have a copy of textures and other resources (though the GPUs
can communicate using a high speed bus). Effectively the amount of
video memory is still 1GB.
Roderick
On Fri, May 15, 2009 at 2:29 AM, Robert Key wrote:
> Changelog:
> * Added support for the ATI HD 4800 series (should be all of them).
> Used a HD4830 device id for HD4800 cards in wined3d_gl.h.
>
>
>
>
From 8034f52551451a8db2440ac4908ff325bae7b04d Mon Sep 17 00:00:00 2001
From: Robert Key
Date: Thu, 14 May 2009 19:14:02 -0400
Subject: Fix ATI HD4800 being reported as ATI 9500
---
dlls/wined3d/directx.c| 17 ++---
dlls/wined3d/wined3d_gl.h |1 +
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 8e3c807..ad192c0 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -1271,10 +1271,20 @@ static BOOL IWineD3DImpl_FillGLCaps(WineD3D_GL_Info
*gl_info) {
break;
case VENDOR_ATI:
if(WINE_D3D9_CAPABLE(gl_info)) {
+/* Radeon R7xx HD4800 - highend */
+if (strstr(gl_info->gl_renderer, "HD 4800") ||
+strstr(gl_info->gl_renderer, "HD 4830") ||
+strstr(gl_info->gl_renderer, "HD 4850") ||
+strstr(gl_info->gl_renderer, "HD 4870") ||
+strstr(gl_info->gl_renderer, "HD 4890"))
+{
+gl_info->gl_card = CARD_ATI_RADEON_HD4800;
+vidmem = 512; /* HD4800 cards use 512-1024MB, up to 2048MB
for X2 version */
+}
/* Radeon R6xx HD2900/HD3800 - highend */
-if (strstr(gl_info->gl_renderer, "HD 2900") ||
-strstr(gl_info->gl_renderer, "HD 3870") ||
-strstr(gl_info->gl_renderer, "HD 3850"))
+else if (strstr(gl_info->gl_renderer, "HD 2900") ||
+ strstr(gl_info->gl_renderer, "HD 3870") ||
+ strstr(gl_info->gl_renderer, "HD 3850"))
{
gl_info->gl_card = CARD_ATI_RADEON_HD2900;
vidmem = 512; /* HD2900/HD3800 uses 256-1024MB */
@@ -4007,6 +4017,7 @@ static const struct driver_version_information
driver_version_table[] = {
{VENDOR_ATI,CARD_ATI_RADEON_HD2300, "ATI Mobility Radeon
HD 2300", 6, 14, 10, 6764},
{VENDOR_ATI,CARD_ATI_RADEON_HD2600, "ATI Mobility Radeon
HD 2600", 6, 14, 10, 6764},
{VENDOR_ATI,CARD_ATI_RADEON_HD2900, "ATI Radeon HD 2900
XT",6, 14, 10, 6764},
+{VENDOR_ATI,CARD_ATI_RADEON_HD4800, "ATI Radeon HD 4800
Series",6, 14, 10, 6764},
/* TODO: Add information about legacy ATI hardware, Intel and other cards
*/
};
diff --git a/dlls/wined3d/wined3d_gl.h b/dlls/wined3d/wined3d_gl.h
index 1a9c925..615d914 100644
--- a/dlls/wined3d/wined3d_gl.h
+++ b/dlls/wined3d/wined3d_gl.h
@@ -3302,6 +3302,7 @@ typedef enum _GL_Cards {
CARD_ATI_RADEON_HD2600 = 0x9581,
CARD_ATI_RADEON_HD2900 = 0x9400,
CARD_ATI_RADEON_HD3200 = 0x9620,
+ CARD_ATI_RADEON_HD4800 = 0x944c,
CARD_NVIDIA_RIVA_128= 0x0018,
CARD_NVIDIA_RIVA_TNT= 0x0020,
--
1.6.3
Re: WINE Intel
> I do not know but I suspect that WINE's various Direct3D code utilizes > OpenGL nVidia Extension or higher level OpenGL ARB Extension rather that > lower one. > > That's why while INTEL OpenGL driver does support DirectX7, DirectX8 level > 3D wine does not able to run many games on INTEL Linux graphics driver. > While those many games run on nVidia Linux driver. > > I hope WINE will someday have better INTEL OpenGL support. Wine is doing nothing wrong we use generic OpenGL extensions all through Wine. The issue is that the intel drivers don't offer all opengl extensions we need for decent d3d9 support, if the gl support isn't there we can't support it. Second the quality of the intel drivers still isn't very good, sure recent versions support GLSL, FBOs and other things but the drivers are first of all buggy and second very slow for those purposes. Further ATI works reasonably well with Wine as well these days (it used to be crap). Intel needs to fix their drivers. Roderick
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg wrote: > On 18.05.2009, at 06:56, Dmitry Timoshkov wrote: > >> "James McKenzie" wrote: >> >>> Austin: >>> Contact Mike Kronenberg or Zach Drayer and see what they currently >>> have. >> >> IMHO since they haven't even bothered so far to change the license from >> GPL to LGPL to match Wine, and clarify what exactly is so much different >> in their builds so that they insist on different naming (Darwine vs. >> Wine), >> they shouldn't be even considered as partners to the Wine project. >> >> If we could have our own Wine builds for Intel Macs, that would finally >> help to avoid this confusion Darwine adds, and remove it from our Wiki >> altogether (since it's apparently where the users coming to them from). >> >> -- >> Dmitry. >> >> > > > > Hi, > > (I hope I did not double-post, but somehow my mail from yesterday was eaten > by filter-gnomes) > > It's not about being willing to, but plain lack of time. > I follow this list closely and work on solutions as time permits. > After half a year, it's been four weeks now that I am able again to build > and test on a regular base again. > > There are other components on OS X that need some love, like the > winehelper.app into which I'm looking atm. > > License and renaming is definitely on the list. > I thought to revamp the package, once the winehelper is replaced, to not > double do the work. > > As already mentioned, I build the dependencies and store them inside the > apple .app package, which allows for drag'n'drop installation and removal. > > Having the dependencies as frameworks would be even better, as there is a > lot of trouble with PATHS, especially if multiple environments are on the > system, like fink and macports. > > But if the name-change is the most pressing issue, I will gladly do that > with this weekends release. > > Mike Kronenberg > > > Could you also upload some docs / scripts on how to build 'DarWine' from scratch? I have an app which I need to run on osx which I like to package as well. I have time to help fixing osx issues (duplicating the effort is not worth it). Roderick
Re: DXTn textures in D3DX9
On Fri, May 22, 2009 at 2:08 PM, Ben Klein wrote: > 2009/5/22 Tony Wasserka : >> Hi everyone, >> I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, >> but I've got a problem. The function >> most convert a loaded surface's data to a user specified surface format >> (I did not yet find a way to do it elsehow, >> UpdateTexture and StretchRect are to limited for that task, suggestions >> welcome if I missed anything). >> Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 >> surface to DXT1 (or to save a surface to a >> DXTn compressed DDS file), I'm not sure wether I can implement that >> behavior; on #winehackers I was told that >> the (de)compression part is coverered by S3's patents, but the Gimp DDS >> plugin and this >> (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS >> solutions for it anways. >> So... Can anybody tell me for sure wether I may implement this code or not? >> >> >> Best regards, Tony > > If it counts for anything, I'd like to see a converter going the other > way (bug 14939). > > > Note that there is some basic s3tc support in mesa these days which you can activate using driconf. I forgot what its limitations are. I believe it is enough for rendering. Roderick
Re: DXTn textures in D3DX9
On Fri, May 22, 2009 at 6:11 PM, Stefan Dösinger wrote: > You may find this helpful: > http://code.google.com/p/nvidia-texture-tools/ > > Wrt the legalese check the last question here: > http://code.google.com/p/nvidia-texture-tools/wiki/FAQ > > Using a proven library for s3tc handling is a good idea even without the legal > troubles. s3tc decompression isn't rocket science, but s3tc compression is > harder than it seems. Nvidia, ATI and Microsoft have fought a long battle for > the best s3tc compression algorithm. For a long time s3tc was considered bad > because there was no really good compressor - so I recommend not to reinvent > the wheel here. > So what they are saying is that Nvidia has a license on the s3tc patent for use in those tools but if we would rip their code out we wouldn't be covered unless (but that is gray area) we put all their image code in wine (which would be impossible since it is C++). Perhaps if we want to be safe we could ask s3 for a license for use in Wine? Roderick
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
On Wed, May 20, 2009 at 4:04 PM, Austin English wrote: > On Wed, May 20, 2009 at 4:46 AM, Roderick Colenbrander > wrote: >> On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg >> wrote: >>> On 18.05.2009, at 06:56, Dmitry Timoshkov wrote: >>> >>>> "James McKenzie" wrote: >>>> >>>>> Austin: >>>>> Contact Mike Kronenberg or Zach Drayer and see what they currently >>>>> have. >>>> >>>> IMHO since they haven't even bothered so far to change the license from >>>> GPL to LGPL to match Wine, and clarify what exactly is so much different >>>> in their builds so that they insist on different naming (Darwine vs. >>>> Wine), >>>> they shouldn't be even considered as partners to the Wine project. >>>> >>>> If we could have our own Wine builds for Intel Macs, that would finally >>>> help to avoid this confusion Darwine adds, and remove it from our Wiki >>>> altogether (since it's apparently where the users coming to them from). >>>> >>>> -- >>>> Dmitry. >>>> >>>> >>> >>> >>> >>> Hi, >>> >>> (I hope I did not double-post, but somehow my mail from yesterday was eaten >>> by filter-gnomes) >>> >>> It's not about being willing to, but plain lack of time. >>> I follow this list closely and work on solutions as time permits. >>> After half a year, it's been four weeks now that I am able again to build >>> and test on a regular base again. >>> >>> There are other components on OS X that need some love, like the >>> winehelper.app into which I'm looking atm. >>> >>> License and renaming is definitely on the list. >>> I thought to revamp the package, once the winehelper is replaced, to not >>> double do the work. >>> >>> As already mentioned, I build the dependencies and store them inside the >>> apple .app package, which allows for drag'n'drop installation and removal. >>> >>> Having the dependencies as frameworks would be even better, as there is a >>> lot of trouble with PATHS, especially if multiple environments are on the >>> system, like fink and macports. >>> >>> But if the name-change is the most pressing issue, I will gladly do that >>> with this weekends release. >>> >>> Mike Kronenberg >>> >>> >>> >> >> Could you also upload some docs / scripts on how to build 'DarWine' >> from scratch? I have an app which I need to run on osx which I like to >> package as well. I have time to help fixing osx issues (duplicating >> the effort is not worth it). >> >> Roderick >> >> >> > > It's available under 'build env': > http://www.kronenberg.org/darwine/buildenv-1.1.5.zip > > -- > -Austin > Thanks, I used this to compile wine 1.1.21 for testing purposes this week. I had to update the scripts a bit (e.g. use newere versions of some libraries and tools because the old ones are offline). I can post a patch against the old script. Further don't ship the opengl hack anymore for new wine packages as you are aware it isn't needed for xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. This might prevent some opengl bug reports which I have to close on bugzilla as well ;) Roderick
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
On Sun, May 24, 2009 at 2:49 AM, James McKenzie wrote: > Roderick Colenbrander wrote: >> >> Thanks, I used this to compile wine 1.1.21 for testing purposes this >> week. I had to update the scripts a bit (e.g. use newere versions of >> some libraries and tools because the old ones are offline). I can post >> a patch against the old script. Further don't ship the opengl hack >> anymore for new wine packages as you are aware it isn't needed for >> xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. >> This might prevent some opengl bug reports which I have to close on >> bugzilla as well ;) >> >> > Can you provide the updates to the scripts? Since I am using Leopard, > the opengl fix is not needed anymore, but it may have to stay until > XQuartz 2.3.3 is backported for Tiger. > > James McKenzie > > Hi James, This is the script I used. It mainly consists of some new servers and updated version numbers because the original versions weren't available anymore (sure they are useally in some 'old' directory). Further I'm not building with the opengl patch. Roderick build_darwine_x86.sh.gz Description: GNU Zip compressed data
Re: PowerPC MacOSX work...
He might be wanting to use winelib and that should work. People used it in the past. Roderick On Mon, May 25, 2009 at 1:44 PM, Stefan Dösinger wrote: > Am Montag, 25. Mai 2009 00:49:55 schrieb Michael G Hughes: >> I have managed to get Wine compiling on a PowerMac G4, MacOSX 10.3.9, a >> while back... >> >> What I know so far... It does not work... Who'd a thunk it? >> >> Just trying to run winecfg gives me: >> >> fixme:seh:RTLCaptureContext not implimented on PowerPC >> fixme:seh:call_stack_handlers not implemented on PowerPC >> wine: Unhandled alignment at address 0x44010788 (thread 000d), starting >> debugger... >> err:process:__wine_kernel_init boot event wait timed out > The main trouble is that Windows apps are x86, so in order to run anything but > builtin notepad you'll need a CPU emulator. In that case, just compile wine > as x86 binary and run it in the emulator as well. > > > >
Re: failure to recognize "early 2009" Mac Mini nVidia 9400 OpenGL version string
On Mon, May 25, 2009 at 12:18 PM, wrote: > Hi, > > as of wine-1.1.21, wine does not recognize the "early 2009" Mac Mini > OpenGL version string from nVidia: > err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: "2.0 > NVIDIA-1.5.44" > > The string probably originates from XQuartz' X11.2.3.3.2. The wine > source code expects a space after NVIDIA. On Linux, the numbers are > much higher, e.g. "2.1.2 NVIDIA 173.14.09" or "2.1.0 NVIDIA 97.55" -- 2 > samples from Google. > > Before I submit a patch to have wine recognize either space or "-" as > separator, I'd like to query the list whether it actually makes sense > to return major = 1, minor = 5, i.e. Apple numbers to a MS-Windows program? > > Or should I not care about the useage and just parse the string (i.e. submit > patch)? > > Thanks, > Jörg Höhle > > > The version string parsing isn't that important. The version number we return isn't based on this anymore. We use a lookup table in case of nvidia. Roderick
Re: DIB Engine : passing all tests
On Wed, May 27, 2009 at 10:26 AM, Vit Hrachovy wrote: > Massimo Del Fedele wrote: >> >> Btw, sorry all but I begins to be tired of telling same stuffs again and >> again. I made a proposal for something that *could* help the migration to >> final design, a *working* proposal, not just a prototype, and I believe on >> it. >> If that's not what most devels think, for me is ok. >> The engine will be available as a patch for whom needs/likes it, point. > > Hi Max, > would it be possible to craft a wikipage on Wine Wiki, that would encompass > * official DIB implementation requirements > * high level description of Huw's solution > * description of Your solution incl. proposed integration plan > > It would ease the orientation, prevent repeating the same stuff again and > again and it could also serve as a solid base for further discussion about > DIB integration requirements. > > Regards > Hark > > > I have asked Alexandre about it but it wasn't really an option. Even for Huw writing a full dib engine (if he resumed his current code) would take five months or so full time. Filling in the 'easy' bits (which Alexandre considers most of the things done so far) is not that much work (the easy bits are the software drawing functions). Roderick
Re: Announcing WineConf 2009
On Fri, May 29, 2009 at 11:26 PM, Steven Edwards wrote: > On Fri, May 29, 2009 at 5:17 PM, Austin English > wrote: >> What is the status of the Wine Party Fund this year, to help with the >> cost of transportation/lodging? I remember quite a bit of it was used >> up last year... > > This also provides a good time for us to publicly seek donations. > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > > > Yep and we might also want donations for some other things e.g. DIB engine and other things (it shouldn't bite with CW). Further remember as of Wineconf 2008 it is not Wine Party Fund but Wine Development Fund but it was discussed on saturday morning ;) Roderick
Re: Implications for Wine from the Ubuntu Developer Summit
On Tue, Jun 2, 2009 at 10:08 AM, Francois Gouget wrote: > On Tue, 2 Jun 2009, Ben Klein wrote: > >> 2009/6/2 Scott Ritchie : > [...] >> > First, I talked with a Pulseaudio expert about what we can do to make >> > things work better. He said that if we want good compatibility we will >> > need our ALSA stack to use the Pulseaudio safe subset: >> > http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a >> > metabug tracking this here: >> > http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset >> > can cause most problems with stuttering or even complete dropoff. >> >> As far as I know, this is not possible for Wine (without massive >> latency issues caused by overbuffering in Wine itself) due to the fact >> that Wine has to make DirectSound apps happy. > > Which of the DONTs are causing problems for Wine? (And why?) > It would be nice to identify them to be able to send argumented feedback > to the PulseAudio developers. > > > -- > Francois Gouget http://fgouget.free.fr/ > tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY > > > I have quickly checked the code and this are I think some of the 'easy' DONTs we violate: - we use snd_config_xxx(), this is replaceable by snd_device_name_hint() - we use snd_card_xxx(), this can be replaced by snd_device_name_hint() - we hard code device strings (e.g. plughw0) - we use snd_pcm_avail_update and snd_pcm_delay (there might be some more but those are less trivial to check) The most critical are the following: - Do not assume that all devices support MMAP style buffer access. - Do not assume that the hardware pointer inside the (possibly mmaped) playback buffer is the actual position of the sample in the DAC. There might be an extra latency involved. - Do not try to recover with your own code from ALSA error conditions such as buffer under-runs. Use snd_pcm_recover() instead. - Do not touch buffering/period metrics unless you have specific latency needs. Develop defensively, handling correctly the case when the backend cannot fulfill your buffering metrics requests. Be aware that the buffering metrics of the playback buffer only indirectly influence the overall latency in many cases. i.e. setting the buffer size to a fixed value might actually result in practical latencies that are much higher. Especially the first one direct sound is all about direct card access and hence mmap .. Roderick
Re: [08/10] wined3d: Use FBOs for offscreen rendering by default.
Sure the test fails on your system but I think it is a driver bug or some change in Vista as a lot of other machines using different windows versions and drivers work fine. Have you tried updating to a newer driver version? Perhaps it also matters if you have desktop effects (dwm?) turned on or off. It might make a difference. I might be able to try the test on my ati laptop later on. Roderick On Fri, Jun 5, 2009 at 5:20 PM, paulo lesgaz wrote: > The point is that the tests are uncorrect: > Here is I obtain in a real windows Vista box: > > http://test.winehq.org/data/8d0cb61bc7760c4ab254c3a5bb751bded3a6f4ed/vista_june5/d3d9:visual.html > > visual.c:183: Driver string: "nvd3dum.dll" > visual.c:184: Description string: "NVIDIA GeForce Go 7600" > visual.c:185: Device name string: "\\.\DISPLAY1" > visual.c:186: Driver version 7.15.11.7692 > visual.c:8868: Tests skipped: D3DFMT_R16F textures not supported > visual.c:7572: Tests skipped: Card has unconditional pow2 support, skipping > conditional NP2 tests > visual.c:9690: Test failed: Input 0xff00: Got color 0x8700 for pixel > 2/1, expected 0x004bff1c, format D3DFMT_UYVY > visual.c:9690: Test failed: Input 0xff00: Got color 0x004bff1c for pixel > 2/1, expected 0x8700, format D3DFMT_UYVY > visual.c:9690: Test failed: Input 0x: Got color 0x00b3 for pixel > 2/1, expected 0x00ffd01c, format D3DFMT_UYVY > visual.c:9690: Test failed: Input 0xffff: Got color 0x30e1 for pixel > 2/1, expected 0x004b, format D3DFMT_UYVY > visual.c:9690: Test failed: Input 0x0000: Got color 0x00ffd01c for pixel > 2/1, expected 0x00b3, format D3DFMT_UYVY > visual.c:9690: Test failed: Input 0x: Got color 0x004b for pixel > 2/1, expected 0x30e1, format D3DFMT_UYVY > visual.c:9690: Test failed: Input 0x00ff: Got color 0x00b300e1 for pixel > 2/1, expected 0x00ff79ff, format D3DFMT_UYVY > visual.c:9686: Test failed: Input 0x: Got color 0x for pixel > 1/1, expected 0x8700, format D3DFMT_YUY2 > visual.c:9690: Test failed: Input 0x: Got color 0x for pixel > 2/1, expected 0x8700, format D3DFMT_YUY2 > visual.c:9686: Test failed: Input 0xff00: Got color 0x for pixel > 1/1, expected 0x00b3, format D3DFMT_YUY2 > visual.c:9690: Test failed: Input 0xff00: Got color 0x for pixel > 2/1, expected 0x00b3, format D3DFMT_YUY2 > visual.c:9686: Test failed: Input 0x00ff: Got color 0x for pixel > 1/1, expected 0x8700, format D3DFMT_YUY2 > visual.c:9690: Test failed: Input 0x00ff: Got color 0x for pixel > 2/1, expected 0x004bff1c, format D3DFMT_YUY2 > visual.c:9686: Test failed: Input 0xff00: Got color 0x for pixel > 1/1, expected 0x30e1, format D3DFMT_YUY2 > visual.c:9690: Test failed: Input 0xff00: Got color 0x for pixel > 2/1, expected 0x30e1, format D3DFMT_YUY2 > visual.c:9686: Test failed: Input 0x00ff: Got color 0x for pixel > 1/1, expected 0x004bff1c, format D3DFMT_YUY2 > visual.c:9690: Test failed: Input 0x00ff: Got color 0x for pixel > 2/1, expected 0x8700, format D3DFMT_YUY2 > visual.c:9686: Test failed: Input 0x: Got color 0x for pixel > 1/1, expected 0x00b3, format D3DFMT_YUY2 > visual.c:9690: Test failed: Input 0x: Got color 0x for pixel > 2/1, expected 0x00ffd01c, format D3DFMT_YUY2 > > > So, something is wrong in wined3d implementation. > > David > > --- En date de : Ven 5.6.09, Alexandre Julliard a > écrit : > > De: Alexandre Julliard > Objet: Re: [08/10] wined3d: Use FBOs for offscreen rendering by default. > À: "Henri Verbeet" > Cc: wine-devel@winehq.org > Date: Vendredi 5 Juin 2009, 14h38 > > Henri Verbeet writes: > >> Alexandre Julliard wrote: >>> It doesn't work here: >>> >>> ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p >>> d3d9_test.exe.so visual.c && touch visual.ok >>> visual.c:7572: Tests skipped: Card has unconditional pow2 support, >>> skipping conditional NP2 tests >>> visual.c:9686: Test failed: Input 0x: Got color 0x for >>> pixel 1/1, expected 0x8700, format D3DFMT_UYVY >>> visual.c:9690: Test failed: Input 0x: Got color 0x for >>> pixel 2/1, expected 0x8700, format D3DFMT_UYVY >>> visual.c:9686: Test failed: Input 0xff00: Got color 0x for >>> pixel 1/1, expected 0x8700, format D3DFMT_UYVY >>> visual.c:9690: Test failed: Input 0xff00: Got color 0x for >>> pixel 2/1, expected 0x004bff1c, format D3DFMT_UYVY >>> visual.c:9686: Test failed: Input 0x00ff: Got color 0x for >>> pixel 1/1, expected 0x00b3, format D3DFMT_UYVY >>> visual.c:9690: Test failed: Input 0x00ff: Got color 0x00ff for >>> pixel 2/1, expected 0x00b3, format D3DFMT_UYVY >>> visual.c:9686: Test failed: Input 0xff00: Got color 0x for >>> pixel 1/1, expected 0x004bff1c, format D3DFMT_UYVY >>> [...many more...] >>> make: *** [visual.ok] E
Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
As of Wine 1.1.23 wined3d made FBOs the default offscreen rendering method. If you are using a non-nvidia card (those in general have buggier drivers) that could explain all the failures. Setting OffscreenRenderingMethod to backbuffer restores the old behavior. Roderick On Fri, Jun 5, 2009 at 10:04 PM, chris ahrendt wrote: > > Something majorly changed and is wrong with the latest GIT tree. > Between the comits yesterday and today 90% of the tests get exceptions > or fail. > All of the d3d tests get a process exception and fail with a dialog box. > > > Ideas? > > Chris > > > > > > > > > >
Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
Check the useful registry keys page at wiki.winehq.org (it is Direct3D/OffscreenRenderingMethod) Roderick On Fri, Jun 5, 2009 at 10:41 PM, chris ahrendt wrote: > > On 06/05/2009 04:32 PM, Roderick Colenbrander wrote: >> As of Wine 1.1.23 wined3d made FBOs the default offscreen rendering >> method. If you are using a non-nvidia card (those in general have >> buggier drivers) that could explain all the failures. Setting >> OffscreenRenderingMethod to backbuffer restores the old behavior. >> >> Roderick >> >> On Fri, Jun 5, 2009 at 10:04 PM, chris ahrendt wrote: >> >>> Something majorly changed and is wrong with the latest GIT tree. >>> Between the comits yesterday and today 90% of the tests get exceptions >>> or fail. >>> All of the d3d tests get a process exception and fail with a dialog box. >>> >>> >>> Ideas? >>> >>> Chris >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> > where do I set that? > > > > > > > >
Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
Sure that is possible but it is something we should avoid. In the longterm having this enabled by default is better as it would get ATI and others to fix their drivers. If we would restore the old value (the old method is also not great for modern games and causes a lot of issues, FBOs are needed for proper d3d9 support) it would take longer for ATI to fix the remaining driver bugs. Roderick On Sat, Jun 6, 2009 at 12:32 PM, Jerome Leclanche wrote: > Would it be a good/stupid idea to check for fglrx during wineboot, and > set OSRM to a different value than fbo? > > 2009/6/6 Henri Verbeet : >> 2009/6/6 Kovács András : >>> wine: Unhandled page fault on read access to 0x0018 at address >>> 0x7c71fb02 (thread 0009), starting debugger... >>> Unhandled exception: page fault on read access to 0x0018 in 32-bit >>> code (0x7c71fb02). >>> Register dump: >>> CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b >>> EIP:7c71fb02 ESP:0033e2a4 EBP:7d838810 EFLAGS:00210246( R- -- I Z- >>> -P- ) >>> EAX:0001 EBX:0001 ECX:7d49d6a0 EDX: >>> ESI: EDI:7d715258 >>> Stack dump: >>> 0x0033e2a4: 7c70ca7f 7d847520 >>> 0x0033e2b4: 7d612f90 7d612f90 >>> 0x0033e2c4: 7d82e7b8 7d612f90 >>> 0x0033e2d4: 7d82e7b8 7d848010 7d82e7b8 >>> 0x0033e2e4: 7d7e2628 >>> 0x0033e2f4: 7d612f90 7d6a7e88 >>> Backtrace: >>> =>0 0x7c71fb02 in fglrx_dri.so (+0x713b02) (0x7d838810) >>> 0x7c71fb02: movl 0x18(%edx),%eax >>> >> >> That's probably the same issue as >> http://bugs.winehq.org/show_bug.cgi?id=18794 >> I'm afraid the conclusion there is simply going to be that fglrx's FBO >> support sucks. We could probably justify not checking depth stencil >> formats, but it's perfecly reasonable to try >> GL_COMPRESSED_RED_GREEN_RGTC2_EXT. The driver should of course crash >> on neither of those. >> >> I suppose we could blacklist EXT_framebuffer_object on fglrx, but that >> will likely just hurt more in the long term. >> >> >> > > > > -- > J. Leclanche / Adys > > >
Re: Одговор: Latest Git build 7aeffc442cc1 fo r Wine 1.1.23
We don't use GL extensions when they aren't around. Perhaps there is a small check which fails for FBOs. Backbuffer should work fine but a lot more changes have been made in .23 and those are which cause the zbuffer error. Roderick On Sat, Jun 6, 2009 at 4:58 PM, Milan Kostić wrote: > Deafulting to fbo is good, but it should be more good to leave also > prior working support for backbuffer on older cards who not have > EXT_framebuffer_object. Reverting to > "OffscreenRenderingMode"="backbuffer" is not working as expected for > me on r200 Mesa/DRI drivers, for example in Max Payne 2 which now > can't be even starting with backbuffer, Rayman 2 and Dungen Siege 2 > also. In 1.1.22>= they worked. > > > >
Re: opengl32: fix a compiler warning on Mac OS X
Actually I need to fix opengl32 properly. For some reason opengl32 is opengl 1.2 while it should be 1.1. Then GL_GLEXT_PROTOTYPES is not needed at all for compiling opengl32. Roderick On Wed, Jun 10, 2009 at 12:18 AM, Austin English wrote: > GL_GLEXT_PROTOTYPES is defined in GL/gl.h on Mac. Other #ifdef methods > end up breaking compilations elsewhere. > > -- > -Austin > > > >
Re: opengl32: fix a compiler warning on Mac OS X
Normally it is very easy to do (2 minutes of work) but the opengl.spec files of which the opengl32 code is generated have been changed a lot in opengl 3.1 (the old versions are offline). I need to rewrite the scripts and some code, so it is quite a bit of work. Roderick On Wed, Jun 10, 2009 at 10:17 AM, Austin English wrote: > On Wed, Jun 10, 2009 at 1:30 AM, Roderick > Colenbrander wrote: >> Actually I need to fix opengl32 properly. For some reason opengl32 is >> opengl 1.2 while it should be 1.1. Then GL_GLEXT_PROTOTYPES is not >> needed at all for compiling opengl32. > > Even better. Any idea how close that is on your todo list? > > -- > -Austin > > >
Re: opengl32: get rid of glext.h
On Thu, Jun 11, 2009 at 11:09 AM, Detlef Riekenberg wrote: > On Mi, 2009-06-10 at 21:56 +0200, Roderick Colenbrander wrote: > >> -#ifdef HAVE_GL_GLEXT_H >> -# include >> -#endif > > The same code is used in winex11.drv/opengl.c > Can this also be removed? > > When that's the case, then "GL/glext.h" can be removed from > AC_CHECK_HEADERS in configure.ac > > -- > > By by ... Detlef > > At a quick glance we don't seem to need it there. We only use a small number of GL calls which are all 1.1 and for extensions we use in there we already define our own function pointers anyway as the functions need to be loaded dynamically. I think we can get rid of it. Roderick
Re: Request for comments on patch
On Sun, Jun 14, 2009 at 10:45 PM, Erich Hoover wrote: > On Sun, Jun 14, 2009 at 2:26 PM, Mike > Kaplinskiy wrote: >> I don't know about stubbing drivers, but I remember that >> autodetection/registry wasn't accepted on the fallout 3 patch. I think >> AJ would prefer something like >> http://source.winehq.org/git/wine.git/?a=commit;h=f2e2e3e49947490368900ef06a92e1df1bc52820 >> but for driver dll strings. >> >> But take my comments with a grain of salt. I just watch the list most >> of the time and don't really understand the graphics stuff too well. >> >> Mike. >> > > It's been some time since I've seen those patches pass through (it's > also possible I missed the patch your talking about), but if I > remember correctly there were a couple different reasons they were > rejected. It sounded like the issue was that they reported a driver > that doesn't exist and/or that the registry key manually specified a > driver. My suggestion is that there's a "try to report the > manufacturer driver" type registry key and that it, when activated, > reports a real driver. This real driver then funnels the requests > back to winex11.drv (with room to add additional non-funneled requests > later, such as requesting the card's video RAM). > > Erich Hoover > ehoo...@mines.edu > > > The only thing I didn't add yet was driver identification as I didn't have time for it yet but I just plan to add that to a table in wined3d (the reported driver name depends also on the windows version). In the end adding such info to the display driver would make sense though but I don't think it brings us much at this point. Roderick
Re: Request for comments on patch
On Sun, Jun 14, 2009 at 10:52 PM, Roderick Colenbrander wrote: > On Sun, Jun 14, 2009 at 10:45 PM, Erich Hoover wrote: >> On Sun, Jun 14, 2009 at 2:26 PM, Mike >> Kaplinskiy wrote: >>> I don't know about stubbing drivers, but I remember that >>> autodetection/registry wasn't accepted on the fallout 3 patch. I think >>> AJ would prefer something like >>> http://source.winehq.org/git/wine.git/?a=commit;h=f2e2e3e49947490368900ef06a92e1df1bc52820 >>> but for driver dll strings. >>> >>> But take my comments with a grain of salt. I just watch the list most >>> of the time and don't really understand the graphics stuff too well. >>> >>> Mike. >>> >> >> It's been some time since I've seen those patches pass through (it's >> also possible I missed the patch your talking about), but if I >> remember correctly there were a couple different reasons they were >> rejected. It sounded like the issue was that they reported a driver >> that doesn't exist and/or that the registry key manually specified a >> driver. My suggestion is that there's a "try to report the >> manufacturer driver" type registry key and that it, when activated, >> reports a real driver. This real driver then funnels the requests >> back to winex11.drv (with room to add additional non-funneled requests >> later, such as requesting the card's video RAM). >> >> Erich Hoover >> ehoo...@mines.edu >> >> >> > > The only thing I didn't add yet was driver identification as I didn't > have time for it yet but I just plan to add that to a table in wined3d > (the reported driver name depends also on the windows version). In the > end adding such info to the display driver would make sense though but > I don't think it brings us much at this point. > > Roderick > I forgot to mention the reason why previous registry key options didn't enter Wine. The reason was that we had to have a good default mechanism (e.g. returning nv4_disp.dll for nvidia by default on 2k/xp) before adding override keys. The registry keys can be added when this mechanism is around. Roderick
Re: Request for comments on patch
On Sun, Jun 14, 2009 at 11:44 PM, Erich Hoover wrote: > On Sun, Jun 14, 2009 at 3:33 PM, Mike > Kaplinskiy wrote: >> ... >> >> I didn't mean symlinking to the /lib/wine directory, but rather, >> symlinking to prefix/windows/system32/ from /lib/wine/ . But since >> that isn't done either, just copying to a new filename also seems >> reasonable. Sadly if we do have a registry-based mechanism for >> selection, this might not be possible to do on wineboot (unless there >> is a way to check on every startup?) >> > > A copy would probably be fine, I'm not familiar with how this is > handled though so I'd have to look into it. > >> Stubbing dlls for every possible driver (even if there are only 2-3) >> seems too much, so a general driver should be available. I'm just not >> too sure on how to convert between that driver's filename and the >> specific filename that our table gives. >> > > I'm not sure exactly what you're referring to here. > >>> >>> "struct driver_version_information" contains the vendor as an integer >>> already, a separate structure could easily contain columns for >>> matching the Vendor and OS in order to return a driver filename. That >>> way you wouldn't end up with a giant "struct >>> driver_version_information". >> >> Yes that is what I meant to say, sorry if I didn't make my intentions >> clear. I was just thinking about the size of the driver_version_table >> array - 5-10 os's, 30-40 drivers already there...that's 150-400 >> entries, and adding something like WINVER_ANY (as a last resort when >> matching) would make it a smaller. >> > > There are only a couple different manufacturers, you don't need an > entry for each specific driver. There would only be > OSVersion*Manufacturer combinations. > > Erich Hoover > ehoo...@mines.edu > Also note as I documented in the card detection code that we don't care about the exact card but about the functionality we can offer (that's also what games care about). In case of d3d10 even if you have a radeon hd4800 (so d3d10 capable) and there is no geometry shader support in the drivers then it doesn't make sense to report this card (games might be so stupid to detect the hd4800 and based on that load the d3d9 or d3d10 backend). The gpu features also depend on the use of direct or indirect rendering. We always need to get the card at run time. Roderick
Re: Fate of PulseAudio in WINE
Hi Arthur, I would recommend you to also read this thread: http://www.winehq.org/pipermail/wine-devel/2009-June/076102.html As mentioned before we would like not to have a pulse audio driver if it isn't needed at all. Some suggestions have been made to use some pulseaudio rules of thumb in our winealsa code to improve the situation. This is likely not doable for some of the stuff like mmap which is needed for direct card access (directsound requires that) but fixes in that area could already improve winealsa <-> pulse interaction a lot. Remaining issues might be solvable in cooperation with the pulse developers. I think a lot of issues can already be fixed without requiring a new driver. Regards, Roderick Colenbrander On Tue, Jun 16, 2009 at 12:33 PM, Arthur Taylor wrote: > Recent activity in http://bugs.winehq.org/show_bug.cgi?id=10495 has > caused some issues. This is also a response to > http://www.winehq.org/pipermail/wine-devel/2009-April/074666.html > > First the background. WinePulse has been an attempt to write a winmm > backend for pulseaudio for wine. Currently the primary audio system > used by wine is through winmm.dll which sends messages to a backend > which basically represents the MS waveOut and waveIn APIs. > > WaveOut works through wavehdrs, a single-linked list structure which > contains a data field pointing at a buffer. Applications feed wavehdrs > via waveOutWrite and receive a message when they have finished being > played. wavehdrs can be formed into loops using flags. This is all > simple enough except for how variable it is. Applications usually > allocate a set size of wavehdrs and then use them circularly. > Applications usually use when a wavehdr is returned for timing > purposes rather than waveOutGetPosition. The number of wavehdrs and > their sizes is entirely up to the application. > > There are two common problems with audio drivers implementing this > system. The first is drivers which return a wavehdr as soon as it is > written to output (waveesd.dr for example) as it will cause timing > issues for applications when large batches of wavehdrs are returned at > once. The second problem is when a windows application makes a smaller > buffer of wavehdrs than the backend provides. In this case wavehdrs > are not returned because they have not been played, and no more data > can be written to fill the buffer because all the wavehdrs are waiting > to be returned from the playback that is stalled. This can happen with > alsa on top of plugins. If the buffered wavehdrs and playback buffer > are very close in size sometimes the audio stutters by, oscillating to > and from underrun and playback. > > Winepulse attempts to overcome these problems. It returns wavehdrs > accurately and avoids stalls by modifying the pulseaudio server buffer > size. In tests it works consistently. > > Most of the people I've had contact with have been positive toward > development of such a backend. That said, the response from wine > developers has been overwhelmingly negative. I can understand the > desire for only clean and maintainable code to be considered for > submissions. However, often it appears that the rejection is wholly > philosophical rather than logical. Continual reports of problems are > always contributed to silly users who are not using ALSA on top of > direct hardware. I do not dislike either ALSA nor winealsa.drv, but I > do reject this skepticism toward a world of Linux audio beyond SB-16 > style "direct hardware." > > The arguments that PulseAudio adds latency or is not suitable for > professional audio are not relevant to the issue of whether or not a > pulseaudio backend for wine should be added. The _addition_ of said > backend _enables_ audio in wine for those who _choose_ to use > pulseaudio. I can't imagine stopping pulseaudio just so I can listen > to music through foobar2000, as that would stop all my voice chats, > notification sounds, and other native audio, etc. For those whom > pulseaudio is not appropriate, the other backends would still exist > and pulseaudio can either be disabled temporarily via pasuspender, not > started or not installed. > > That said, latency in pulseaudio is managed and through the winepulse > patch exposed to the windows application. The daemon is usually run > with realtime priority and will use data buffers if the requesting > application locks temporarily, allowing less worry with recording. > > The method of audio playback and capture through waveOut and waveIn > are quite broken. Even if winealsa uses the "safe ALSA api subset" it > means that the poor and varied behaviours are translated to poor and > varied alsa calls (DSound HEL is an exception here.) The winepulse > patch attemp
Wine MIME handling
Hi, For the past few days I have been looking at MIME handling in Wine. A program I'm using uses CreateProcess to launch a pdf file and I would like to use the default native pdf viewer. Initially I wrote a simple script which calls xdg-open to launch the file offered by Wine. (xdg-open "`wine winepath -u "$1"`") The script works properly and it could be used for all sorts of file formats. It would be useful to have a 'winemime' mechanism for this in Wine (either a script, program or shell32 code). The issue could be solved in different ways. For instance there is already some XDG MIME code in shell32 which could be extended, a winebrowser-like winelib program could be written or we could use a script. Personally I would favor either of the last two solutions. The main downside of a script is that as far as I know I need to set the whole linux path (e.g. /usr/local/bin/winemime) in the registry and this could be avoided if the tool was a winelib program as it would be in the wine path by default. Second I would like not to depend on the xds-open script on linux but have this code merged inside winemime. A winelib based winemime would be very similar to winebrowser, so if we would go the winelib way might it make sense to extend winebrowser for this? I hope to get some feedback and suggestions on how to proceed before I start writing code. Thanks, Roderick Colenbrander
Re: How to force use of DirectX8 instead of DirectX9?
Likely there is just a configuration option in the game to select a different renderer. I believe the game has a opengl and d3d one. I have no idea what it means with d3d8 or d3d9. Sometimes games really use d3d8.dll instead of d3d9.dll but other times the games only use the 'd3d8 subset' of d3d9. Roderick On Tue, Jun 16, 2009 at 2:58 PM, Tom Wickline wrote: > In the registry :) > > Tom > > On Tue, Jun 16, 2009 at 6:35 AM, wrote: >> Hi, >> >> What is the recommended way not to use Wine's DirectX9 and fall back to >> DirectX8 instead? >> Some applications list DirectX 8.1 as their minimal graphics requirement, >> yet they come with DirectX9 on the CD and presumably use Wine's DirectX9. >> >> The author of the screenshot at >> http://www.adventure-treff.de/images/bild.php?bild=/features/ankh_grafikvergleich.jpg >> shows how graphics differ a lot for Ankh, depending on whether DirectX 8 or 9 >> is being used in MS-Windows. >> >> Perhaps forcing use of DirectX8 can help make some applications run? (Or >> help locate bugs) >> >> Thanks for your help, >> Jörg Höhle >> >> >> > > >
Re: Wine MIME handling
On Tue, Jun 16, 2009 at 7:23 PM, Brian Vincent wrote: > On Tue, Jun 16, 2009 at 5:26 AM, Roderick Colenbrander > wrote: >> >> For the past few days I have been looking at MIME handling in Wine. A >> program I'm using uses CreateProcess to launch a pdf file and I would >> like to use the default native pdf viewer. > > I think it would be useful to have two different checkbox option in winecfg > that ask: > > 1. "Always open files with native application if available?" > 2. "Ask me whether to open with file formats with a native application or > my Windows application?" > > (Optionally, saying "No" to #1 could imply #2. However, I think it might be > clearer to explicitly have it as an option.) > > For instance, in the case of PDF's, say you have a great native viewer > available and you want to use that viewer to view all PDF's. However, you > also have Adobe Acrobat installed under Wine (hypothetical, I have no idea > if that app works) and that's what you like to use for editing. You > probably want to use the viewer most of the time, but every once in a while > you'd probably like to be prompted to use Acrobat so you can edit the PDF. > > What would also be slick is to have the Windows Explorer "Open With..." > functionality provide a list of native apps as well. > > -Brian > The XDG spec which is what I would use defines how to find a program which can handle the format (a default handler). The user can override the handler but I'm not sure whether the spec also defines a way to query which programs can handle the format. This would be needed for the 'Open With...' stuff if it is possible then it should be done from within shell32. What I'm interested in at this point is a method to add native apps to handle opening of files (using HKEY_CLASSES_ROOT like on Windows). I propose to do this using a winemime program/script. The tool would use 'xdg-open' to get the default handler (when the user selects a different handler from the default handler on the system, his preference is selected). I'm not sure whether the tool needs to be a script, program or whether it should be part of shell32. If it is a script should xdg-open be forked or ported to C for a winelib version of winemime? Roderick
Re: [PATCH 2/2] wined3d: improved ATI Radeon HD 4xxx detection
On Wed, Jun 17, 2009 at 10:16 AM, Yann Droneaud wrote: > Le mercredi 17 juin 2009 à 04:01 +0200, Stefan Dösinger a écrit : >> The patches seem ok to me, although I'd probably merge them into one >> patch(there's no point in adding unused defines) > > In my first version, I tried to match each model because inside each > sub family, some are faster than the other. > > According to Internet sources > like http://en.wikipedia.org/wiki/Radeon_R700 and > http://en.wikipedia.org/wiki/Comparison_of_ATI_graphics_processing_units#Radeon_R700_.28HD_4xxx.29_series > > HD4350 and HD4550 have quite the same horse power, based on RV710. > HD4650 and HD4670 have quite the same horse power, based on RV730. > > HD4700 is reported by AMD to be based on RV770, while HD4770 is based on > RV740. See > http://developer.amd.com/drivers/pc_vendor_id/Pages/default.aspx > > HD48xx uses RV770 but not HD4890 which uses RV790. > > According to benchmark, HD4770 is "faster" than HD4830. > > Upcoming (rumored) HD4790 based on RV790 is said to be faster than > HD4850 or even HD4870. > http://www.techpowerup.com/index.php?96859 > > Note that the patch doesn't take account of HD48xx X2 card model based > on R700 which are reported to be way faster than all the others. > > So the point was to match card and sort them by "power" instead of > family. > But it seems not doable since OpenGL renderer string like "ATI Radeon HD > 4800 Series" is not useful to distinguish between HD4890 and HD4850 :( > > Regards. > > -- > Yann Droneaud > > The patch is good and you are correctly merging boards. Stefan his point was that next time you should merge both patches into one file as adding unused defines (the first patch) has zero effect without the second patch, so they should be one patch. Roderick
Re: [3/6] d3dx9: Implement ID3DXFont_GetDesc
Hi Tony, +WideCharToMultiByte(CP_ACP, 0, This->desc.FaceName, -1, desc->FaceName, sizeof(desc->FaceName) / sizeof(CHAR), NULL, NULL); sizeof(desc->FaceName) / sizeof(CHAR) won't give you the length of the string (remember that sizeof is evaluated at compile time, so the value is a constant) Regards, Roderick
Re: [6/6] d3dx9: Add tests for basic ID3DXFont functions
Hi Tony, +hr = D3DXCreateFontA(device, 12, 0, FW_DONTCARE, 0, FALSE, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH, "Arial", &font); A bunch of font tests all use Arial. On Windows this font is always around, what happens on Wine when this font isn't around? Perhaps the function fails on fonts which aren't around, so this could potentially result in a lot of test failures on Wine. Not sure what should be done if this is the case though (perhaps check at run time if the font is around or perhaps use a font which is always around as a fallback). Regards, Roderick
Re: Is there any way to debug driver?
Well as Henri mentioned a bug report has been posted to the (un)official amd bugzilla for it with details on the crash. It was just related to the enabling of FBOs by default and some FBO related tests. Regarding debugging I would try to use winedbg and if it isn't sufficient winedbg offers a gdb proxy method which could be useful as well. Further it might also be useful to use the Wine ddraw/d3d8/d3d9 test suites. The tests consist of both conformance tests to windows behavior and they also test tricky d3d functionality which popular games require. Various tests fail at this point on the AMD drivers (on windows some also don't always work) and before (on catalyst <=9.3 or it was <=9.2) some tests even caused a system crash. It would be useful if the tests could be run as they illustrate a lot of tricky d3d9 situations. Regards, Roderick Colenbrander On Wed, Jun 17, 2009 at 5:38 PM, Damjan Jovanovic wrote: > On Wed, Jun 17, 2009 at 11:01 AM, Guan, Xiao-Feng > wrote: >> Hello, >> >> As we can see that, from version 1.1.23, all application fails to start on >> AMD card. We are going to investigate why it happens. If it is necessary, >> Would you please let us know a little more about the changes of this >> version? > > If it worked for you before and doesn't work in 1.1.23, it sounds like > you should do a regression test to find the patch that broke it: > http://wiki.winehq.org/RegressionTesting > >> >> >> Thanks & regards. >> >> >> >> Guan Xiaofeng >> >> OpenGL Software Engineer, >> >> Graphic Product Group >> >> Shanghai R&D Center, AMD Cop. >> >> xiao-feng.g...@amd.com >> >> Tel 86 021 61601838 ext 25746 >> >> >> > > Regards and good luck > Damjan Jovanovic > > >
Re: [3/6] d3dx9: Implement ID3DXFont_GetDesc
Wasn't aware that it was a buffer with a fixed size. Then you are correct and it should work. Roderick On Wed, Jun 17, 2009 at 9:04 PM, Tony Wasserka wrote: > Roderick Colenbrander schrieb: >> Hi Tony, >> >> + WideCharToMultiByte(CP_ACP, 0, This->desc.FaceName, -1, >> desc->FaceName, sizeof(desc->FaceName) / sizeof(CHAR), NULL, NULL); >> >> sizeof(desc->FaceName) / sizeof(CHAR) won't give you the length of the >> string (remember that sizeof is evaluated at compile time, so the >> value is a constant) >> >> Regards, >> Roderick >> >> >> > FaceName is an array of (W)CHARs with a fixed size of LF_FACESIZE, so > that would be okay, wouldn't it? > The code which is in the official tree right now does this, too, so I > thought it'd be okay. > >
Re: Is there any way to debug driver?
Have you tried: winedbg --gdb appname.exe? It will use gdb then and still see win32 symbols I think. Roderick On Wed, Jun 17, 2009 at 5:49 PM, Wang, Robin wrote: > We also have tried using winedbg, but it cannot break into our driver either. > > The only way we can break into our driver before is using "gdb wine-pthread", > but now it is not available. > > Do you have some suggestion on winedbg configuration to make it able to break > into graphics drivers. > > Thanks > > -Original Message- > From: Henri Verbeet [mailto:hverb...@gmail.com] > Sent: Wednesday, June 17, 2009 9:27 PM > To: Guan, Xiao-Feng > Cc: wine-devel@winehq.org; Wang, Robin; Zhou, Jesse; Jin, Jian-Rong; Sun, > Sunny; Boudier, Pierre > Subject: Re: Is there any way to debug driver? > > 2009/6/17 Guan, Xiao-Feng : >> As we can see that, from version 1.1.23, all application fails to start on >> AMD card. We are going to investigate why it happens. If it is necessary, >> Would you please let us know a little more about the changes of this >> version? >> > There's a bug for that specific issue filed at > http://ati.cchtml.com/show_bug.cgi?id=1571. It contains an explanation > and test case. Current git versions of Wine avoid the bug by just not > attaching compressed and depth formats to an FBO, since they're not > supposed to be color-renderable anyway. > > I'm afraid I can't help much with getting gdb working with Wine, I > don't use/like debuggers much. I think you're supposed to use winedbg > for Wine debugging though. > > Henri > > >
Re: Wine MIME handling
Just for the record winebrowser already seems to support what is needed without any changes, so need for winemime. The following does the trick for pdf: REGEDIT4 [HKEY_CLASSES_ROOT\.pdf] @="pdffile" "Content Type"="application/pdf" [HKEY_CLASSES_ROOT\pdffile] [HKEY_CLASSES_ROOT\pdffile\shell] [HKEY_CLASSES_ROOT\pdffile\shell\open] [HKEY_CLASSES_ROOT\pdffile\shell\open\command] @="winebrowser \"%1\"" Roderick On Tue, Jun 16, 2009 at 8:13 PM, Roderick Colenbrander wrote: > On Tue, Jun 16, 2009 at 7:23 PM, Brian Vincent wrote: >> On Tue, Jun 16, 2009 at 5:26 AM, Roderick Colenbrander >> wrote: >>> >>> For the past few days I have been looking at MIME handling in Wine. A >>> program I'm using uses CreateProcess to launch a pdf file and I would >>> like to use the default native pdf viewer. >> >> I think it would be useful to have two different checkbox option in winecfg >> that ask: >> >> 1. "Always open files with native application if available?" >> 2. "Ask me whether to open with file formats with a native application or >> my Windows application?" >> >> (Optionally, saying "No" to #1 could imply #2. However, I think it might be >> clearer to explicitly have it as an option.) >> >> For instance, in the case of PDF's, say you have a great native viewer >> available and you want to use that viewer to view all PDF's. However, you >> also have Adobe Acrobat installed under Wine (hypothetical, I have no idea >> if that app works) and that's what you like to use for editing. You >> probably want to use the viewer most of the time, but every once in a while >> you'd probably like to be prompted to use Acrobat so you can edit the PDF. >> >> What would also be slick is to have the Windows Explorer "Open With..." >> functionality provide a list of native apps as well. >> >> -Brian >> > > The XDG spec which is what I would use defines how to find a program > which can handle the format (a default handler). The user can override > the handler but I'm not sure whether the spec also defines a way to > query which programs can handle the format. This would be needed for > the 'Open With...' stuff if it is possible then it should be done from > within shell32. > > What I'm interested in at this point is a method to add native apps to > handle opening of files (using HKEY_CLASSES_ROOT like on Windows). I > propose to do this using a winemime program/script. The tool would use > 'xdg-open' to get the default handler (when the user selects a > different handler from the default handler on the system, his > preference is selected). I'm not sure whether the tool needs to be a > script, program or whether it should be part of shell32. If it is a > script should xdg-open be forked or ported to C for a winelib version > of winemime? > > Roderick >
Re: Is there any way to debug driver?
At what sort of points did you try to set breakpoints before? Note that we are loading opengl dynamically which might make debugging a little bit harder. What about plain winedbg? Today I tried 'winedbg --gdb notepad' and indeed had some issues but plain winedbg worked properly. Further 'gdb wine notepad' also worked properly except that for some reason my back trace didn't include debug symbols. It might help to explain what commands you are exactly using and what sort of break points you attempt to set. Then we might be able to help you better. Roderick On Mon, Jun 22, 2009 at 8:52 AM, Guan, Xiao-Feng wrote: > The gdb way always turns into some SIGTRAP signal from preloader and > finally terminates the loading process. It seems that the WINE binary > loader would not co-work with gdb. > > We will try another way -- the WINE visual tests, to see if it is enough > for work. > > Thanks very much. > > Guan Xiaofeng > AMD Shanghai SW OpenGL Team > 021-61601838-25746 > xiao-feng.g...@amd.com > > > -Original Message- > From: Ken Thomases [mailto:k...@codeweavers.com] > Sent: Thursday, June 18, 2009 11:34 PM > To: Wang, Robin; wine-devel > Cc: Guan, Xiao-Feng; Boudier, Pierre; Zhou, Jesse; Jin, Jian-Rong; Sun, > Sunny > Subject: Re: Is there any way to debug driver? > > On Jun 17, 2009, at 10:49 AM, Wang, Robin wrote: > >> We also have tried using winedbg, but it cannot break into our >> driver either. >> >> The only way we can break into our driver before is using "gdb wine- >> pthread", but now it is not available. >> >> Do you have some suggestion on winedbg configuration to make it able >> to break into graphics drivers. > > As already mentioned by Ben Klein, just try "gdb wine" instead of "gdb > wine-pthread". The executable name has changed. That's all. > > Cheers, > Ken > > > > > >
Re: Is there any way to debug driver?
It was just mentioned on IRC that the environment variable WINELOADERNOEXEC=1 needs to be set. After that you can just run 'gdb wine' and continue the same way as using wine-preloader. Roderick On Mon, Jun 22, 2009 at 10:24 PM, Eric Pouech wrote: > Wang, Robin a écrit : >> >> Hi Roderick, >> >> Using winedbg, it is OK for us to break into libGL.so. But we cannot set >> break point in our dri drivers, which is loaded by libGL.so using dlopen(). >> >> > > please send me the output of running > WINEDEBUG=+dbghelp wine > > and then at debugger prompt > > Wine-dbg> break your_func_in_dri_driver > Wine-dbg> cont > > TIA > > -- > Eric Pouech > "The problem with designing something completely foolproof is to > underestimate the ingenuity of a complete idiot." (Douglas Adams) > > >
Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?
On Thu, Jun 25, 2009 at 10:06 PM, Austin English wrote: > On Thu, Jun 25, 2009 at 8:56 AM, wrote: >> Hi, >> >> Yesterday I edited http://wiki.winehq.org/MacOSX/FAQs to be much less >> outdated than before and today I found that Dmitry Timoshkov removed all >> references to Mike Kronenberg's Wine binary distribution at >> http://www.kronenberg.org/darwine/ >> >> This is unappropriate censorship to me. >> http://wiki.winehq.org/MacOSX/FAQs?action=diff&rev2=39&rev1=40 >> >> Am I upset? It costs me precious time to write code and >> documentation, so I dislike it when it gets deleted for >> uncomprehensible reasons. Censorship may be too strong a word. >> >> The only gripes I understand about Kronenberg's work are: >> - Although he agreed to change the name from Darwin to Wine in May, he has >> not yet done so. Cf. >> http://www.winehq.org/pipermail/wine-devel/2009-May/075775.html >> - Similarly, the license is still GPL, while Wine switched to LGPL long ago. >> >> Other than that, his work seems solid and provides for a great user >> experience: >> >> + It's built with Xcode 2.5, so it does not suffer from bug #14920 >> http://bugs.winehq.org/show_bug.cgi?id=14920 >> So 16bit applications work. >> >> + It provides a WineHelper GUI applications that supposedly makes it >> easy to start applications by clicking on icons. >> I never used it and am still researching the equivalent of >> xyz.desktop files from Linux. >> winemenubuilder does not work on MacOS so far. >> >> + It contains a newer FreeType library than Apple's which I've read is buggy. >> I can confirm that e.g. his winecfg "About" page looks as crisp as >> on Linux, whereas my build using only Apple resources shows ugly 'W' >> and kerning: in "Bibliothek", there should be one pixel horizontal >> space between letters, never 2. On Linux all lines are exactly one >> pixel wide, crisp as if hand-drawn. >> HKCU\FontSmoothing does not help, as the ugly 'W' just gets shades >> of grey. >> Perhaps the only difference is Tahoma.ttf (the 'f' looks different), >> i.e. font files rather than FreeType, but so far I did not further >> investigate this issue. >> >> + He's been providing a binary distribution for a long time. Linux >> experience shows that most people tend to download binaries rather than >> build themselves from source. Users of gentoo are sometimes >> considered exotic for that reason. OTOH on Mac, this seems normal, as >> neither Fink nor MacPorts provide online binary repositories. Strange. >> >> + I looked into his build script. >> http://www.kronenberg.org/darwine/buildenv-1.1.5.zip >> It is basically ./configure & make as far as Wine is concerned. >> I can start /Volumes/Darwine/Contents.../bin/wine foo.exe like on Linux. >> Beside that, it builds WineHelper, FreeType and lots of other open >> source libraries. >> All but one of the 3-4 patches therein are obsolete (already in Wine >> git or perhaps only needed on Tiger). There's a single patch not in >> Wine: XGravity event handling. Hopefully Mike can comment on it. >> Presumably it should get into Wine as well. >> >> So to me his binary appears like a pretty normal Wine build. This is >> not Cedega. I am about to submit a bug report to Wine bugzilla about >> MIDI audio based on his binary; I see no reason to dismiss it. Sadly >> I cannot produce the bug compiling myself, because of the above >> all-16bit-apps-crash bug with the Xcode3.x that I own. > > The lingering problem is that those extra features make it different > from 'vanilla' wine. While most of the patches in there are obsolete, > they're still in the source and still applied. The build source isn't > current, some of the package downloads are busted (not really a reason > to 'block it' though). > > In that discussion you've already referenced, most of this is already > mentioned. > > If there were a plain vanilla wine built on OS X, I think more > developers would be receptive to it. Unfortunately, most developers > don't have access to Mac's, and/or aren't focused on packaging/etc., > but on more practical coding (fixing bugs, adding features, etc.). > > -- > -Austin > > I would be willing to assist with any Mac issues as I would need a LGPL'ed version of Wine on OSX myself. I'm assisting bringing a university program to Linux/Mac using Wine and for that I need decent Mac support. Darwine set some steps in the right direction and we could help making it a better experience. I do agree that the license / name issues should be solved. I'm also interested in a way to create application bundles of Wine + win32 app for Mac and plan to work on that. Perhaps others are interested as well. Roderick
Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?
On Fri, Jun 26, 2009 at 9:42 PM, Steven Edwards wrote: > On Fri, Jun 26, 2009 at 10:51 AM, Dmitry > Timoshkov wrote: >> Darwine site claims that it's under GPL. In any case different name means >> a different product regardless of claims and intentions. Darwine is not >> Wine, plain and simple. > > I have a Mac that I've given Austin English access to for his Wine > hacking needs and he's got a set of scripts for building and running > Winetests. I am happy to provide binaries of stock Winehq but I don't > see any reason why we can't link to Mike's Darwine build. Maybe he's > not had time to cleanup his site, documentation or whatever. > > As far as the patches go, fewer and fewer of them are needed. Austin > has been cleaning up the build script, which btw mostly just satisfies > dependencies. I don't know of any major patch we currently need to > make stock Wine not suck on OS X. Having the extra Darwine stuff like > the helper should not be a problem as it does not mess with Wine > directly. For my own tree, the only major hack I've used from Darwine > is the wine script that is used to launch Wine. It simply insures the > environment is always sane and has the normal stock wine binary > renamed to mwine. Certain Linux package maintainers have recently > expressed interest in bundling the DIB Engine and custom Icon sets in > their Wine packages are we going to stop allowing those package > maintainers to link on Winehq if they do this? > If they ship hacks like the DIB engine then we won't accept bug reports for it as it a real big hack and shouldn't be linked to from our website. Tweaking themes or icons is fine. Actually we just need to refine our .msstyles support and then icon can just be part of a theme like they are on Windows. Roderick
Re: Anyone at LinuxTag?
On Mon, Jun 29, 2009 at 8:28 AM, Scott Ritchie wrote: > Kai Blin wrote: >> >> On Monday 29 June 2009 07:51:03 Austin English wrote: >>> >>> On Mon, Jun 29, 2009 at 12:46 AM, Kai Blin wrote: >> Yes. Realistically, there will be a contract involved regulating what needs to be done to get the money. I very much doubt the government just go and drop money on random paypal buttons and hope for the best. The way I've seen stuff like this work before is that there's a call for bids from companies to implement certain features in a piece of software, maybe with the requirement at a reasonable effort to get the produced changes upstream. >>> >>> Ah, misunderstood what you meant there. >>> >>> Eventually some sort of foundation would be the best thing to head >>> toward, but that's a legal headache. >> >> I don't see how a foundation would help with a a situation like that. To >> recap the (theoretical) situation. Someone, let's call him the client, wants >> some features implemented in Wine and is ready to spend money on that. >> >> Now, there's three things the client could do. He could hire some >> developers to get the stuff he wants implemented. That's a huge >> administrative effort just to get some lines of code done, and as you tend >> to pay employees by work-hours, you need to estimate how long it will take >> to implement the feature. >> >> The more obvious thing to do (IMHO) is to go and contract somebody, >> company or individual to implement these features. As opposed to an >> employment contract, you usually agree on what needs to be delivered and pay >> only if it is delivered. >> Now what I understood you're suggesting is that instead of contracting a >> company or individual, the client could give the money to a Wine Foundation. >> How is that money going to turn into the code the client wants to have? Is >> the Wine Foundation going to hire Wine developers to work on such stuff? Is >> there enough money in development services like that to offer a stable job >> to any developer? >> > > There may very well be - Mozilla had a few full time employees years ago, > and at the time they had about as many users as we do. > > That doesn't even count other roles a foundation could play, such as > community organizing, developer recruiting, sponsoring "summer of code" > projects year round, or even just serving as a tax deduction for > Codeweavers' donated code. > > Thanks, > Scott Ritchie > > A full foundation could give us advantages like that. I really think that we could raise quite a bit of money (just see what other projects are receiving). We mainly lack good goals and policies what we should do with it. Sponsoring WineConf and perhaps even developers makes sense. The danger is of course competing with Codeweavers but I don't think it would be better for both. Right now Codeweavers works on areas which are critical to get programs they support working. This includes 'boring' stuff like msxml, msi, jscript and other parts which volunteers barely work. There are also big parts like our beloved DIB engine which take a lot of resources and might only get implemented if there is a serious need or a big paying customer. Else it is too expensive. I can imagine that if we had some good goals and organize lets say 1 or 2 fund raisers a year you might be able to raise 50k. This could be used for purposes like the ones explained but parts can also be used to sponsor Codeweavers (or an external developer) on things like a DIB engine which else never get implemented. Thanks, Roderick
Windows 2D GDI benchmark tools?
Hi, I'm working on rewriting Wine its blitting code using XRender. This has several advantages e.g. no need for depth conversion, no need for manual stretching/mirroring, it saves a lot of back-and-forth copying between X and further various operations will be accelerated by the GPU using XRender. (For a big part it might eliminate the need for a DIB engine!) Right now I'm looking for some 2D GDI benchmark tools which test blitting performance and other 2D operations and which work on Wine. I have tried Sisoft Sandra and PassMark but those don't work on Wine. Does anyone know any other 2D benchmark tools? It would help me a lot to isolate slow parts and optimize my code even further. Thanks, Roderick
Re: Wine very very slow in Chinese language of Linux
I think the slowness can be related to the font code. For some reason (still have to investigate why) font rendering performance (at least on nvidia and ati) is 50x faster if you enable font smoothing. (set it to rgb or bgr, gray is not that much faster). Axel use winetricks to enable it. Roderick On Sat, Jul 11, 2009 at 8:18 PM, Dan Kegel wrote: > Axel wrote: >> When using WINE in Chinese environment Linux, the WINE works very very slow >> even opening windows / clicking buttons > > Does this happen with the latest wine (1.1.25)? > If so, can you show us how to reproduce the problem on > an ubuntu 9.04 system? Remember, most of us > don't speak chinese, so you'll need to be very > explicit with your instructions. > > Thanks, > Dan > > >
Re: FW: Re: winequartz.drv Mac OS X UI discontinued?
On Sun, Jul 12, 2009 at 2:06 AM, James McKenzie wrote: > Rolf Kalbermatter wrote: >> On Thursday July 09, 2009 5:32 PM Chris Robinson wrote: >> >> >>> If OSX will always have Obj-C support, and the Obj-C code can be >>> restricted to OSX-only code, then the only sticking point, in my eyes, >>> would be how maintainable it is. After all, if only one or two people >>> can work with Obj-C code, it can bit-rot that much more quickly. >>> >> >> I think this is in fact the major issue here. There is certainly interest in >> starting such a project but maintaining it is a completely different beast. >> >> > This may be AJ's major concern. I don't know of many Obj-C programmers > on this project. > > James McKenzie > > > > Just something else. I think that the amount of obj-c code could be limited if we delegate as much of the work we can to OpenGL. That way we directly have a modern GPU accelerated GDI renderer like on Windows7. Yes perhaps older Intel Macs don't have great OpenGL drivers but I wouldn't consider that an issue as they could still use X11. I think that mostly we need OSX-code for window management and input (keyboard/mouse). Even in Winex11 we aren't that far away from switching to OpenGL. Right now I'm adding more XRender acceleration but the same (and even much more) can be done using OpenGL. In case of Winex11 we could use GLX_EXT_texture_from_pixmap and render stuff for which OpenGL isn't suited to a pixmap and then blit it using a texture. Roderick
Re: 2/2 winex11: add XRender based GetSrcAreaStretch [with patch]
Could you retry this patch using the latest XRender color conversion patch? There was a division by zero error which got triggered in some cases (not all 1-bit paths pass through my code yet). Roderick On Sun, Jul 12, 2009 at 8:36 PM, Austin English wrote: > On Sat, Jul 11, 2009 at 2:33 PM, Roderick > Colenbrander wrote: >> This time with patch. >> >> Roderick >> >> On Sat, Jul 11, 2009 at 9:08 PM, Roderick >> Colenbrander wrote: >>> Hi, >>> >>> This patch adds a XRender based GetSrcAreaStretch. A lot of work is >>> offloaded to X (less round trips are needed) and it can take advantage >>> of hardware acceleration. On Nvidia and AMD drivers blt performance >>> has improved by 20% in CrystalMark2004 while more optimizations can be >>> added later on. >>> >>> Regards, >>> Roderick Colenbrander > > Dan asked me to run appinstall with it, and when I did, found that a > ton of stuff breaks. > > Easiest to see is 'wine control'. It runs, but takes up 100% of a cpu > core, and the window never appears. > > Notepad++ (my dogfood text editor has the same problem). > > I'm working on adjusting the tests to handle this type of failure > better, and will try to run the full test suite on it soon. > > -- > -Austin >
Re: 2/2 winex11: add XRender based GetSrcAreaStretch [with patch]
I have just tested notepad++ on my system and it works fine. I haven't tested it using the old color patch but I'm quite certain that was the issue. If you can retest some apps. Roderick On Sun, Jul 12, 2009 at 9:10 PM, Roderick Colenbrander wrote: > Could you retry this patch using the latest XRender color conversion > patch? There was a division by zero error which got triggered in some > cases (not all 1-bit paths pass through my code yet). > > Roderick > > On Sun, Jul 12, 2009 at 8:36 PM, Austin English > wrote: >> On Sat, Jul 11, 2009 at 2:33 PM, Roderick >> Colenbrander wrote: >>> This time with patch. >>> >>> Roderick >>> >>> On Sat, Jul 11, 2009 at 9:08 PM, Roderick >>> Colenbrander wrote: >>>> Hi, >>>> >>>> This patch adds a XRender based GetSrcAreaStretch. A lot of work is >>>> offloaded to X (less round trips are needed) and it can take advantage >>>> of hardware acceleration. On Nvidia and AMD drivers blt performance >>>> has improved by 20% in CrystalMark2004 while more optimizations can be >>>> added later on. >>>> >>>> Regards, >>>> Roderick Colenbrander >> >> Dan asked me to run appinstall with it, and when I did, found that a >> ton of stuff breaks. >> >> Easiest to see is 'wine control'. It runs, but takes up 100% of a cpu >> core, and the window never appears. >> >> Notepad++ (my dogfood text editor has the same problem). >> >> I'm working on adjusting the tests to handle this type of failure >> better, and will try to run the full test suite on it soon. >> >> -- >> -Austin >> >
Re: 2/2 winex11: add XRender based GetSrcAreaStretch
Good to hear. There are various optimizations which I still have to make which can boost performance some more. For instance in case of SRCCOPY (means a direct copy from a source to a destination without any fancy blending or some bit-wise operation) I can save a 'memcpy' and I don't always have to recreate XRender Pictures which could also help. Performance will get better :) Roderick On Tue, Jul 14, 2009 at 1:51 PM, Aurimas Fišeras wrote: > On 07/11/2009 10:08 PM, Roderick Colenbrander wrote: >> Hi, >> >> This patch adds a XRender based GetSrcAreaStretch. A lot of work is >> offloaded to X (less round trips are needed) and it can take advantage >> of hardware acceleration. On Nvidia and AMD drivers blt performance >> has improved by 20% in CrystalMark2004 while more optimizations can be >> added later on. > > I get a similar performance increase on intel driver too. > > > >
RFC XRender add support for dibsections in more color depths
Hi,
For some weeks I have been working on moving more 2D rendering to
XRender. XRender has three advantages for Wine. First of all it allows
us to perform more rendering operations using X which we previously
did using a combination of software rendering and back-forth copying
between the Xserver. Second XRender offers depth conversion (this
gives us proper alpha support in Wine and allows us to bypass DIB
color conversion in some cases!). Third XRender brings us more
hardware acceleration and that way more performance.
The patch attached to this thread adds support for dibsections in
additional color depths. On Xservers running at 24-bit this patch
offers us dibsections in 1-bit/15-bit/16-bit/24-bit/32-bit. (32-bit is
for proper alpha support) Big parts of the Wine X11 Driver make
assumptions about having only two color depths around (1-bit and
screen_depth e.g. 24-bit). I would like to request that people apply
the current patch to latest git (in combination with the Office2007
patch which I posted to wine-patches). Please report any 2D rendering
issues you see and also mention possible Wine crashes due to X errors
like BadMatch. Try as much programs as possible.
Thanks in advance,
Roderick Colenbrander
From 1ffe94b441654ba146cfe2fd10965b4aed43c03c Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Sun, 19 Jul 2009 18:44:21 +0200
Subject: [PATCH] Add support for dibsections in depths other than 1-bit / screen_depth when XRender is around.
---
dlls/winex11.drv/dib.c | 11 +-
dlls/winex11.drv/x11drv.h |1 +
dlls/winex11.drv/xrender.c | 84
3 files changed, 95 insertions(+), 1 deletions(-)
diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c
index 07ce9e1..3e88cbe 100644
--- a/dlls/winex11.drv/dib.c
+++ b/dlls/winex11.drv/dib.c
@@ -4683,6 +4683,7 @@ HBITMAP CDECL X11DRV_CreateDIBSection( X11DRV_PDEVICE *physDev, HBITMAP hbitmap,
{
X_PHYSBITMAP *physBitmap;
DIBSECTION dib;
+int redMask, greenMask, blueMask;
if (!(physBitmap = X11DRV_init_phys_bitmap( hbitmap ))) return 0;
physBitmap->status = DIB_Status_None;
@@ -4699,7 +4700,7 @@ HBITMAP CDECL X11DRV_CreateDIBSection( X11DRV_PDEVICE *physDev, HBITMAP hbitmap,
/* create pixmap and X image */
wine_tsx11_lock();
-physBitmap->pixmap_depth = (dib.dsBm.bmBitsPixel == 1) ? 1 : screen_depth;
+physBitmap->pixmap_depth = X11DRV_XRender_GetDIBDepth(&dib, &redMask, &greenMask, &blueMask);
physBitmap->pixmap = XCreatePixmap( gdi_display, root_window, dib.dsBm.bmWidth,
dib.dsBm.bmHeight, physBitmap->pixmap_depth );
#ifdef HAVE_LIBXXSHM
@@ -4713,6 +4714,14 @@ HBITMAP CDECL X11DRV_CreateDIBSection( X11DRV_PDEVICE *physDev, HBITMAP hbitmap,
wine_tsx11_unlock();
if (!physBitmap->pixmap || !physBitmap->image) return 0;
+/* When XRender is around and used, we also support dibsections in other formats like 16-bit. In these
+ * cases we need to override the mask of XImages. The reason is that during XImage creation the masks are
+ * derived from a 24-bit visual (no 16-bit ones are around when X runs at 24-bit). SetImageBits and other
+ * functions rely on the color masks for proper color conversion, so we need to override the masks here. */
+physBitmap->image->red_mask = redMask;
+physBitmap->image->green_mask = greenMask;
+physBitmap->image->blue_mask = blueMask;
+
/* install fault handler */
InitializeCriticalSection( &physBitmap->lock );
physBitmap->lock.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ": X_PHYSBITMAP.lock");
diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h
index 10af183..65a3a89 100644
--- a/dlls/winex11.drv/x11drv.h
+++ b/dlls/winex11.drv/x11drv.h
@@ -267,6 +267,7 @@ extern void X11DRV_XRender_DeleteDC(X11DRV_PDEVICE*);
extern BOOL X11DRV_XRender_ExtTextOut(X11DRV_PDEVICE *physDev, INT x, INT y, UINT flags,
const RECT *lprect, LPCWSTR wstr,
UINT count, const INT *lpDx);
+extern int X11DRV_XRender_GetDIBDepth(const DIBSECTION *dib, int *redMask, int *greenMask, int *blueMask);
BOOL X11DRV_XRender_GetSrcAreaStretch(X11DRV_PDEVICE *physDevSrc, X11DRV_PDEVICE *physDevDst,
Pixmap pixmap, GC gc,
INT xSrc, INT ySrc,
diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c
index 3bf37e4..31b9ce7 100644
--- a/dlls/winex11.drv/xrender.c
+++ b/dlls/winex11.drv/xrender.c
@@ -427,10 +427,55 @@ static WineXRenderFormat *get_xrender_format(WXRFormat format)
return NULL;
}
+static WineXRenderFormat *get_xrender_format_from_dibsection(const DIBSECTION *dib)
+{
+int redMask=0, greenMask=0, blueMask=0;
+int i;
+
+if(dib->dsBm.bmBitsPixel == 1)
+return get_xrender_format(WXR_FORMAT_MONO);
+
+/* Pale
Re: RFC XRender add support for dibsections in more color depths
I just forgot to mention that next to adding proper Alpha support this patch can dramatically improve performance in some programs. Especially in some 2D games which suffer from DIB depth conversion this patch helps a lot. E.g. C&C Tiberian Sun is a lot faster using this patch WITHOUT any opengl (for Tiberian Sun xrender is better than opengl). This is on Nvidia drivers which accelerate XRender well. Geforce6/7 users make sure InitialPixmapPlacement is set to 2 for optimal performance (this is the default value for Geforce8+ cards). Roderick On Thu, Jul 23, 2009 at 10:51 PM, Roderick Colenbrander wrote: > Hi, > > For some weeks I have been working on moving more 2D rendering to > XRender. XRender has three advantages for Wine. First of all it allows > us to perform more rendering operations using X which we previously > did using a combination of software rendering and back-forth copying > between the Xserver. Second XRender offers depth conversion (this > gives us proper alpha support in Wine and allows us to bypass DIB > color conversion in some cases!). Third XRender brings us more > hardware acceleration and that way more performance. > > The patch attached to this thread adds support for dibsections in > additional color depths. On Xservers running at 24-bit this patch > offers us dibsections in 1-bit/15-bit/16-bit/24-bit/32-bit. (32-bit is > for proper alpha support) Big parts of the Wine X11 Driver make > assumptions about having only two color depths around (1-bit and > screen_depth e.g. 24-bit). I would like to request that people apply > the current patch to latest git (in combination with the Office2007 > patch which I posted to wine-patches). Please report any 2D rendering > issues you see and also mention possible Wine crashes due to X errors > like BadMatch. Try as much programs as possible. > > Thanks in advance, > Roderick Colenbrander >
Re: RFC XRender add support for dibsections in more color depths
I guess some of the font or dib rendering code is making some depth assumptions somewhere. Is there an english version or demo version of the app? I could take a look at it then. Roderick On Fri, Jul 24, 2009 at 11:06 AM, Anders Jonsson wrote: > Roderick Colenbrander wrote: >> Hi, >> >> For some weeks I have been working on moving more 2D rendering to >> XRender. XRender has three advantages for Wine. First of all it allows >> us to perform more rendering operations using X which we previously >> did using a combination of software rendering and back-forth copying >> between the Xserver. Second XRender offers depth conversion (this >> gives us proper alpha support in Wine and allows us to bypass DIB >> color conversion in some cases!). Third XRender brings us more >> hardware acceleration and that way more performance. >> >> The patch attached to this thread adds support for dibsections in >> additional color depths. On Xservers running at 24-bit this patch >> offers us dibsections in 1-bit/15-bit/16-bit/24-bit/32-bit. (32-bit is >> for proper alpha support) Big parts of the Wine X11 Driver make >> assumptions about having only two color depths around (1-bit and >> screen_depth e.g. 24-bit). I would like to request that people apply >> the current patch to latest git (in combination with the Office2007 >> patch which I posted to wine-patches). Please report any 2D rendering >> issues you see and also mention possible Wine crashes due to X errors >> like BadMatch. Try as much programs as possible. >> >> Thanks in advance, >> Roderick Colenbrander >> >> > Hi, > > tested the patch, and it makes some improvement on bug 10408: > http://bugs.winehq.org/show_bug.cgi?id=10408#c24 > > The drawback is that some text that is supposed to be white now is > colored. See comparison: > http://bugs2.winehq.org/attachment.cgi?id=22572 >
Re: Request for Review: Cursor & Icon patches
On Sat, Jul 25, 2009 at 8:04 AM, lats wrote: > On 25/07/09 12:46, Daniel Santos wrote: > >> >> I finished the actual code about 3 weeks ago, >>> >>> but it's been a lot of work for me to split it out into >>> smaller pieces, especially being new to git. > > The intention is that is that you build and test smaller chunks, hence the > term "commit often". It certainly makes it easier later on. > > > Sure in general you should submit small chunks but in this case it is a very invasive change and I think Alexandre wants to see the overal work before he lets in small chunks (e.g. changes in winex11, wineserver and other parts are needed). Unfortunately I don't know anything about the cursor code, so can't comment on it. I think Henri, Alexandre and perhaps some other can comment on it. Roderick
Re: RFC XRender add support for dibsections in more color depths
Hi all,
This is an updated version of my patch. It should fix the XChangeGC
crash but the text color issue in that japanese game is still around.
I hope to receive some more feed back.
Roderick
On Sat, Jul 25, 2009 at 11:20 PM, Jesse Allen wrote:
> On Thu, Jul 23, 2009 at 2:51 PM, Roderick
> Colenbrander wrote:
>> Hi,
>>
>> For some weeks I have been working on moving more 2D rendering to
>> XRender. XRender has three advantages for Wine. First of all it allows
>> us to perform more rendering operations using X which we previously
>> did using a combination of software rendering and back-forth copying
>> between the Xserver. Second XRender offers depth conversion (this
>> gives us proper alpha support in Wine and allows us to bypass DIB
>> color conversion in some cases!). Third XRender brings us more
>> hardware acceleration and that way more performance.
>>
>> The patch attached to this thread adds support for dibsections in
>> additional color depths. On Xservers running at 24-bit this patch
>> offers us dibsections in 1-bit/15-bit/16-bit/24-bit/32-bit. (32-bit is
>> for proper alpha support) Big parts of the Wine X11 Driver make
>> assumptions about having only two color depths around (1-bit and
>> screen_depth e.g. 24-bit). I would like to request that people apply
>> the current patch to latest git (in combination with the Office2007
>> patch which I posted to wine-patches). Please report any 2D rendering
>> issues you see and also mention possible Wine crashes due to X errors
>> like BadMatch. Try as much programs as possible.
>>
>> Thanks in advance,
>> Roderick Colenbrander
>>
>>
>>
>>
>
>
>
> Very nice Roderick, it seems to be working on my system with
> StarEdit.exe where it is faster. It seems like it could be a good
> solution.
>
> Jesse
>
From 80f7325253f8b38750398daf044f7c6e32f772e1 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Sun, 26 Jul 2009 22:35:59 +0200
Subject: [PATCH] Add support for dibsections in more formats when XRender is around.
---
dlls/winex11.drv/bitmap.c |1 +
dlls/winex11.drv/brush.c | 16 +++--
dlls/winex11.drv/dib.c | 11 +++-
dlls/winex11.drv/x11drv.h |1 +
dlls/winex11.drv/xrender.c | 140
5 files changed, 161 insertions(+), 8 deletions(-)
diff --git a/dlls/winex11.drv/bitmap.c b/dlls/winex11.drv/bitmap.c
index a288352..03e78a0 100644
--- a/dlls/winex11.drv/bitmap.c
+++ b/dlls/winex11.drv/bitmap.c
@@ -161,6 +161,7 @@ BOOL CDECL X11DRV_CreateBitmap( X11DRV_PDEVICE *physDev, HBITMAP hbitmap, LPVOID
physBitmap->pixmap_depth = (bitmap.bmBitsPixel == 1) ? 1 : screen_depth;
physBitmap->pixmap = XCreatePixmap(gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight, physBitmap->pixmap_depth);
+//ERR("hbitmap=%p pixmap_depth=%d pixmap=%p\n", hbitmap, physBitmap->pixmap_depth, physBitmap->pixmap);
wine_tsx11_unlock();
if (!physBitmap->pixmap)
{
diff --git a/dlls/winex11.drv/brush.c b/dlls/winex11.drv/brush.c
index c94e04e..37d5e1f 100644
--- a/dlls/winex11.drv/brush.c
+++ b/dlls/winex11.drv/brush.c
@@ -204,7 +204,8 @@ static void BRUSH_SelectSolidBrush( X11DRV_PDEVICE *physDev, COLORREF color )
}
}
-
+//this will be moved to x11drv.h later on
+BOOL X11DRV_XRender_CopyBrush(X11DRV_PDEVICE *physDev, X_PHYSBITMAP *physBitmap, int width, int height);
/***
* BRUSH_SelectPatternBrush
*/
@@ -215,25 +216,26 @@ static BOOL BRUSH_SelectPatternBrush( X11DRV_PDEVICE *physDev, HBITMAP hbitmap )
if (!physBitmap || !GetObjectW( hbitmap, sizeof(bitmap), &bitmap )) return FALSE;
-wine_tsx11_lock();
if ((physDev->depth == 1) && (physBitmap->pixmap_depth != 1))
{
+wine_tsx11_lock();
/* Special case: a color pattern on a monochrome DC */
physDev->brush.pixmap = XCreatePixmap( gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight, 1);
/* FIXME: should probably convert to monochrome instead */
XCopyPlane( gdi_display, physBitmap->pixmap, physDev->brush.pixmap,
get_bitmap_gc(1), 0, 0, bitmap.bmWidth, bitmap.bmHeight, 0, 0, 1 );
+wine_tsx11_unlock();
}
else
{
physDev->brush.pixmap = XCreatePixmap( gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight,
- physBitmap->pixmap_depth );
-XCopyArea( gdi_display, physBitmap->pixmap, physDev->brush.pixmap,
- get_bitmap_gc(physBitmap->pixmap_depth),
Re: RFC XRender add support for dibsections in more color depths
Hi,
This version should hopefully fix your issues. I hope it also fixes
other gc issues .. I'm not sure if the patch is correct yet though.
Roderick
On Mon, Jul 27, 2009 at 11:08 AM, Matej
Spindler wrote:
> Roderick Colenbrander wrote:
>>
>> Hi all,
>>
>> This is an updated version of my patch. It should fix the XChangeGC
>> crash but the text color issue in that japanese game is still around.
>> I hope to receive some more feed back.
>>
>> Roderick
>>
>
> Hi Roderick
>
> With this patch Room Arranger crashes with:
>>
>> X Error of failed request: BadMatch (invalid parameter attributes)
>> Major opcode of failed request: 56 (X_ChangeGC)
>> Serial number of failed request: 18560
>> Current serial number in output stream: 18919
>
> Program can be downloaded from: http://www.roomarranger.com/
>
> Matej
>
>
>
From d97239729b73a0d46a0130867828b5ab6f40a707 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Sun, 26 Jul 2009 22:35:59 +0200
Subject: [PATCH] Add support for dibsections in more formats when XRender is around.
---
dlls/winex11.drv/bitmap.c |1 +
dlls/winex11.drv/brush.c | 18 --
dlls/winex11.drv/dib.c | 11 +++-
dlls/winex11.drv/x11drv.h |1 +
dlls/winex11.drv/xrender.c | 140
5 files changed, 163 insertions(+), 8 deletions(-)
diff --git a/dlls/winex11.drv/bitmap.c b/dlls/winex11.drv/bitmap.c
index a288352..03e78a0 100644
--- a/dlls/winex11.drv/bitmap.c
+++ b/dlls/winex11.drv/bitmap.c
@@ -161,6 +161,7 @@ BOOL CDECL X11DRV_CreateBitmap( X11DRV_PDEVICE *physDev, HBITMAP hbitmap, LPVOID
physBitmap->pixmap_depth = (bitmap.bmBitsPixel == 1) ? 1 : screen_depth;
physBitmap->pixmap = XCreatePixmap(gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight, physBitmap->pixmap_depth);
+//ERR("hbitmap=%p pixmap_depth=%d pixmap=%p\n", hbitmap, physBitmap->pixmap_depth, physBitmap->pixmap);
wine_tsx11_unlock();
if (!physBitmap->pixmap)
{
diff --git a/dlls/winex11.drv/brush.c b/dlls/winex11.drv/brush.c
index c94e04e..8621565 100644
--- a/dlls/winex11.drv/brush.c
+++ b/dlls/winex11.drv/brush.c
@@ -204,7 +204,8 @@ static void BRUSH_SelectSolidBrush( X11DRV_PDEVICE *physDev, COLORREF color )
}
}
-
+//this will be moved to x11drv.h later on
+BOOL X11DRV_XRender_CopyBrush(X11DRV_PDEVICE *physDev, X_PHYSBITMAP *physBitmap, int width, int height);
/***
* BRUSH_SelectPatternBrush
*/
@@ -215,25 +216,28 @@ static BOOL BRUSH_SelectPatternBrush( X11DRV_PDEVICE *physDev, HBITMAP hbitmap )
if (!physBitmap || !GetObjectW( hbitmap, sizeof(bitmap), &bitmap )) return FALSE;
-wine_tsx11_lock();
if ((physDev->depth == 1) && (physBitmap->pixmap_depth != 1))
{
+wine_tsx11_lock();
/* Special case: a color pattern on a monochrome DC */
physDev->brush.pixmap = XCreatePixmap( gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight, 1);
/* FIXME: should probably convert to monochrome instead */
XCopyPlane( gdi_display, physBitmap->pixmap, physDev->brush.pixmap,
get_bitmap_gc(1), 0, 0, bitmap.bmWidth, bitmap.bmHeight, 0, 0, 1 );
+wine_tsx11_unlock();
}
else
{
+int depth = physBitmap->pixmap_depth == 1 ? 1 : physDev->depth; //is this correct? room architect else triggers some fun gc depth mismatch issues
+//ERR("%d %d\n", physBitmap->pixmap_depth, physDev->depth);
physDev->brush.pixmap = XCreatePixmap( gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight,
- physBitmap->pixmap_depth );
-XCopyArea( gdi_display, physBitmap->pixmap, physDev->brush.pixmap,
- get_bitmap_gc(physBitmap->pixmap_depth), 0, 0, bitmap.bmWidth, bitmap.bmHeight, 0, 0 );
+ depth);
+
+/* XRender is needed because of possible depth conversion */
+X11DRV_XRender_CopyBrush(physDev, physBitmap, bitmap.bmWidth, bitmap.bmHeight);
}
-wine_tsx11_unlock();
if (physBitmap->pixmap_depth > 1)
{
@@ -260,7 +264,7 @@ HBRUSH CDECL X11DRV_SelectBrush( X11DRV_PDEVICE *physDev, HBRUSH hbrush )
if (!GetObjectA( hbrush, sizeof(logbrush), &logbrush )) return 0;
-TRACE("hdc=%p hbrush=%p\n", physDev->hdc,hbrush);
+TRACE("hdc=%p hbrush=%p style=%x\n", physDev->hdc,hbrush, logbrush.lbStyle);
if (physDev->brush.pixmap)
{
diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c
index 07ce9e1..3e
Re: coordinating efforts wrt rejected patches
I have just added two theming related patches which are bit-rotting. The patches fix drawing issues but in both cases tests are needed to prove that they are correct. Roderick On Tue, Jul 28, 2009 at 7:28 PM, Vincent Povirk wrote: > Some people have expressed interest recently in finding patches that > have been sent to wine-patches and have not yet been accepted into > winehq. The hope is that we can put some effort into getting feedback > to the authors of recent ones, and maybe the old abandoned patches > will catch the interest of some wandering developers. > > Sifting them out from the wine-patches archives is unfortunately not > trivial. I'm way too lazy to try to create a bot for this, but I > figure there may be enough interest to do it manually, going through > the wine-patches messages and searching for similarly-named messages > in wine-patches and wine-cvs. We just need to make sure we don't > duplicate effort. If people end up using this information effectively, > maybe someone will write a bot. If not, well, then it's good no one > wasted time on it. > > To this end, I have created this wiki page: > http://wiki.winehq.org/RejectedPatches > > I've gone through the submissions to wine-patches over one day and > added the rejected entries to that page, sorted based on whether > there's been a response. > > Anyone is welcome to use/update this information as they see fit and > to expand the range of checked messages (but not into the future, at > least until we get another round of commits). > > -- > Vincent Povirk > > >
Re: WINE and iTunes
According to appdb there is indeed some small installer regressions and for that some hack is posted there (see http://appdb.winehq.org/objectManager.php?sClass=version&iId=14793). Using this hack the program apparently installs and runs. The main limitation is that we don't have USB support for ipod/iphone synchronization. Maarten Lankhorst worked a bit on that last year but his work needs to be finished and cleaned up. Fixing the msi issue might be easy but it requires writing of a small msi test case I think. Roderick On Wed, Jul 29, 2009 at 12:47 PM, Martin Packer wrote: > Where are we with supporting iTunes? > > I've not seen anyone recently say it works. Installing doesn't seem to work > on 1.1.26. > > I'd've thought it would be a popular package to support. > > Just wondering where we are with it. (And whether help is needed.) > > Thanks, Martin > > Martin Packer > Performance Consultant > IBM United Kingdom Ltd > +44-20-8832-5167 > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter ID: MartinPacker > > "They're figuring out that collaboration isn't a productivity hit, it makes > them smarter." Sam Palmisano on BlogCentral, 26 November 2008 > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > >
Re: RFC XRender add support for dibsections in more color depths
Hi all,
This is an updated version of the patch which also addresses the font
color issue in that japanese game. I hope as much people can test it
so that I can fix other potential bugs (hopefully there are none
left).
Roderick
On Tue, Jul 28, 2009 at 12:25 AM, Roderick
Colenbrander wrote:
> Hi,
>
> This version should hopefully fix your issues. I hope it also fixes
> other gc issues .. I'm not sure if the patch is correct yet though.
>
> Roderick
>
> On Mon, Jul 27, 2009 at 11:08 AM, Matej
> Spindler wrote:
>> Roderick Colenbrander wrote:
>>>
>>> Hi all,
>>>
>>> This is an updated version of my patch. It should fix the XChangeGC
>>> crash but the text color issue in that japanese game is still around.
>>> I hope to receive some more feed back.
>>>
>>> Roderick
>>>
>>
>> Hi Roderick
>>
>> With this patch Room Arranger crashes with:
>>>
>>> X Error of failed request: BadMatch (invalid parameter attributes)
>>> Major opcode of failed request: 56 (X_ChangeGC)
>>> Serial number of failed request: 18560
>>> Current serial number in output stream: 18919
>>
>> Program can be downloaded from: http://www.roomarranger.com/
>>
>> Matej
>>
>>
>>
>
From c202729ee60f45b4a136dbbc1bef2a2685bd26a2 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Sun, 26 Jul 2009 22:35:59 +0200
Subject: [PATCH] Add support for dibsections in more formats when XRender is around.
---
dlls/winex11.drv/bitmap.c |1 +
dlls/winex11.drv/brush.c | 18 +++--
dlls/winex11.drv/dib.c | 11 +++-
dlls/winex11.drv/x11drv.h |1 +
dlls/winex11.drv/xrender.c | 148 +++-
5 files changed, 169 insertions(+), 10 deletions(-)
diff --git a/dlls/winex11.drv/bitmap.c b/dlls/winex11.drv/bitmap.c
index a288352..03e78a0 100644
--- a/dlls/winex11.drv/bitmap.c
+++ b/dlls/winex11.drv/bitmap.c
@@ -161,6 +161,7 @@ BOOL CDECL X11DRV_CreateBitmap( X11DRV_PDEVICE *physDev, HBITMAP hbitmap, LPVOID
physBitmap->pixmap_depth = (bitmap.bmBitsPixel == 1) ? 1 : screen_depth;
physBitmap->pixmap = XCreatePixmap(gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight, physBitmap->pixmap_depth);
+//ERR("hbitmap=%p pixmap_depth=%d pixmap=%p\n", hbitmap, physBitmap->pixmap_depth, physBitmap->pixmap);
wine_tsx11_unlock();
if (!physBitmap->pixmap)
{
diff --git a/dlls/winex11.drv/brush.c b/dlls/winex11.drv/brush.c
index c94e04e..8621565 100644
--- a/dlls/winex11.drv/brush.c
+++ b/dlls/winex11.drv/brush.c
@@ -204,7 +204,8 @@ static void BRUSH_SelectSolidBrush( X11DRV_PDEVICE *physDev, COLORREF color )
}
}
-
+//this will be moved to x11drv.h later on
+BOOL X11DRV_XRender_CopyBrush(X11DRV_PDEVICE *physDev, X_PHYSBITMAP *physBitmap, int width, int height);
/***
* BRUSH_SelectPatternBrush
*/
@@ -215,25 +216,28 @@ static BOOL BRUSH_SelectPatternBrush( X11DRV_PDEVICE *physDev, HBITMAP hbitmap )
if (!physBitmap || !GetObjectW( hbitmap, sizeof(bitmap), &bitmap )) return FALSE;
-wine_tsx11_lock();
if ((physDev->depth == 1) && (physBitmap->pixmap_depth != 1))
{
+wine_tsx11_lock();
/* Special case: a color pattern on a monochrome DC */
physDev->brush.pixmap = XCreatePixmap( gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight, 1);
/* FIXME: should probably convert to monochrome instead */
XCopyPlane( gdi_display, physBitmap->pixmap, physDev->brush.pixmap,
get_bitmap_gc(1), 0, 0, bitmap.bmWidth, bitmap.bmHeight, 0, 0, 1 );
+wine_tsx11_unlock();
}
else
{
+int depth = physBitmap->pixmap_depth == 1 ? 1 : physDev->depth; //is this correct? room architect else triggers some fun gc depth mismatch issues
+//ERR("%d %d\n", physBitmap->pixmap_depth, physDev->depth);
physDev->brush.pixmap = XCreatePixmap( gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight,
- physBitmap->pixmap_depth );
-XCopyArea( gdi_display, physBitmap->pixmap, physDev->brush.pixmap,
- get_bitmap_gc(physBitmap->pixmap_depth), 0, 0, bitmap.bmWidth, bitmap.bmHeight, 0, 0 );
+ depth);
+
+/* XRender is needed because of possible depth conversion */
+X11DRV_XRender_CopyBrush(physDev, physBitmap, bitmap.bmWidth, bitmap.bmHeight);
}
-wine_tsx11_unlock();
if (physBitmap->pixmap_depth > 1)
{
@@ -260
Re: RFC XRender add support for dibsections in more color depths
Hi Reece, The only thing required is a git version of Wine and XRender libraries on your system. After that any app can be tested. On decent drivers like Nvidia you'll notice heavily improved 2D performance (e.g. useful for theming). When using a Geforce6/7 try to set 'nvidia-setings -a InitialPixmapPlacement=2' which makes sure all pixmaps are placed in video memory. Roderick On Wed, Jul 29, 2009 at 10:09 PM, Reece Dunn wrote: > 2009/7/29 Roderick Colenbrander : >> Hi all, >> >> This is an updated version of the patch which also addresses the font >> color issue in that japanese game. I hope as much people can test it >> so that I can fix other potential bugs (hopefully there are none >> left). > > I get: > > """ > re...@rowan:/media/hdd1/pkg/github/wine$ git apply > ~/Desktop/0001-Add-support-for-dibsections-in-more-formats-when-XRe.patch > /home/reece/Desktop/0001-Add-support-for-dibsections-in-more-formats-when-XRe.patch:158: > trailing whitespace. > if( dib->dsBm.bmBitsPixel == wxr_formats_template[i].depth && > /home/reece/Desktop/0001-Add-support-for-dibsections-in-more-formats-when-XRe.patch:300: > trailing whitespace. > > warning: 2 lines add whitespace errors. > """ > > when applying the patch. > > Do I need to get any additional packages in addition to the ones > mentioned at http://wiki.winehq.org/Recommended_Packages, and that are > installed via Dan's helper script for Ubuntu? > > When testing this, do I need anything over and above the NVidia binary > drivers? > > - Reece >
Re: winecfg: Add toggle for systray visibility
Hi Andrew, First of all it seems that the patch makes more changes than needed (e.g. lost of changes in En.rc. Second why is this patch needed? Various apps need the systray for proper functioning and hiding it doesn't look that nice to me.. Roderick On Thu, Jul 30, 2009 at 5:30 PM, Andrew Eikum wrote: > --- > programs/winecfg/En.rc | 21 +++-- > programs/winecfg/resource.h | 1 + > programs/winecfg/x11drvdlg.c | 37 +++-- > 3 files changed, 43 insertions(+), 16 deletions(-) > > > > > >
Re: winecfg: Add toggle for systray visibility
Hi Andrew, Good that you have removed the unneeded changes. I'm wondering where the support in winex11.drv is for the winecfg option you added. My git version doesn't have it and I can't remember seeing patches for it (though I might have missed them). If these patches indeed have not been submitted, I would urge you to submit those first. Regards, Roderick On Wed, Jul 29, 2009 at 8:20 PM, Andrew Eikum wrote: > --- > programs/winecfg/En.rc | 2 ++ > programs/winecfg/resource.h | 1 + > programs/winecfg/theme.c | 19 +++ > 3 files changed, 22 insertions(+), 0 deletions(-) > > > > > >
Re: RFC XRender add support for dibsections in more color depths
On Fri, Jul 31, 2009 at 9:25 AM, Austin English wrote:
> On Thu, Jul 23, 2009 at 3:51 PM, Roderick
> Colenbrander wrote:
>> Hi,
>>
>> For some weeks I have been working on moving more 2D rendering to
>> XRender. XRender has three advantages for Wine. First of all it allows
>> us to perform more rendering operations using X which we previously
>> did using a combination of software rendering and back-forth copying
>> between the Xserver. Second XRender offers depth conversion (this
>> gives us proper alpha support in Wine and allows us to bypass DIB
>> color conversion in some cases!). Third XRender brings us more
>> hardware acceleration and that way more performance.
>>
>> The patch attached to this thread adds support for dibsections in
>> additional color depths. On Xservers running at 24-bit this patch
>> offers us dibsections in 1-bit/15-bit/16-bit/24-bit/32-bit. (32-bit is
>> for proper alpha support) Big parts of the Wine X11 Driver make
>> assumptions about having only two color depths around (1-bit and
>> screen_depth e.g. 24-bit). I would like to request that people apply
>> the current patch to latest git (in combination with the Office2007
>> patch which I posted to wine-patches). Please report any 2D rendering
>> issues you see and also mention possible Wine crashes due to X errors
>> like BadMatch. Try as much programs as possible.
>>
>> Thanks in advance,
>> Roderick Colenbrander
>>
>>
>>
>>
>
> Still fails the gimp test in appinstall. It's just this patch on top
> of git, nothing else right?
>
> --
> -Austin
>
Yeah it is just this patch on top of git. At what point does gimp fail
for you? I tried to open some images including the png gimp splash
screen and I'm seeing no issues. To be certain that you are using the
right patch I have reattached it (this time with the white space
trailing issues fixed). Just to be sure what display drivers are you
using and what videocard?
Roderick
From 5cbb96d0d7268a2cb68574120eb00ef6d660f545 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Sun, 26 Jul 2009 22:35:59 +0200
Subject: [PATCH] Add support for dibsections in more formats when XRender is around.
---
dlls/winex11.drv/bitmap.c |1 +
dlls/winex11.drv/brush.c | 18 +++--
dlls/winex11.drv/dib.c | 11 +++-
dlls/winex11.drv/x11drv.h |1 +
dlls/winex11.drv/xrender.c | 148 +++-
5 files changed, 169 insertions(+), 10 deletions(-)
diff --git a/dlls/winex11.drv/bitmap.c b/dlls/winex11.drv/bitmap.c
index a288352..03e78a0 100644
--- a/dlls/winex11.drv/bitmap.c
+++ b/dlls/winex11.drv/bitmap.c
@@ -161,6 +161,7 @@ BOOL CDECL X11DRV_CreateBitmap( X11DRV_PDEVICE *physDev, HBITMAP hbitmap, LPVOID
physBitmap->pixmap_depth = (bitmap.bmBitsPixel == 1) ? 1 : screen_depth;
physBitmap->pixmap = XCreatePixmap(gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight, physBitmap->pixmap_depth);
+//ERR("hbitmap=%p pixmap_depth=%d pixmap=%p\n", hbitmap, physBitmap->pixmap_depth, physBitmap->pixmap);
wine_tsx11_unlock();
if (!physBitmap->pixmap)
{
diff --git a/dlls/winex11.drv/brush.c b/dlls/winex11.drv/brush.c
index c94e04e..8621565 100644
--- a/dlls/winex11.drv/brush.c
+++ b/dlls/winex11.drv/brush.c
@@ -204,7 +204,8 @@ static void BRUSH_SelectSolidBrush( X11DRV_PDEVICE *physDev, COLORREF color )
}
}
-
+//this will be moved to x11drv.h later on
+BOOL X11DRV_XRender_CopyBrush(X11DRV_PDEVICE *physDev, X_PHYSBITMAP *physBitmap, int width, int height);
/***
* BRUSH_SelectPatternBrush
*/
@@ -215,25 +216,28 @@ static BOOL BRUSH_SelectPatternBrush( X11DRV_PDEVICE *physDev, HBITMAP hbitmap )
if (!physBitmap || !GetObjectW( hbitmap, sizeof(bitmap), &bitmap )) return FALSE;
-wine_tsx11_lock();
if ((physDev->depth == 1) && (physBitmap->pixmap_depth != 1))
{
+wine_tsx11_lock();
/* Special case: a color pattern on a monochrome DC */
physDev->brush.pixmap = XCreatePixmap( gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight, 1);
/* FIXME: should probably convert to monochrome instead */
XCopyPlane( gdi_display, physBitmap->pixmap, physDev->brush.pixmap,
get_bitmap_gc(1), 0, 0, bitmap.bmWidth, bitmap.bmHeight, 0, 0, 1 );
+wine_tsx11_unlock();
}
else
{
+int depth = physBitmap->pixmap_depth == 1 ? 1 : physDev->depth; //is this correct? room architect else triggers some fun gc depth mismatch issues
+//ERR("%d %d\n", physBitmap->pixmap_depth, physDev->depth);
WGL: fix usage of non-GLX visual in glXCreateContext
Hi,
We should not expect that the default Wine visual supports GLX, use
glXChooseVisual instead. This should fix bug 19570.
Regards,
Roderick Colenbrander
From 72f1dc239dc76f323288304aa902c97f343fca9e Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Fri, 31 Jul 2009 22:50:36 +0200
Subject: [PATCH] We should not expect that the default visual supports GLX. This caused some issues by XQuartz which they fixed but nonetheless we are violating the GLX standard, so use glXChooseVisual instead.
---
dlls/winex11.drv/opengl.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c
index b2cf82a..4e4a3a0 100644
--- a/dlls/winex11.drv/opengl.c
+++ b/dlls/winex11.drv/opengl.c
@@ -275,15 +275,12 @@ MAKE_FUNCPTR(glFlush)
static BOOL infoInitialized = FALSE;
static BOOL X11DRV_WineGL_InitOpenglInfo(void)
{
-
int screen = DefaultScreen(gdi_display);
Window win = RootWindow(gdi_display, screen);
const char* str;
-Visual *visual;
-XVisualInfo template;
XVisualInfo *vis;
-int num;
GLXContext ctx = NULL;
+int attribList[] = {GLX_RGBA, GLX_DOUBLEBUFFER, None};
if (infoInitialized)
return TRUE;
@@ -291,9 +288,7 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
wine_tsx11_lock();
-visual = DefaultVisual(gdi_display, screen);
-template.visualid = XVisualIDFromVisual(visual);
-vis = XGetVisualInfo(gdi_display, VisualIDMask, &template, &num);
+vis = pglXChooseVisual(gdi_display, screen, attribList);
if (vis) {
WORD old_fs = wine_get_fs();
/* Create a GLX Context. Without one we can't query GL information */
--
1.6.0.4
Re: Status of XI2 mouse stuff?
Hi Luke, Paul Hampson (TBBle on IRC) worked on it. He has some patches but some cleaning up and restructuring (e.g. adding some new tasks to explorer.exe) and more is needed to get it into Wine. I'm not sure what the current status is. You can find his email in the wine-devel archives. Roderick On Sun, Aug 2, 2009 at 9:04 AM, Luke Benstead wrote: > Hi all, > > I remember seeing an email that someone had implemented DX mouse input > using the new XInput2 extensions. What's the status of that? Is it in > Wine already? > > Cheers, > > Luke. > > >
