March 2011 - Wine-Devel - list.winehq.org

Re: [PATCH] winegcc - do not create .exe.so

by Chris Robinson

On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote: > On 03/20/2011 05:14 AM, Pali Rohár wrote: > > Can anybody review my patch? > > Not sure what you trying to do exactly. Wine already has wrapper that makes > all wine binaries executable after they are being installed into system. Wine installs wrapper scripts which call wine with the appropriate .exe.so DSO. The .exe.so file can't be run directly. As far as I can tell, the patch makes it so the .exe.so file can be run directly, by adding a _start section that automatically execs wine with all the same arguments passed on the command line. As a result, it removes the .so extension so you can, for example, just run the 'winecfg.exe' executable itself, with no 'winecfg' wrapper script needed. This stuff isn't an area I'm familiar with, so I can't really comment on the patch itself.

March 21, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Vitaliy Margolen

On 03/20/2011 05:14 AM, Pali Rohár wrote: > Can anybody review my patch? Not sure what you trying to do exactly. Wine already has wrapper that makes all wine binaries executable after they are being installed into system. As for the patch: - Do not use tab characters - Please no unneeded white space changes - Use git to create your patch. At the very minimum it have to have full path to the source file in the header - patch should be generated from the top of the source tree. Vitaliy.

March 20, 2011

Re: Idea

by Vitaliy Margolen

On 03/20/2011 12:12 PM, Sanket Patel wrote: > I Have One Idea ......... > Why Should not we make wine portable ? Elaborate in details please. How do you want to make something portable? This is not windows. Everything already can be packaged into a single binary. And if you talking about packaging 1/2 of the system into one package - no one would go with that. Vitaliy.

March 20, 2011

Re: Xbox 360 controller compatibility

by Vitaliy Margolen

On 03/20/2011 04:48 PM, Stefan Dösinger wrote: > but preferably joystick input should be done over the X server and winex11.drv. This sounds good in theory but completely useless in practice. The X11 interface does not support force feedback, so you'll need to talk to the device directly for that. And mixing different access methods to the same device isn't good. Vitaliy

March 20, 2011

Re: Xbox 360 controller compatibility

by Stefan Dösinger

On Sunday 20 March 2011 21:46:34 Austin English wrote: > > There are some patches still around (would have to look them up) and > > they work. <warn reason="clueless"> I think the main problem with implementing xinput.dll isn't xinput itself, it is the lack of a proper joystick infrastructure in wine. Currently dinput.dll reads the /dev/js* devices directly, but preferably joystick input should be done over the X server and winex11.drv. This needs some tricky adjustments, winex11.drv isn't a place where you can just add some hacky code and hope Alexandre doesn't notice. </warn>

March 20, 2011

Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)

by Stefan Dösinger

On Sunday 20 March 2011 22:29:34 Joshua Beck wrote: > I erred on the side of caution because I didn't want to spend all summer > working on a project that I couldn't finish. Finding the right amount of work is certainly tricky. Luckily d3dx9 has many functions, so if you find out that you have plenty of time left you can include extra work in your project later on. You don't have to get the set of work perfect at the start - reevaluating the amount of work needed and adjusting the goals during the project is part of gsoc. However, finding a most likely doable, but not overly simple set of work does improve the application. We'll provide feedback on this(as I just did, I hope others who know the library better will jump in if I am telling you incorrect things) > However I do have other > ideas that I would also like to implement. For instance, I would be > willing to implement the D3DXSave[Surface/Texture]ToFile* functions for > all file formats currently supported by WINE. Wrt this specific function we already have some related infrastructure for D3DXLoadSurfaceFrom* . Also other parts of Wine(gdi32.dll, windowscodecs.dll) have functions for handling various on-disk file formats which can(and should) be used. (That's just some generic implementation hint, it doesn't mean that it makes the idea good or bad)

March 20, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

Hi, Thanks for your proposal! I don't know the functions you suggest well enough personally to judge the amount of work that is needed. Potential mentors are Roderick, Matteo, Henri and me. I don't know who has time and is willing to mentor, but I think it is safe to say that we'll find somebody :-) We had two d3dx9-centered gsoc projects in the past, namely Matteo's shader assembler work and Tony Wasserka's texture loading work. Matteo's project succeeded and the code is in Wine now. Tony's code didn't make it in during the project, but at least parts(everything?) of it got committed later. As you can see we have another developer who's interested in d3dx9. Two projects on the same library are doable if they target independent parts. Luckily d3dx9 is a big collection of mostly independent helper functions. I don't want to jump to conclusions just yet, the formal application process will decide which proposals are accepted. Best regards Stefan On Sunday 20 March 2011 18:09:24 Michael Mc Donnell wrote: > Dear Wine developers, > > I would like implement some of the missing mesh functions in Wine's > D3DX9 for Google Summer of Code 2011. I would like to implement the > following functions: > - CloneMesh > - CloneMeshFVF > - ConvertPointRepsToAdjacency > - ConvertAdjacencyToPointReps > - GenerateAdjacency > > They seem to be suitable in size to implement during a summer, and I > have a good idea of how to implement them. I expect to first implement > tests and then implement the functions. > > I am a masters student at the Technical University of Denmark nearing > the end of my studies, and I have specialized in 3D computer graphics, > studying both real-time and physically based techniques, as well as > how to use existing 3D modeling tools to create animations. The mesh > functions should be fairly straight forward for me to implement as I > have recently taken an advanced course on geometry processing which > involved a lot of mesh manipulation. I have, furthermore, already > tests (for a shell32 function) in the wine test suite so I have some > knowledge of Wine development. > > Roderick Coldenbrander is listed as a possible mentor for "Direct3D - > Implement missing D3D9_xx DLLs" on the wiki. Are you still interested, > or would someone else like to be a mentor? > > Regards, > Michael Mc Donnell

March 20, 2011

Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)

by Joshua Beck

On 3/20/2011 1:02 PM, Stefan Dösinger wrote: > On Sunday 20 March 2011 18:15:20 Joshua Beck wrote: >> I'm looking for feedback on an idea for a Google Summer of Code project. > Cool, thanks for your interest! > >> I looked at bugzilla and found that the D3DX9 versions of >> Float16To32Array and Float32To16Array were needed for some games to run. >> I thought that implementing those functions would make a good Google >> Summer of Code project, but later discovered that Misha Koshelev had >> already implemented them in a patch that wasn’t committed yet. > I think those two functions are way too small for a summer of code > project(~2.5 months of work). I implemented the original half-float conversion > code in wined3d, and it took me about a day with some tests. This code didn't > have to deal with too many special cases, so the d3dx* implementation is a bit > more work, but still not enough to fill 2.5 months. I erred on the side of caution because I didn't want to spend all summer working on a project that I couldn't finish. However I do have other ideas that I would also like to implement. For instance, I would be willing to implement the D3DXSave[Surface/Texture]ToFile* functions for all file formats currently supported by WINE. The general idea I have for implementing them is to have two basic groups of functions. One would be to convert the format that the surface or texture is stored in to an intermediate, uncompressed format. The other group would convert from this uncompressed format to another format supported by these functions. If that isn't enough, I would also be willing to start adding support for DDS files to the various functions that need them (for example GetImageInfo*, LoadSurface*, and Save[Texture/Surface]*).

March 20, 2011

Re: Xbox 360 controller compatibility

by Austin English

On Sun, Mar 20, 2011 at 15:40, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > On Sun, Mar 20, 2011 at 1:26 PM, Alesh Slovak <aleshslovak(a)gmail.com> wrote: >> >> On 21 March 2011 00:21, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >>> >>> On 03/20/2011 08:20 AM, Alesh Slovak wrote: >>>> >>>> I am interested in getting the Xbox 360 controller working in wine. >>> >>> You'll need to implement xinput*.dll which is an empty stub in Wine. >> >> Do you know if there has been any previous effort that I can take a look >> at/use as a starting point? I found lots of references to such efforts, but >> they all seemed to fizzle out and there was never any code. >> > > There are some patches still around (would have to look them up) and > they work. The xinput API is very trivial. Essentially there is only > one real call there and that's to poll the device. The API is not so > nice though, because xinput was written in such a way that you can add > a controller whenever you want throughout the lifetime of the game. > The also 'nice' thing is that when you plug in a second controller, it > may actually become the 'first' controller (there is no guarantee) and > the first would become the second. A correct implementation would > 're-probe' for joysticks every 'poll' command :( http://www.winehq.org/pipermail/wine-patches/2008-November/064302.html http://www.winehq.org/pipermail/wine-patches/2008-November/064304.html http://www.winehq.org/pipermail/wine-patches/2008-November/064305.html -- -Austin

March 20, 2011

Re: Xbox 360 controller compatibility

by Roderick Colenbrander

On Sun, Mar 20, 2011 at 1:26 PM, Alesh Slovak <aleshslovak(a)gmail.com> wrote: > > On 21 March 2011 00:21, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >> >> On 03/20/2011 08:20 AM, Alesh Slovak wrote: >>> >>> I am interested in getting the Xbox 360 controller working in wine. >> >> You'll need to implement xinput*.dll which is an empty stub in Wine. > > Do you know if there has been any previous effort that I can take a look > at/use as a starting point? I found lots of references to such efforts, but > they all seemed to fizzle out and there was never any code. > There are some patches still around (would have to look them up) and they work. The xinput API is very trivial. Essentially there is only one real call there and that's to poll the device. The API is not so nice though, because xinput was written in such a way that you can add a controller whenever you want throughout the lifetime of the game. The also 'nice' thing is that when you plug in a second controller, it may actually become the 'first' controller (there is no guarantee) and the first would become the second. A correct implementation would 're-probe' for joysticks every 'poll' command :( Roderick

March 20, 2011

Re: Xbox 360 controller compatibility

by Alesh Slovak

On 21 March 2011 00:21, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > On 03/20/2011 08:20 AM, Alesh Slovak wrote: > >> I am interested in getting the Xbox 360 controller working in wine. >> > You'll need to implement xinput*.dll which is an empty stub in Wine. > Do you know if there has been any previous effort that I can take a look at/use as a starting point? I found lots of references to such efforts, but they all seemed to fizzle out and there was never any code.

March 20, 2011

GSoC: Cygwin and the file system

by Jay Yang

Hello, First an introduction, My name is Jay Yang, I'm currently an undergraduate at the University of Michigan, and as this email indicates, I'm interested in participating in Google Summer of Code. I've been looking at the Cygwin project idea listed on the Summer of Code page, and after looking at some bug reports, I found at least three bugs related to Cygwin that seem to have something to do with the file system. I also saw that the Cygwin page on the wine wiki seems to note that symlinks are one thing that do not work correctly. Is there some underlying bug or unimplemented feature that is causing these failures or are they each their own problem? Also would fixing some of these file system related issues be a good project? Thanks -- Jay Yang

March 20, 2011

Idea

by Sanket Patel

I Have One Idea ......... Why Should not we make wine portable ? -- " Live 2 Love and Love 2 Live "

March 20, 2011

Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)

by Stefan Dösinger

On Sunday 20 March 2011 18:15:20 Joshua Beck wrote: > I'm looking for feedback on an idea for a Google Summer of Code project. Cool, thanks for your interest! > I looked at bugzilla and found that the D3DX9 versions of > Float16To32Array and Float32To16Array were needed for some games to run. > I thought that implementing those functions would make a good Google > Summer of Code project, but later discovered that Misha Koshelev had > already implemented them in a patch that wasn’t committed yet. I think those two functions are way too small for a summer of code project(~2.5 months of work). I implemented the original half-float conversion code in wined3d, and it took me about a day with some tests. This code didn't have to deal with too many special cases, so the d3dx* implementation is a bit more work, but still not enough to fill 2.5 months.

March 20, 2011

Re: testing sending to mailing list

by Vitaliy Margolen

On 03/20/2011 11:13 AM, Joshua Beck wrote: > My last two emails to this list haven't been accepted. I think I figured out > the reason why. Instead of resending the last email I sent, which might make > it look like I'm spamming, I'm sending this test email instead. > You have to be subscribed to this ML in order to send e-mails. Otherwise they go through moderator(s) who usually take time due to huge volume of spam. Vitaliy.

March 20, 2011

d3dx10: Float16To32Array and Float32To16Array (GSoC)

by Joshua Beck

I'm looking for feedback on an idea for a Google Summer of Code project. I looked at bugzilla and found that the D3DX9 versions of Float16To32Array and Float32To16Array were needed for some games to run. I thought that implementing those functions would make a good Google Summer of Code project, but later discovered that Misha Koshelev had already implemented them in a patch that wasn’t committed yet. In looking up documentation on half floats and these functions gave me ideas for other improvements. For instance, the functions may be implemented differently in D3DX10. A post in this thread: http://www.devmaster.net/forums/showthread.php?t=10924 says that D3DX10 uses different rounding rules and can store NaNs and infinities. I have access to computers running Vista and 7 so I would be able to test how the D3DX10 versions of the functions convert floating point numbers. After doing so, I could make the D3DX10 versions of the functions by modifying the D3DX9 patch’s code. I could also write a conformance test to make sure that the functions are implemented correctly in D3DX10. Joshua Beck

March 20, 2011

testing sending to mailing list

by Joshua Beck

My last two emails to this list haven't been accepted. I think I figured out the reason why. Instead of resending the last email I sent, which might make it look like I'm spamming, I'm sending this test email instead.

March 20, 2011

GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

Dear Wine developers, I would like implement some of the missing mesh functions in Wine's D3DX9 for Google Summer of Code 2011. I would like to implement the following functions: - CloneMesh - CloneMeshFVF - ConvertPointRepsToAdjacency - ConvertAdjacencyToPointReps - GenerateAdjacency They seem to be suitable in size to implement during a summer, and I have a good idea of how to implement them. I expect to first implement tests and then implement the functions. I am a masters student at the Technical University of Denmark nearing the end of my studies, and I have specialized in 3D computer graphics, studying both real-time and physically based techniques, as well as how to use existing 3D modeling tools to create animations. The mesh functions should be fairly straight forward for me to implement as I have recently taken an advanced course on geometry processing which involved a lot of mesh manipulation. I have, furthermore, already tests (for a shell32 function) in the wine test suite so I have some knowledge of Wine development. Roderick Coldenbrander is listed as a possible mentor for "Direct3D - Implement missing D3D9_xx DLLs" on the wiki. Are you still interested, or would someone else like to be a mentor? Regards, Michael Mc Donnell

March 20, 2011

Re: [PATCH] Label verbosity levels.

by Vitaliy Margolen

On 03/19/2011 11:29 PM, max(a)mtew.isa-geek.net wrote: > The suffix logical form is not that difficult to understand. But is completely alien for the rest of the project. Please don't use it. Even Perl creator himself says not to use such notation. Vitaliy.

March 20, 2011

d3dx10: Float16To32Array and Float32To16Array (GSoC)

by Joshua Beck

I'm looking for feedback on an idea for a Google Summer of Code project. I looked at bugzilla and found that the D3DX9 versions of Float16To32Array and Float32To16Array were needed for some games to run. I thought that implementing those functions would make a good Google Summer of Code project, but later discovered that Misha Koshelev had already implemented them in a patch that wasn’t committed yet. In looking up documentation on half floats and these functions gave me ideas for other improvements. For instance, the functions may be implemented differently in D3DX10. A post in this thread: http://www.devmaster.net/forums/showthread.php?t=10924 says that D3DX10 uses different rounding rules and can store NaNs and infinities. I have access to computers running Vista and 7 so I would be able to test how the D3DX10 versions of the functions convert floating point numbers. After doing so, I could make the D3DX10 versions of the functions by modifying the D3DX9 patch’s code. I could also write a conformance test to make sure that the functions are implemented correctly in D3DX10. Joshua Beck

March 20, 2011

Re: Xbox 360 controller compatibility

by Vitaliy Margolen

On 03/20/2011 08:20 AM, Alesh Slovak wrote: > I am interested in getting the Xbox 360 controller working in wine. You'll need to implement xinput*.dll which is an empty stub in Wine. Vitaliy.

March 20, 2011

Xbox 360 controller compatibility

by Alesh Slovak

Hi, I apologize if this question has come up before, I could not find a search feature in the mailing list archives and google didn't give me much on the subject. I am interested in getting the Xbox 360 controller working in wine. Currently, I can use the controller, but it is recognized only as a generic controller. This is acceptable (although annoying) for games that allow me to freely configure the controller, but others seem to specifically look for an Xbox 360 controller, and when they can't find it, drop to keyboard controls. Firstly, I am not even sure this is something that should or can be handled in wine. Maybe this needs to be handled in the xpad kernel module, or maybe both. But my guess is that wine would need to detect an Xbox 360 controller and then explicitly present it as such to any games. I guess the first step would be to find out how exactly games detect the Xbox 360 controller under Windows and try to emulate that. Any other previous attempts that anyone knows of? I would appreciate it if anybody out there who has any knowledge in this area, can point me in the right direction. Thanks.

March 20, 2011

Re: [PATCH] Label verbosity levels.

by max＠mtew.isa-geek.net

From: max <max(a)mtew.isa-geek.net> On 03/19/2011 08:42 PM, Joris Huizer wrote: > On 03/19/2011 11:32 PM, Vitaliy Margolen wrote: >> On 03/18/2011 09:24 PM, max(a)mtew.isa-geek.net wrote: >>> - if ($opt_verbose> 0) >>> - { >>> - print "Processing ".$spec_name."\n"; >>> - } >>> + print "Processing ".$spec_name."\n" >>> + if $opt_verbose q>= $VERBOSE_INPUT; >> >> Please don't do this reverse notation. It's much more confusing to most people who are not too familiar with Perl. >> >> Also you changing logic, by replacing ">" (greater then) with ">=" (greater of equal. This is a big no-no to combine any logical changes with cleanup changes. > > This doesn't seem to change logic as $VERBOSE_INPUT equals 1 ( $VERBOSE_QUIET equals 0 ) > Correct. The clean-up involves two counter-acting logic changes. The change from > to >= is countered by increasing the target number by one. The result is that the number itself has the designated meaning. Before the number was one less than level needed to change the affect. There is no _functional_ change. The suffix logical form is not that difficult to understand. It shifts the emphasis from the conditional as the thing of primary import to the message being conveyed, where it belongs. On the other hand if anybody can come up with better names for the levels, PLEASE comment! Max

March 20, 2011

[GSOC] d3dx10: Float16To32Array and Float32To16Array

by Joshua Beck

I'm looking for feedback on an idea for a Google Summer of Code project. I looked at bugzilla and found that the D3DX9 versions of Float16To32Array and Float32To16Array were needed for some games to run. I thought that implementing those functions would make a good Google Summer of Code project, but later discovered that Misha Koshelev had already implemented them in a patch that wasn't committed yet. In looking up documentation on half floats and these functions gave me ideas for other improvements. For instance, the functions may be implemented differently in D3DX10. A post in this thread: http://www.devmaster.net/forums/showthread.php?t=10924 says that D3DX10 uses different rounding rules and can store NaNs and infinities. I have access to computers running Vista and 7 so I would be able to test how the D3DX10 versions of the functions convert floating point numbers. After doing so, I could make the D3DX10 versions of the functions by modifying the D3DX9 patch's code. I could also write a conformance test to make sure that the functions are implemented correctly in D3DX10. Joshua Beck

March 20, 2011

Re: [1/2] msvcrt: Implement _mbsupr_s (try2).

by Konrad Rzepecki

Dnia piątek, 18 marca 2011, Dan Kegel napisał(a): > But you could do a few tests. It's ok if some of them are todo_wine. > - Dan I've added some simple test and you have completly right to add them. The original libraries works different from what documentation says... Fourth try was send couple minutes ago. I really hope this is last one. -- Konrad Rzepecki (Hannibal)

March 20, 2011