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

Would like to get some feedback on GSOC idea

by M C

Hi everyone, My name is Marek Chmiel, I am a student a NEIU. I am studying computer science and network security related topics. This semester I had spent a fair amount of time writing crypt related functions with java, and became very interested in Cryptography. After looking over the suggested ideas on SOC official wine wiki I was pleasantly surprised to see that there was already a crypt related idea suggested. I have a great understanding of c++ and java, and though I know c I have not worked with it as much as the other languages. Implementing a DSS provider sounds like an awesome task to tackle, if someone has never written code for Linux, can they take on such a task? Are there any significant issues implementing a DSS that you guys know about? Any crypt GSOC ideas would you suggest for someone who has wrote limited amount of code for Linux? What I would also like to do, besides implementing a DSS provider, is to fix most if not all of the crypt related bugs that remain in Wine. This might seem like more than most people can chew, but viewing the Bug Tracking database it appears that there aren't that many crypt related bugs and might even be caused by a lack of a DSS provider (Hopefully this wouldn't create a entire new series of bugs). Thanks for any input I might receive, and look forward to speaking with you all. I can also be found on the irc for development with the nick "MarcoVonChmiel". Marek K Chmiel.

March 27, 2012

RFC: Duplicate in/out device naming

by Andrew Eikum

I'm working on Bug 14559 and have run into an interesting UI problem. In WinMM, there are three "classes" of devices: waveIn, waveOut, and mixer. Windows 7's WinMM implementation provides one mixer for each waveIn and waveOut device. The "WCHAR caps.szPname[32]" field for the matching mixer and waveIn/Out device are the same. Some applications, in this case Rosetta Stone 3, use the matching szPname fields to determine which mixer to associate with which device. The problem turns up when we have duplicate input and output device names. Consider: waveOut: 0: default 1: HDA Intel Analog 2: HDA Intel Digital waveIn: 0: default 1: HDA Intel Analog mixer: 0: default 1: HDA Intel Analog 2: HDA Intel Digital 3: default 4: HDA Intel Analog Rosetta Stone chooses waveIn[0] and starts iterating over the mixers' szPname fields, finding that mixer[0] matches. But, mixer[0] is actually associated with the waveOut default, not the waveIn default. Bad things happen. Windows 7 solves this problem implicitly by providing unique device names at the MMDevAPI level. For instance, the input device is Microphone and the output devices are Stereo and Headphones. Hacking the registry to force duplicate MMDevAPI device names actually does result in duplicate mixer names. But Wine's backends don't provide this kind of information, so we simply provide the ALSA device name as the device's name. As an attempt to solve this in Wine, I added a prefix to each MMDevice indicating its flow direction. The unique identifier must be a prefix, as WinMM's szPname field truncates at 31 characters. This gives WinMM device names like: waveOut: 0: Out: default 1: Out: HDA Intel Analog 2: Out: HDA Intel Digital This solves the Rosetta Stone issue, as you can see in the bug. But when testing this in other applications, it quickly becomes silly. Audacity 1.3 adds its own "Out: " prefix to WinMM device names, creating "Out: Out: default" in the UI. Dynamically adding prefixes only if a duplicate device is present causes issues with duplicates appearing/disappearing. Trying to remember if a duplicate has ever been present is quite "ugly" in code, requiring storing that kind of information in the registry. So I don't know what to do. Have ugly, redundant device names? Leave Rosetta Stone broken, as it is arguably an application bug? Try to guess at the device type, and insert names like "Speakers" and "Microphone" into the MMDevAPI device name, even if that might be wrong? Thoughts? Andrew

March 27, 2012

Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > On 03/27/2012 08:04 AM, Alexandre Julliard wrote: >> Vitaliy Margolen<wine-devel(a)kievinfo.com> writes: >> >>> Dinput needs to talk to x11drv directly to get xi2 events. Same for >>> requests to clip cursor in exclusive mode. The current method of using >>> hooks can stay for backwards compatibility. >> >> I'm not at all convinced that this would be an improvement, particularly >> since you still need the events to follow the normal path for apps that >> don't use dinput. >> > In exclusive mode dinput consumes those events - they should not be > making it to the actual application. So it's not a problem there. In > background mode they are duplicated - again not an issue. The point is that we need to send the events to the server and to the hooks anyway, so dinput might as well get them from there instead of having its own back channel. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2012

Re: [PATCH] mciqtz: Actually assign result to the output structure

by Aric Stewart

Hi Joerg, Cool, but what I could use is concrete test cases with reported failures. Could you give me some example scripts, maybe with accompanying media files, with the issues pointed out. You could give me where the expected behavior does not match the existing behavior. clear tests and procedures like that will allow me to really focus in on what is going wrong. thanks! -aric On 12/03/23 13:18, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > Aric Stewart wrote: >> If you know about specifically quartz issues I am happy to start looking at them. > > I find the following very specific: > Mciqtz is nothing but a pass-through to quartz' IVideoWindow_* IMediaSeeking_* > IMediaControl_ and IGraphBuilder_QueryInterface. > So using mciqtz is like using quartz directly. The nice thing is: > every bug you find is a bug in Wine, since only Wine > source is involved, without third-party app. > That's why I find working with the MCI very rewarding. > > The MCI shell is at > http://bugs.winehq.org/show_bug.cgi?id=20232#c10 > > Here are basic scenarios that do not work correctly now > -- in the following, replace foo.xyz with your choice of > .wav (embedding linear pcm, adpcm and esp. mp3), > .avi (with whatever RLL/iccvid/msvidc1/etc. video format), > use .avi with and without audio tracks, > .mp3 or > .mpg audio/video (if you feel like stressing winegstreamer) > (even .wma if you feel like using codec outside Wine) > You may even try .mid files, but perhaps that would use DirectMusic in native. > > Open foo.xyz type mpegvideo alias q > > Window q state show > Status q time format # optional, yields "frames" with .avi > Set q time format milliseconds # optional > Status q length > Set q time format frames # restore default for .avi > Status q length > Seek q to start > Play q notify # or alternatively > Play q from 0 notify > Play q from 5 to 10 > Play q from 0 repeat notify # repeat flag not yet implemented > Status q position > Status q mode # should yield "stopped" or "playing" > Set q time format bytes # expect MCIERR_UNSUPPORTED_FUNCTION == refused > # presumably, quartz does not work with bytes (or would mciqtz intercept that?) > Stop q > Close q > > IIRC, Wine's DirectSoundRenderer would not stop and > regularly throw errors to the console. > > I just noticed that "play X from 5 repeat" behaves differently > between native mciavi32 and mciqtz (xp). Mciqtz repeats from 0 > while mciavi repeats from 5. Also their window refresh modes > are very different, mciqtz is mostly unresponsive while mciavi > refreshes even when not playing. So it is not the case > that MS made mciavi and mciqtz equal. > > Actually, I don't know where the default time format originates from. > A typical .avi yields "frames", using a .wav yields milliseconds. > So it is not a constant for mciqtz. > > So I think there's plenty of room for improvement in quartz, and you need > not wade through obscure logs produced by binary-only apps. And once > mciqtz/quartz behaviour becomes undistinguishable from native's as witnessed > by the MCI shell with "type mpegvideo", many bugzilla quartz items will > appear fixed automagically, I'm sure. > > Thank you, > Jörg Höhle

March 27, 2012

Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

by Vitaliy Margolen

On 03/27/2012 08:04 AM, Alexandre Julliard wrote: > Vitaliy Margolen<wine-devel(a)kievinfo.com> writes: > >> Dinput needs to talk to x11drv directly to get xi2 events. Same for >> requests to clip cursor in exclusive mode. The current method of using >> hooks can stay for backwards compatibility. > > I'm not at all convinced that this would be an improvement, particularly > since you still need the events to follow the normal path for apps that > don't use dinput. > In exclusive mode dinput consumes those events - they should not be making it to the actual application. So it's not a problem there. In background mode they are duplicated - again not an issue. It's a separate data feed into dinput of key press/releases and relative position changes - gets rid of all the complexity related to absolute -> relative calculations. And it's a possible source for RawInput whenever it will be implemented. It can receive background kbd & mouse events as well. Vitaliy.

March 27, 2012

Re: Need suggestion to choose a GSoC idea

by Qian Hong

Hi Aric, Thanks for reply. On Tue, Mar 27, 2012 at 7:56 PM, Aric Stewart <aric(a)codeweavers.com> wrote: > Hi, > > Oh, I would love this. However speaking from experience font code is very > hard. You would need to directly specify what you wanted to try to do and > what needs improvement. The code there is very messy and fragile but also > critical so it gets tricky to make any sweeping modifications. > > My favorite is to implement Font Association support, since currently we have no workaround for it without recompile source code. However, before investigate on font issue deeply, could I ask here for other wine developers' work plan? Just half day after I post my previous email, Huw and Kusanagi have sent their patches regarding font support to wine-patch. we have multiple developers working on this area, to prevent duplicate work, could you tell me is anyone working on Font Association support? Thanks a lot! > > I dont know if we need OCR. With the dib engine if we have a known font we > can probably just do bitmap compares. I am not an expert here but it sounds > interesting. > I didn't known we can just do bitmap compares, if that's possible I think the OCR plan could be schedule low priority, maybe I'll investigate it in the future. Is it a good GSoC idea to improve font related testcase base on bitmap compares? Thank you! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

March 27, 2012

Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Dinput needs to talk to x11drv directly to get xi2 events. Same for > requests to clip cursor in exclusive mode. The current method of using > hooks can stay for backwards compatibility. I'm not at all convinced that this would be an improvement, particularly since you still need the events to follow the normal path for apps that don't use dinput. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2012

Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.

by Vitaliy Margolen

On 03/27/2012 02:29 AM, Alexandre Julliard wrote: > Vitaliy Margolen<wine-devel(a)kievinfo.com> writes: > > If you have suggestions on how to do this differently please explain > them. Dinput needs to talk to x11drv directly to get xi2 events. Same for requests to clip cursor in exclusive mode. The current method of using hooks can stay for backwards compatibility. This can also apply to keyboard events for dinput as well. They main issue here is that you need a thread not directly attached to any window pulling all X's events. Dinput already have one such thread. You just need to let it talk to X. Vitaliy.

March 27, 2012

Re: Need suggestion to choose a GSoC idea

by Aric Stewart

Hi, On 3/26/12 10:29 PM, Qian Hong wrote: > - Improve Wine CJK font support > > The main idea is fix Bug 16325 [11], Aric and others have done a lot of work > on it, and I'm glad to participating too. I think the main blocker for Wine > CJK font support is Font Association now, is it suitable for a GSoC project? > Also I've filed some other Wine font bugs [12],[13],[14],[15],[16], I'm happy > to working on them. > Oh, I would love this. However speaking from experience font code is very hard. You would need to directly specify what you wanted to try to do and what needs improvement. The code there is very messy and fragile but also critical so it gets tricky to make any sweeping modifications. > - Improve Wine font test case > > This idea is similar with the above one, however, instead of fixing real bugs, > this idea is to prevent new bugs(regression). As having filed 100+ bugs I know > the pain of doing regression test if we can't script the test, this happens on > font related bugs. > > The main idea is to integrate an OCR engine to wine testcase, use ORC method > to detect whether the fonts display correctly. We already have very good open > source ORC engine [17] which is in Apache License. However tesseract-ocr is > written in C++ an I am worring that will not be integrated to Wine code tree. > I dont know if we need OCR. With the dib engine if we have a known font we can probably just do bitmap compares. I am not an expert here but it sounds interesting. -aric

March 27, 2012

Re: [3/8] scrrun: Add IFileSystem3 support

by Alistair Leslie-Hughes

Hi Jacek, > Is there any reason for this to be heap-based object? It looks to me like > it would better be a static object (AFAICS you don't even need FileSystem > struct since you're not going to store anything in it). No, Just habit to create them like this. Best Regards Alistair Leslie-Hughes

March 27, 2012