[PATCH v4 3/6] winex11.drv: Store monitor information in the wineserver for EnumDisplayMonitors().

[Rémi Bernon]

On 5/31/21 1:12 PM, Zhiyi Zhang wrote:
> 
> 
> On 5/31/21 6:48 PM, Rémi Bernon wrote:
>> On 5/31/21 11:16 AM, Zhiyi Zhang wrote:
>>>
>>> On 5/22/21 1:25 AM, Rémi Bernon wrote:
>>>> Hi Zhiyi!
>>>>
>>>> I had a look, as I was working on the null graphics driver and as the monitor code is the only thing remaining for it to pass user32 tests.
>>>>
>>>>
>>>> IMHO this could at least be split (unless there's something I missed that makes it hard), with first the monitor info being sent to wineserver, then using it for enumeration and then to get monitor info in separate patches.
>>>
>>> Hi Rémi,
>>>
>>> Yes, I could split the patch that way. But it will then create a patch that does nothing with only the monitor information in the wineserver and they're not used anywhere.
>>> I was advised not to do create such patches before.
>>>
>>>>
>>>>
>>>> Then, I think duplicating the code between winex11.drv and winemac.drv is not great, and that it would be nice if this could be done in user32 instead.
>>>>
>>>> It would be a bit more work to refactor the driver interface first, but I think it would be a nice way to reduce code duplication, and it would then be much easier to expose fake monitors and modes as a default implementation, for the null graphics driver.
>>>>
>>>>
>>>> For instance, I think the driver interface should probably expose get_gpus / get_adapters / get_monitors callbacks.
>>>>
>>>> We could even maybe name them pEnumDisplayDevices / pEnumDisplayMonitors and keep it closer to their user32 entry point counterparts, and to make it more consistent with the other driver entry points.
>>>>
>>>> It may only be worth the trouble if we can return the information we need from the drivers in the related user32 structures, as otherwise we'll need custom struct anyway.
>>>
>>> I'm aware of the duplication for tje display device initialization code in winex11.drv and winemac.drv. I just don't think the refactoring is worth the trouble at this point. There is also
>>> of the question of whether it is appropriate to do display device enumeration in user32. I think you don't have to refactor the display device interface to refactor the null graphics driver.
>>>
>>
>> Okay, maybe I'm wrong, but as far as I could see, to report fake display devices, monitors and modes, I basically had to reproduce most of winex11.drv / winemac.drv code to user32, which feels even more of a waste.
>>
>> It may be possible to do it with less, I didn't spend much time on it.
> 
> It depends on how much you need to fake. If you just need to get some application to think there is a display, EnumDisplayDevices and EnumDisplayMonitors
> should be enough. In fact, wine already reports a fallback display device and a monitor in EnumDisplayDevices and EnumDisplayMonitors.
> 
I wanted at least to make user32 tests pass. The idea is to make it 
possible to test user32 behavior independently of graphics drivers, to 
determine more easily where an incorrect behavior comes from.

For instance, SetActiveWindow has bugs on the user32 side alone, but 
winex11.drv also adds another layer of problems, which makes it hard to 
debug it, test it consistently and fix properly.
-- 
Rémi Bernon <rbernon at codeweavers.com>