Udev monitor monitors the whole input subsystem, but not all devices
in the input subsystem have devnodes associated to them.
This MR makes the event processing ignore such devices.
All device handling assumes devices have devnodes, so here we just
simply ignore all devices which do not have one. They are irrelevant.
Previously, udev bus thread aborted when an event for a device without
a devnode was processed:
```
10111.330:0068:0084:trace:hid:process_monitor_event Received action "remove" for udev device (null)
10111.330:0068:0084:warn:hid:bus_main_thread L"UDEV" bus wait returned status 0xc0000005
```
Just plugging in and out a normal mouse was enough cause this.
This was because root input devices (which do not have devnodes) were
handled too and `find_device_from_devnode()` choked on NULL argument.
--
v4: winebus: change debugging class of an error case from WARN to ERR.
winebus: change debugging class of an error case from FIXME to ERR
winebus: group local variable declarations
https://gitlab.winehq.org/wine/wine/-/merge_requests/5385
--
v8: explorer: Restore display settings on process exit.
winex11.drv: Process RRNotify events in xrandr14_get_id.
user32/tests: Test that display settings are restored on process exit.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5060
With some intermediate refactoring to make the code simpler.
I believe the failures that happened previously were coming from how NtGdiDdDDIOpenAdapterFromLuid initialized desc->hAdapter in win32u while winex11 was then relying on it. I missed this detail before and it should be working fine now that the vulkan path is only used to retrieve the physical device.
--
v4: win32u: Move D3DKMT vulkan implementation out of winex11.
winex11: Introduce a new find_adapter_from_handle helper.
winex11: Introduce a new get_vulkan_physical_device helper.
winex11: Initialize D3DKMT vulkan instance only once.
win32u: Open adapters in NtGdiDdDDIEnumAdapters2 outside of the display devices lock.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5306
Tests failed. Apparently the AVI decoder is expected to enumerate formats that it doesn't actually support?
?_? and also ಠ_ಠ.
Well, that's not the first insane part of Windows I've seen. Apparently something calls pin_query_accept anyways, so that patch is unnecessary.
Also fixed 16bit BI_RGB in the iccvid patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5744#note_71576
> > If you wish to have me removed as maintainer of winegstreamer, please propose that directly, rather than abusing GitLab to get your patches committed.
>
> This is not an automated process and I don't think I'm abusing any mechanism here.
Well... unless I'm mistaken, it kind of is. The whole point of using Gitlab's reviewers feature is to have the software track things so that Alexandre doesn't have to. If he has to look at every patch to check if the right people have reviewed it then that point is defeated. If he's just looking for patches with no pending review [in areas that are known to have a maintainer] then removing a reviewer will make a patch effectively ready to commit. I can only assume this is why my patches to wined3d have been committed without Jan's approval when the bot flakes out and doesn't assign Jan as a reviewer.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5667#note_71571