I think it's not possible to implement it correctly using floating point operations when 24bit precision is used. We would either need to implement it without floating point operations (I'll look into that) or set the precision.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8242#note_106331
Wine applications crash in VNC/headless environments due to invalid all-zero monitor coordinates.
The root cause is:
- Environment Issue: VNC systems report all displays as RR_Disconnected
- Faulty Fallback: Wine incorrectly reverts to legacy XRandR 1.0 API when no "connected" displays are detected
- API Incompatibility: Modern XRandR 1.6 doesn't support Wine's XRandR 1.0 implementation, causing XRRSizes() to return empty display modes
- Uninitialized Data: This leaves critical display fields (dmPelsWidth/Height) at initialization value 0
--
v3: winex11: handle fallback display modes when XRandR fails
https://gitlab.winehq.org/wine/wine/-/merge_requests/8216
eric pouech (@epo) commented about programs/cmd/wcmdmain.c:
> * Otherwise, parse the buffer to find the last parameter in the buffer,
> * where tab was pressed.
> */
> - if (len && inputBuffer[len-1] == L' ') {
you should support the same parameters as below
likely you'd better have the {cc=len; } body when parameter_with_delims() fails
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8200#note_106328
eric pouech (@epo) commented about programs/cmd/wcmdmain.c:
> /* Handle paths here. Find last '\\'.
> * If '\\' isn't found then insert pos is the same as search pos.
> */
> - while (cc > sc->search_pos && inputBuffer[cc] != L'\\') {
ditto is there a reason to not handle the other delimiters here?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8200#note_106327
FileRenameInfoEx is already handled by NtSetInformationFile, SetFileInformationByHandle need only pass it through correctly.
As of version 5.3, Apple's Metal Developer Tools are dependent on SetFileInformationByHandle to handle FileRenameInfoEx in this fashion.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8293
Updating the GL drawables on/offscreen dynamically, similarly to how we do it for Vulkan, and in order to ultimately converge and factor both GL and VK client surfaces.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8291
OSmesa is deprecated and has been removed from latest mesa releases, this replaces it with pbuffer rendering and flushing of the surface onto the bitmap at some specific sync points. The tests show that this is roughly how Windows seem to behave anyway, instead of rendering directly to the memory as OSmesa does.
--
v5: win32u: Remove now unnecessary context and pbuffer funcs.
win32u: Drop now unnecessary OSMesa dependency.
win32u: Use a pbuffer to implement GL on memory DCs.
opengl32: Flush the contexts on gl(Draw|Read)Pixels and glViewport.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8210