[PATCH 2/9] winemac.drv: EnumDisplayDevices placeholder implementation

[Donat Enikeev]

Hi Ken,

 >Then just leave the Mac driver patch out of the series.

Yes, it was a bad idea, I've just moved old implementation to `nulldrv` 
and submitted other fixes mentioned here, hope it's accepted and you 
are able to add necessary implementation for mac.

Best,
Donnie

On Вт, апр 25, 2017 at 9:18 , Ken Thomases <ken at codeweavers.com> 
wrote:
> On Apr 25, 2017, at 12:58 AM, Donat Enikeev <donat at enikeev.net> wrote:
>> 
>>>  This doesn't build:
>> 
>>  Thanks, will have a deeper look. Though since I don't have mac 
>> (even VM), it was aimed to bring just backward compatibility with 
>> the migration, while actual devices/displays enumeration, flags, etc 
>> -- are kept for someone having experience with Cocoa, with an 
>> ability to check results live on multi-display setup.
> 
> Then just leave the Mac driver patch out of the series.  The null 
> driver in user32 should probably contain the old implementation to 
> prevent regressions for drivers which don't implement the entry 
> point.  If your patches are accepted, I'll implement it for the Mac 
> driver.
> 
> 
>>>  It may be somewhat clunky, but has the advantage that it ensures 
>>> all three functions return mutually consistent results. Since you 
>>> appear to have dropped my patches which caused GetMonitorInfoW() to 
>>> return unique names for the displays, they are no longer consistent.
>> 
>>  I am probably missing something, but they supposed to be consistent 
>> (at least for winex11.drv)
> 
> Right, but it doesn't work that way in the Mac driver.  See my 
> original patch 
> <https://github.com/wine-compholio/wine-staging/blob/master/patches/gdi32-MultiMonitor/0004-winemac-Make-GetMonitorInfo-give-a-different-device-.patch>.
> 
>>>  because Alexandre wanted the tracking and management of displays 
>>> and display modes centralized in the explorer process[1].
>> 
>>  Not sure what was meant exactly here, but the patch making things 
>> work with certain respect to surrounding approach - looks to me as a 
>> small but good first step.
> 
> That's what I thought about my original patches.  We'll have to see 
> if Alexandre agrees. :)
> 
>>>  I have my reservations about that approach, mind you. ;)
>> 
>>  Could you please clarify this point, do you mean you are going to 
>> work all that out in the nearest future?
> 
> No.  I meant I have doubts that Alexandre's preferred approach will 
> be feasible on the Mac.  I was referring to my replies to Alexandre's 
> email that I linked to:
> https://www.winehq.org/pipermail/wine-devel/2014-March/103685.html
> https://www.winehq.org/pipermail/wine-devel/2014-March/103688.html
> 
> -Ken
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20170508/8ffd0f24/attachment.html>