Only save unthemed system metrics to the registry when the LoadedBefore
registry key value is '0'. This avoids saving themed system metrics
when two processes are trying to activate theming at the same time.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
So that temporary system metrics are not saved in the registry. Saving
them to the registry creates a race condition when two processes are
trying to activate theming at the same time, one process might save
themed system metrics instead of unthemed system metrics to the registry.
The race condition will be more apparent when initializing a wine prefix
after theming is turned on by default in wine.inf.
This patch refactors the system metric helper functions to use an
in-memory struct and is a prerequisite to remove the race condition.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We no longer enable or disable the event tap manually, and it re-enables
itself on kCGEventTapDisabledByTimeout, so this check is not needed.
Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
There's no analogous state on Windows, where an app is focused but has no
visible windows, but this seems like the best behavior.
Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Centralizes all clipping behavior into -startClippingCursor: and
-stopClippingCursor.
Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is done even if the emf contains a previous EMR_SETSTRETCHBLTMODE
record.
Thanks to Sebastián Aedo for some of the testing.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Esme Povirk <esme@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Despite what msdn states, I and I32 are supported width modifiers.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Piotr Caban <piotr@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Unlike most of the other wrc error functions, error() does not append a
trailing linefeed.
Signed-off-by: Francois Gouget <fgouget@free.fr>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
With a new internal poll callback for mouse and keyboard Wine-specific
message peeking behavior.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In a container with a non-trivial user namespace, we cannot rely on
libudev communicating with udevd as a way to monitor device nodes,
for the following reasons:
* If uid 0 from the host is not mapped to uid 0 in the container, libudev
cannot authenticate netlink messages from the host, because their sender
uid appears to be the overflowuid. Resolving this by mapping uid 0 into
the container is not allowed when creating user namespaces as an
unprivileged user, and even when running as a privileged user, it might
be desirable for the real uid 0 to not be mapped as a way to harden the
security boundary between container and host.
* Depending on the container configuration, initial enumeration might
not be able to read /run/udev from the host system. If it can't, sysfs
attributes will still work because those are read directly from the
kernel via sysfs, but udev properties coming from user-space rules
(in particular ID_INPUT_JOYSTICK and friends) will appear to be missing.
* The protocols between udevd and libudev (netlink messages for monitoring,
and /run/udev for initial enumeration) are considered to be private to
a particular version of udev, and are not a stable API; but in a
container, we cannot expect that our copy of libudev is at exactly the
same version as udevd on the host system.
Sidestep this by adding a code path that continues to use libudev for
the parts that work regardless of whether udevd is running or can be
communicated with.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As per https://github.com/systemd/systemd/blob/v247-rc1/NEWS#L5
there are more kernel uevent types than just "add" and "remove",
and we should be treating everything other than "remove" as being
potentially an "add".
To cope with this, try_add_device() now checks whether the same device
was already added. If so, we ignore it.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rémi Bernon