Re: [GSoC] My (new) proposal for GSoC 2013
On Fri, Apr 5, 2013 at 10:08 AM, Stefan Dösinger
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-04-04 22:52, schrieb Gediminas Jakutis:
> There is some merit to the proposal, but it needs a lot more detail.
> We already have a lot of d3d tests (see
> dlls/{ddraw,d3d8,d3d9,d3d10core,dxgi}/tests/) . Those already provide
> a way to test if opengl works ok, to some extent - those tests are
> fairly strict and only pass on nvidia and r600g.
Good day!
This was discussed on the IRC a bit. The idea is to write
[performance?] tests that are to be used for dxdiag. (I suppose that
includes that funny spinning dx logo cube test found on the native
dxdiag).
Regarding the way of testing if opengl works - I was thinking in the lines of:
Making a GUI tool that would let simple users test if d3d and opengl
works along with providing info on current wine-specific d3d / opengl
settings / specs and similar thing. i.e. a user-friendly tool for,
uhm, simple users. Something related to what wine crash dialog is: I
bet many "simple" users were not much aware of Wine's debug output and
bug reporting. Meanwhile the crash dialog was something like - "Hey!
Something crashed! Take this info and report it if it's a bug!".
So yes, the idea idea of the "if works" test is to make a
user-friendly GUI tool. I believe that would be a great help in cases
for some reason opengl [and along d3d] breaks for a user, so it could
be easily identified early, thus helping to avoid situations where the
user looks into other possible causes / asks around for quite some
time before realizing opengl w/ d3d broke. Also, that might help avoid
possible invalid bug reports that would caused by a broken opengl /
d3d, yet reported without the user checking that properly.
> Extending dxdiag (and adding the information dialog) might be a good
> idea. I think there have been some projects concerning that in the
> past, I recommend to do some research.
I suppose when making those dxdiag-orientated tests, working with
built-in dxdiag a bit might just come naturally.
I hope that makes my intentions for GSoC a bit more clear. And, sorry
- I should've gone with more detail on previous letter, indeed.
--
Gediminas Jakutis
LDK Varčiai www.varciai.lt
Re: 64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
On Fri, Apr 5, 2013 at 3:36 AM, jordan wrote: > It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27). > On intel systems, it works on ALL versions. On my AMD system, it > doesn't work at all. Hello! Works fine on my AMD system: vinis@g44:/media/vinis/code/temp/fsthost-code$ WINEPREFIX=/media/vinis/bottles/test64 ./test64.exe ../ColourEQ_64.dll Load plugin ../ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close gcc 4.7.2; wine 1.5.27; -- Gediminas Jakutis LDK Varčiai www.varciai.lt
[GSoC] My (new) proposal for GSoC 2013
Hello! My previous application[1] turned out to be a total failure, hence making a completely different one. My proposal this time goes as follows: Write various D3D tests, mostly focusing on ones that can be later re-used for dxdiag in one way or another. Along with writing a tool that would allow users to easily test if d3d and wgl / opengl work & are set up properly. Info about me (copied over from [1]): >My name is Gediminas Jakutis. I study Informatics Engineering >[bachelor / undergraduate] at Kaunas University of Technology, second >year. >I wish to try out GSoC for the first time by helping to improve Wine. >My primary programming language is C. I am self-taught in C, but I >believe my knowledge is good enough. >I am quite familiar with Wine - I use it and experiment with it for >many years now. I am subscribed to and read wine-devel for more than a >year. >I browse through Wine's source code once in a while out of curiosity. >Thus, I have some knowledge of its structure. >Sadly, I have not written any patches for Wine yet. Mostly due to lack of >confidence. [1] http://www.winehq.org/pipermail/wine-devel/2013-March/099213.html Thank You for Your time Gediminas Jakutis -- LDK Varčiai www.varciai.lt
Re: [GSoC] My proposal for GSoC 2013
Hello again! Thank You all for the feedback! >There's a bit more info at >http://wiki.winehq.org/FAQ#head-dba86ae589dca54a116a3fc21f6237af45e8119c. That's odd - I could've sworn this was an environment variable which had the same limitations as using winecfg! My memory must be playing tricks on me... And yes, now that I tested it again, I see it really does the job. Except for not working with steam games, but that is steam's fault, not Wine's. >Though you did start early, so you have plenty of time to find other ideas Indeed... But now that I have to think of something else - what general areas in Wine are most welcome for GSoC ideas? I Looked over the GSoC Wine's wiki page, but I do not know how much I can trust it. That is because after GSoC 2012, it was only edited once. And the edit comment says: > remove some stuff that's done (still quite a bit of cleanup left).. Thank You for Your time! Gediminas Jakutis -- LDK Varčiai www.varciai.lt
[GSoC] My proposal for GSoC 2013
Hello! My name is Gediminas Jakutis. I study Informatics Engineering [bachelor / undergraduate] at Kaunas University of Technology, second year. I wish to try out GSoC for the first time by helping to improve Wine. My primary programming language is C. I am self-taught in C, but I believe my knowledge is good enough. I am quite familiar with Wine - I use it and experiment with it for many years now. I am subscribed to and read wine-devel for more than a year. I browse through Wine's source code once in a while out of curiosity. Thus, I have some knowledge of its structure. Sadly, I have not written any patches for Wine yet. Mostly due to lack of confidence. For GSoC, I am suggesting my own idea. In case this idea is not good, I am open to changing it, thinking of a new one, or adopting one. My idea: I have noticed that Wine's virtual desktop feature is very limited - if the first program on a prefix starts without a virtual desktop, all programs launched during the same session also start without a VD, disregarding any VD settings and/or requests with environment variables. And vice versa - if the first program starts inside a VD, all other programs in that sessions start in the VD. Often, this can be worked around by using separate Wine prefixes. Yet sometimes, this workaround is not possible. A good example: steam and games that only run properly in a VD. This forces the user to start steam in a VD and makes steam itself unusable while a game is running, especially if the game does not support the steam overlay. I would like to fix this limitation and make it possible to properly choose to run different programs on one prefix with or without a VD regardless what was chosen to programs already running in that prefix. I can already see this requiring changes in the winecfg utility, by the way. In case this turns out to be too easy of a project, I could implement some way to perform "alt-tabbing" between programs in a VD and/or an optional (enable-able in winecfg) rudimentary taskbar for changing/checking focus. I am very excited about participating in GSoC. And even more excited about starting to contribute to Wine by writing patches! Regardless if I get accepted or not, I wish to make Wine better. Thus, expect me to start submitting patches in the future even if I do not get accepted. ;] Sincerely, Gediminas Jakutis LDK Varčiai www.varciai.lt
Debugging and steam
Good day! Does anyone has any experience on dealing with Steam when debugging a game which depends on Steam? I am trying to squash a bug which makes a game crash. I started from relay logs, but have a bit of a problem - calls from Steam itself produce a few megabytes worth of relay logs every second. Those get mixed together with calls originating from the game. Also, it appears the game takes a couple of seconds after that "bad" call before crashing. When it is mixed together with Steam's own spam, it is a nightmare finding where it went wrong. I tried every idea I could muster on how to get a "pure" log of the game. Not a single one turned out to be effective. I am all out of ideas now. So if anyone had to deal with this and found a satisfactory solution, please enlighten me. Thank You in advance! -- Gediminas Jakutis LDK Varčiai www.varciai.lt
Re: Ubuntu 12.10 - anyone?
On Thu, Oct 18, 2012 at 5:25 AM, Erich E. Hoover wrote: > I just upgraded to 12.04, until they fix the "32-bit headers problem" > you'll have to manually create the symbolic links for the "-dev" > package behavior: > > cd /usr/lib/i386-linux-gnu > sudo ln -s libfreetype.so.6 libfreetype.so > sudo ln -s libXau.so.6 libXau.so > sudo ln -s libXcursor.so.1 libXcursor.so > sudo ln -s libXi.so.6 libXi.so > sudo ln -s libXext.so.6 libXext.so > sudo ln -s libXxf86vm.so.1 libXxf86vm.so > sudo ln -s libXrandr.so.2 libXrandr.so > sudo ln -s libXrender.so.1 libXrender.so > sudo ln -s libXinerama.so.1 libXinerama.so > sudo ln -s libXcomposite.so.1 libXcomposite.so > sudo ln -s libGLU.so.1 libGLU.so > sudo ln -s libOSMesa.so.6 libOSMesa.so > sudo ln -s libgnutls.so.26 libgnutls.so > sudo ln -s libsane.so.1 libsane.so > sudo ln -s libv4l1.so.0 libv4l1.so > sudo ln -s libv4l2.so.0 libv4l2.so > sudo ln -s liblcms.so.1 liblcms.so > sudo ln -s libcapi20.so.3 libcapi20.so > sudo ln -s libcups.so.2 libcups.so > sudo ln -s libfontconfig.so.1 libfontconfig.so > sudo ln -s libtiff.so.4 libtiff.so > sudo ln -s libmpg123.so.0 libmpg123.so > sudo ln -s libodbc.so.1 libodbc.so > sudo ln -s libopenal.so.1 libopenal.so > sudo ln -s libldap-2.4.so.2 libldap.so > sudo ln -s libldap_r-2.4.so.2 libldap_r.so > sudo ln -s liblber-2.4.so.2 liblber.so > sudo ln -s libxml2.so.2 libxml2.so > sudo ln -s libxslt.so.1 libxslt.so > sudo ln -s libssl.so.0.9.8 libssl.so > sudo ln -s libcrypto.so.0.9.8 libcrypto.so > sudo ln -s libjpeg.so.8 libjpeg.so > sudo ln -s mesa/libGL.so libGL.so > cd /usr/lib/i386-linux-gnu/mesa > sudo ln -s libGL.so.1 libGL.so > cd /lib/i386-linux-gnu > sudo ln -s libdbus-1.so.3 libdbus-1.so > sudo ln -s libpng12.so.0 libpng.so > > > It is important to note that all the above assumes that you have all > the packages you need loaded in ":i386" form. I have not included > packages that won't coinstall on amd64 or haven't gotten to work > (libhal, libgsm, gstreamer, libgphoto2). If your setup is anything > like mine then you'll only need to add a couple more packages: > sudo apt-get install libosmesa6:i386 libosmesa-dev libjpeg-turbo8-dev:i386 The situation must be different on 12.04, because I am looking at that link list and see libs from many packages that I know won't co-install on 12.10 (at least for me). -- Gediminas Jakutis LDK Varčiai www.varciai.lt
Re: Ubuntu 12.10 - anyone?
On Wed, Oct 17, 2012 at 11:21 PM, Joey Yandle wrote: > I've been happily building 32-bit wine on 64-bit ubuntu 12.04. I just > had to make a debootstrap chroot: > > https://help.ubuntu.com/community/DebootstrapChroot/ > The Wine Wiki page on this has a nice How-to http://wiki.winehq.org/WineOn64bit > It only takes a few minutes to setup, given a fast internet connections. > > No idea whether the multiarch conversion has progressed to where this is > no longer necessary. > Still needed. I just tested it again on 12.10 - many 32bit build dependencies conflict with many 64bit packages (and some of those are dependencies of packages unrelated to Wine...) Thus, building it without a chroot in a "clean" way is not yet possible. Also, building with both sane and tiff support is problematic: libsane-dev wants libtiff5-dev, which conflicts with libtiff4-dev (the one that wine wants) -- Gediminas Jakutis LDK Varčiai www.varciai.lt
