To get a uniform color gradient, fewer colors should be squeezed between
close key colors than between distant ones.
Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com>
---
There are two issues with the current pattern colors:
* We have lots of blue/green colors which are hard to distinguish.
* We have few colors in the yellow/red range despite those being easier
to distinguish.
This is in part because we don't take the space between key colors into
account, but mainly because interpolating in the RGB colorspace does not
yield good results.
So the goal of this patchset is to make it easier to distinguish the
pattern colors by fixing these two issues.
---
winetest/build-patterns | 35 ++++++++++++++++++++++++++++-------
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/winetest/build-patterns b/winetest/build-patterns
index 2ee5d5bdd..ff72516f6 100755
--- a/winetest/build-patterns
+++ b/winetest/build-patterns
@@ -872,6 +872,13 @@ sub blend($$$)
return $r;
}
+sub distance($$)
+{
+ my ($a, $b) = @_;
+ return sqrt(($b->[0] - $a->[0])**2 +
+ ($b->[1] - $a->[1])**2 +
+ ($b->[2] - $a->[2])**2);
+}
# Use colors to differentiate the set values. Each unique value is assigned
# a color (in HTML format) picked along a series of gradients passing by the
@@ -897,19 +904,33 @@ sub compute_set_colors($)
# when many colors are needed.
$keycolors[0] = [0, 179, 179] if ($count > 10);
+ # Compute the total length of the path traced by the key colors through
+ # the colorspace. This is necessary so the gradient remains uniform
+ # even if two key colors are close to each other. This does assume that
+ # the path does not zigzag too much: (0,0,0)->(255,0,0)->(1,0,0) cannot
+ # produce a meaningful gradient.
+ my @keypos = (0);
+ for (my $i = 1; $i < @keycolors; $i++)
+ {
+ my $d = distance($keycolors[$i - 1], $keycolors[$i]);
+ $keypos[$i] = $keypos[$i - 1] + $d;
+ }
+
my $k = 0;
- my ($start, $end) = (-1, 0);
for (0..$count-1)
{
- while (!$end or $_ > $end)
+ # Compute the position of the current item on the path
+ my $pos = $_ / ($count - 1) * $keypos[-1];
+
+ # Figure out which segment of the path this corresponds to
+ while ($pos > $keypos[$k+1] and $k+1 < @keycolors-1)
{
$k++;
- $start = $end;
- $end = ($count-1) * $k / (@keycolors-1);
}
- $set->{$values[$_]} = color2html(blend(($_-$start)/($end-$start),
- $keycolors[$k-1],
- $keycolors[$k]));
+
+ # And blend
+ my $Rgb = blend(($pos - $keypos[$k]) / ($keypos[$k+1] - $keypos[$k]), $keycolors[$k], $keycolors[$k+1]);
+ $set->{$values[$_]} = color2html($Rgb);
}
}
}
--
2.30.2
And match it in winehid.sys instead of individual bus ids.
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com>
---
v3: * Use memcpy whenever possible, fix the missing NULL terminators.
* Renamed everything. I kept the "gamepad" naming, as I think it'll
be eventually quite accurate. Later patches will use "xinput" for
the device to be used by xinput.
* Create new devices on a WINEXINPUT\ bus, instead of re-using the
underlying bus. This helps with the transitions from old devices
to new ones, as setupapi keeps a cache of compatible ids.
The internal device would use an "&XI_" suffix for hidclass.sys to
distinguish it from the "&IG_" one.
Otherwise we would have to change the patch ordering so that the
cache don't mess up the driver matching (the old &IG_00 device
would retain its COMP_XINPUT id, which would make winexinput
device match with itself recursively).
I'm just sending the first patches for now, but I also rewritten the
next ones to store what was "device_state" directly on the func_device,
initializing it on the fdo creation instead of the gamepad, as well as
to use a completion instead of a synchronous call to the lower driver.
dlls/winebus.sys/main.c | 22 ++++++++++++++++++++--
dlls/winehid.sys/winehid.inf | 7 +------
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c
index e9c85deb846..49385576d62 100644
--- a/dlls/winebus.sys/main.c
+++ b/dlls/winebus.sys/main.c
@@ -226,7 +226,7 @@ static WCHAR *get_device_id(DEVICE_OBJECT *device)
return dst;
}
-static WCHAR *get_compatible_ids(DEVICE_OBJECT *device)
+static WCHAR *get_hardware_ids(DEVICE_OBJECT *device)
{
struct device_extension *ext = (struct device_extension *)device->DeviceExtension;
WCHAR *dst;
@@ -240,6 +240,24 @@ static WCHAR *get_compatible_ids(DEVICE_OBJECT *device)
return dst;
}
+static WCHAR *get_compatible_ids(DEVICE_OBJECT *device)
+{
+ static const WCHAR hid_compat[] =
+ {
+ 'W','I','N','E','B','U','S','\\','W','I','N','E','_','C','O','M','P','_','H','I','D',0
+ };
+ DWORD size = sizeof(hid_compat);
+ WCHAR *dst;
+
+ if ((dst = ExAllocatePool(PagedPool, size + sizeof(WCHAR))))
+ {
+ memcpy(dst, hid_compat, sizeof(hid_compat));
+ dst[size / sizeof(WCHAR)] = 0;
+ }
+
+ return dst;
+}
+
static void remove_pending_irps(DEVICE_OBJECT *device)
{
struct device_extension *ext = device->DeviceExtension;
@@ -444,7 +462,7 @@ static NTSTATUS handle_IRP_MN_QUERY_ID(DEVICE_OBJECT *device, IRP *irp)
{
case BusQueryHardwareIDs:
TRACE("BusQueryHardwareIDs\n");
- irp->IoStatus.Information = (ULONG_PTR)get_compatible_ids(device);
+ irp->IoStatus.Information = (ULONG_PTR)get_hardware_ids(device);
break;
case BusQueryCompatibleIDs:
TRACE("BusQueryCompatibleIDs\n");
diff --git a/dlls/winehid.sys/winehid.inf b/dlls/winehid.sys/winehid.inf
index f9ed4091217..c1d8a1cf999 100644
--- a/dlls/winehid.sys/winehid.inf
+++ b/dlls/winehid.sys/winehid.inf
@@ -7,12 +7,7 @@ Class=HIDClass
Wine=mfg_section
[mfg_section]
-Wine hidraw device=device_section,HIDRAW
-Wine IOHID device=device_section,IOHID
-Wine libevent device=device_section,LNXEV
-Wine SDL HID device=device_section,SDLJOY
-Wine mouse device=device_section,WINEMOUSE
-Wine keyboard device=device_section,WINEKEYBOARD
+Wine HID compatible device=device_section,WINEBUS\WINE_COMP_HID
[device_section.Services]
AddService = winehid,0x2,svc_section
--
2.33.0
Eh, I probably missed something but something strange happened to this
patch. I see the message that it is committed, but I don't see it in the
list of new patches in #winehackers and also not in git.
On 8/31/21 23:40, Marvin wrote:
> Thank you for your contribution to Wine!
>
> This is an automated notification to let you know that your patch has
> been reviewed and its status set to "Committed".
>
> This means that your patch has been approved, and committed to the
> main git tree. Congratulations!
This can overflow the debug buffer. We could print each argument
on an individual line, but command-line arguments can be
obtained other ways and turned out to usually not be useful.
Signed-off-by: Esme Povirk <esme(a)codeweavers.com>
---
The argc trace is added so I don't get confused about whether
logs are from a verion of Wine that traces arguments or not.
The filename trace is kept because it's very convenient for the
+mscoree trace to show every managed PE image loaded in the process.
dlls/mscoree/corruntimehost.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/dlls/mscoree/corruntimehost.c b/dlls/mscoree/corruntimehost.c
index 51522c57d83..c4dfbe88b99 100644
--- a/dlls/mscoree/corruntimehost.c
+++ b/dlls/mscoree/corruntimehost.c
@@ -1449,10 +1449,7 @@ __int32 WINAPI _CorExeMain(void)
GetModuleFileNameW(NULL, filename, MAX_PATH);
- TRACE("%s", debugstr_w(filename));
- for (i=0; i<argc; i++)
- TRACE(" %s", debugstr_a(argv[i]));
- TRACE("\n");
+ TRACE("%s argc=%i\n", debugstr_w(filename), argc);
filenameA = WtoA(filename);
if (!filenameA)
--
2.30.2