Before this commit each WDF driver called VirtIOWdfSetDriverFeatures
from its PrepareHardware WDF callback. Many drivers do not have any
specific needs for features but needed to make this call in order
just to set VIRTIO_F_VERSION_1 and VIRTIO_F_ANY_LAYOUT properly.
So, even when the call VirtIOWdfSetDriverFeatures is optional in
general, it is mandatory to handle V1 devices.
Current commit moves ack for VIRTIO_F_VERSION_1 and VIRTIO_F_ANY_LAYOUT
features to WDF VirtIO library. If the driver does not call
VirtIOWdfSetDriverFeatures, these features are set properly at time of
queues' initialization. So, drivers need to make this call only if
they need to enable some type-spefific features or if they need to
disable some common features which WDF library handles automatically
(currently VIRTIO_F_VERSION_1, VIRTIO_F_ANY_LAYOUT).
Signed-off-by: Yuri Benditovich <[email protected]>
Allocate 2 blocks of 4K. One will be sliced for input events
(8 bytes each, i.e. 512 events, when the queue size is usually 64).
Another one for sporadic output of keyboard reports, 16 bytes
allocated for each.
Signed-off-by: Yuri Benditovich <[email protected]>
https://github.com/virtio-win/kvm-guest-drivers-windows/issues/413
When logical limits of an absolute device are not default (0..0x7fff),
the device, redirected over input-host, does not function at all
in Windows. Addition of physical limits definition makes it function.
Note that this does not solve completely the problem of touchpads
especially ones that report absolute coordinates like mice do:
they require more effort to function correctly.
Signed-off-by: Yuri Benditovich <[email protected]>
https://github.com/virtio-win/kvm-guest-drivers-windows/issues/385
High resultion mouse often provides values out of range (-127,+127).
Unfortunately the interface of vioinput does not provide any
information about logical limits of relative pointer.
So, let's keep the value inside the range.
Signed-off-by: Yuri Benditovich <[email protected]>
https://bugzilla.redhat.com/show_bug.cgi?id=1588425
The mentioned commit fixes the problem it was intended to fix
but contains 2 mistakes. The purpose of said commit was to allow
some relative non-XY axes (expecially REL_WHEEL) to be used with
absolute pointing devices (i.e. ABS_XY+REL_WHEEL).
Problem1: in case of combined device (ABS_XY+REL_XY+REL_WHEEL)
the change in the code causes absolute and relative axes to be
exposed in the same mouse device.
Windows HID stack rejects such devices, so the rule is to expose
absolute ABS_XY only if REL_XY are not present (as described in
commit 52e521d2e9). The mistake was in use of InputCfgDataHasBit
after DecodeNextBit on the same structure (DecodeNextBit clears
bits of interest in the bitmap and later InputCfgDataHasBit returns
unexpected result).
Problem2: for example in case of (REL_X+ABS_XY), the driver will
expose REL_X which is not planned (see also commit 52e521d2e9).
Current commit fixes both problems and still allows exposing
relative wheel with absolute axes.
Signed-off-by: Yuri Benditovich <[email protected]>
This commit is preparation for build with VS2017, which requires
WDK higher than 15063 to be installed.
When VS2015 and VS2017 coexist and VS2015 is used for drivers
build, but higher WDK(s) are also installed, the files under
"Windows Kits\10\build" are modified causing failure when build runs.
Current commit fixes it by importing Driver.Initial.props prior
to any other imported project. In order to ensure proper order of
importing projects, we remove direct importing of Visual studio
.props files and now each driver package project includes
only its own .props file and Tools\Driver.Common.props file,
which includes Visual Studio .props files and Driver.Initial.props
file in proper order.
Signed-off-by: Yuri Benditovich <[email protected]>
All relative axes including mouse wheels are ignored whenever REL_X and
REL_Y inputs are missing, such as for virtio-tablet-pci devices. This
patch restores support for all relative axes in tablet mode.
Signed-off-by: Justin Gatzen <[email protected]>
When vendor uses its own subvendor id, the resulting driver
package will not formally be compatible with devices of RedHat and other
vendors, because of hardware ID changing in the .inf file. Using
Compatible ID provides compatibility between drivers of different vendors.
If several versions of the driver packages were found during installation,
configuration manager will select a package with a exactly matching
Hardware ID, it is important especially when driver was obtained
automatically from Windows Update.
Signed-off-by: Ilya Rudakov <[email protected]>
Static analysis was failing with:
hidpassthrough\hidpassthrough.c(109): warning C28169: The dispatch function 'HidPassthroughDispatchIoctl' does not have any _Dispatch_type_ annotations: This can be corrected by adding appropriate _Dispatch_type_ annotations to the function. Unnecessary casts can cause this warning.
sys\device.c(271): warning C28170: The function 'VIOInputCreateChildPdo' has been declared to be in a paged segment, but neither PAGED_CODE nor PAGED_CODE_LOCKED was found: This warning is not emitted for functions that are __forceinline.
sys\driver.c(88): warning C28208: Function VIOInputEvtDriverContextCleanup was previously defined with a different parameter list at c:\kvm-guest-drivers-windows\vioinput\sys\driver.c(38). Some analysis tools will yield incorrect results.
sys\driver.c(91): warning C28118: The current function is permitted to run at an IRQ level above the maximum permitted for '__PREfastPagedCode' (1). Prior function calls or annotation are inconsistent with use of that function: The current function may need _IRQL_requires_max_, or it may be that the limit is set by some prior call. Maximum legal IRQL was last set to 2 at line 90.
sys\hidkeyboard.c(162): warning C28625: Function call used to clear sensitive data will be optimized away.
sys\keymap.c(660): warning C6385: Reading invalid data from 'ReportCodeToUsageCodeTable': the readable size is '2456' bytes, but 'uEventCode' bytes may be read.
Signed-off-by: Ladi Prosek <[email protected]>
The virtio-input driver has the same bug as virtio-serial, see
https://bugzilla.redhat.com/show_bug.cgi?id=1520352.
It's much harder to hit it with virtio-input because of its much lower
data rate and, to a smaller extend, also a smaller number of "receive"
buffers that can be pushed on the event queue (64 vs. 128 in virtio-
serial).
The fix here is simply to reset the device before touching the event
queue with virtqueue_detach_unused_buf() so it doesn't race with the
device processing it. With virtio 1.0, the reset is synchronous (the
driver waits for the reset to be acknowledged by the device) and
virtio-input is exposed as a virtio 1.0-only device.
Long-term it may be nicer to eliminate the virtqueue_detach_unused_buf()
API altogether and have the drivers track what's been pushed with a
simple linked list or similar.
Signed-off-by: Ladi Prosek <[email protected]>
It is important that all parties shipping virtio-win drivers use their
own vendor-specific HW ID to avoid driving somebody else's device.
This is especially critical for WHQL'ed drivers distributed with Windows
Update, as these could be installed without any explicit user action.
This commit introduces a new build-time variable SUBSYSTEM_VENDOR_ID
to be set by vendors in their respective Driver.$(_VENDOR_).props file.
The default value is 1AF4, exposed by VirtIO devices in upstream QEMU
and reserved by Red Hat.
Signed-off-by: Ladi Prosek <[email protected]>
Now that the build system has proven stable, the check header is
no longer needed. Also lowering the importance of "Adding {0}=>{1}"
messages produced by the SubstituteFileContent task to Low to cut
down on verbosity.
Signed-off-by: Ladi Prosek <[email protected]>
uPendingLedCode initial value is 0xFF, which means invalid code, and uShortPendingLedValue initial value is 0.
Using "uShortPendingLedValue != 0xFF" as condition to send kbd led status, it will send invalid code 0xFF and value 0 to backend.
Signed-off-by: xuxi0513 <[email protected]>
Signed-off-by: Yi Wang <[email protected]>
This commit contains fixes to the mouse HID report descriptor
building code to make the resulting descriptor compatible with
Windows.
* Axes, both relative and absolute, are exposed only if at
least X and Y are present.
* Absolute axes are exposed only if relative ones are not.
Windows does not seem to like the rel+abs combination.
* Unknown absolute axes are ignored. Previously they were
exposed as the catch-all HID_USAGE_GENERIC_SLIDER usage but
Windows does not seem to like it.
Signed-off-by: Ladi Prosek <[email protected]>
Before this commit the driver failed to load if it didn't create
a HID report descriptor for at least one device. The host evdev
device connected to the VM may be arbitrarily obscure and not being
able to drive it should not be an error condition.
In general, virtio-input is a best-effort driver. It ignores what
it doesn't understand, which includes ignoring everything if the
evdev device description doesn't make sense.
Signed-off-by: Ladi Prosek <[email protected]>
The INF verification test in Win10 HLK 1703 started treating some
of the verification warnings as errors:
Section [sourcedisksfiles] is defined multiple times.
Empty DDInstall section will not install any drivers.
This commit fixes it by merging [sourcedisksfiles] sections into
one and adding a [CopyFiles_Child] section.
Signed-off-by: Ladi Prosek <[email protected]>
According to documentation the va_end macro should be invoked before
the function returns whenever va_start has been invoked from that
function.
This commit fixes errors reported by cppcheck tool.
Error sample:
[kvm-guest-drivers-windows/Balloon/sys/utils.c:60]: (error) va_list 'list'
was opened but not closed by va_end().
Signed-off-by: Sameeh Jubran <[email protected]>
Defines a new CopyrightStrings property which is then used in
vendor specific files to compose copyright strings. This way
a new vendor FOO will define their copyright string policy in
Driver.FOO.props
foo.ver
etc.
without touching driver props files.
Keeping vendor specific properties in their separate files makes
introducing a new vendor a purely additive process, without the
need to edit existing files. The vendor may even keep their files
"downstream only" if they choose so.
Signed-off-by: Ladi Prosek <[email protected]>
this patch sets COPYRIGHT_STARTING_YEAR in all .props
Signed-off-by: Alexey V. Kostyushko <[email protected]>
Signed-off-by: Denis V. Lunev <[email protected]>
This patch removes all packone PostBuildEvent and stores packages in
Install directory as earlier.
Signed-off-by: Alexey V. Kostyushko <[email protected]>
Signed-off-by: Denis V. Lunev <[email protected]>
Driver.c - #includes vendor.check.h for logging
vioinput.inx - replace rhel vendor specific with INX_ that will be
substituted by tools
vioinput.rc - simplified and use common schema from tools
vioinput.props - enables features
vioinput.vcxproj - import props, import tools targets
same for hidpassthrough
Signed-off-by: Alexey V. Kostyushko <[email protected]>
Signed-off-by: Denis V. Lunev <[email protected]>
The canonical KMDF HID driver uses mshidkmdf.sys (or its equivalent
viohidkmdf.sys) as the FDO for the device and the actual KMDF driver
as its lower filter to work around PnP KMDF limitations. This works,
except for the case where the same device, in terms of USB or PCI or
any other bus location, may expose different HID collections every time
it's plugged in. Because the instance path of the HID PDO (like for
example "HID-compliant mouse") is constructed only from the instance
path of the parent - likely just by replacing the bus ID with "HID" -
the system will reuse pre-existing devnodes, even if the HID collection
and the report descriptor are completely different and a keyboard,
for example, should be created instead of a mouse.
It's not hard to run into this issue with the vioinput driver. E.g.
switching from
-device virtio-mouse-pci
to
-device virtio-keyboard-pci
for the same PCI slot will result in the system loading the mouse HID
driver and the keyboard not working.
This commit works around it by making the KMDF driver a bus driver
which enumerates one and only child PDO, functionally driven by
viohidkmdf.sys. IOCTL IRPs are forwarded from viohidkmdf to vioinput
and processed just like before. The key difference is that vioinput
now generates the instance ID of the child, thus having the ability
to alter the instance path depending on the shape of the input device.
Specifically, vioinput computes a simple hash out of the HID report
descriptor and uses it as the child instance ID.
The child device is hidden from Device Manager so as not to confuse
users. It's not meant to be manipulated except through its parent.
Signed-off-by: Ladi Prosek <[email protected]>
This commit makes the hidpassthrough project part of the build
and makes vioinput install and use it instead of mshidkmdf.sys.
The primary reason for building our own HID KMDF shim is the
requirement to certify vioinput on server core Windows where the
in-box component is missing. A nice side-effect is that the driver
may be built for older Windows as well, although that may not be
of much use.
When HidQueue's ExecutionLevel= WdfExecutionLevelPassive and WdfIoQueueRetrieveNextRequest is called in IRQL=
DISPATCH ,so WdfRequestForwardToIoQueue(in hid.c EvtIoDeviceControl)can not be called timely for inserting request to HIdQueue.
HW prepare/release may be called repeatedly, for example on
resource rebalancing. The uNumOfClasses device context field
was not being reset so the second invocation of HW release
attempted to touch already released input classes.
This fixes BZ #1388775.
The three environment variables were just defined to be equal to
_BUILD_MAJOR_VERSION_, _BUILD_MINOR_VERSION_, and _RHEL_RELEASE_VERSION_,
respectively, adding no value.
This commit removes them and replaces all occurrences with the source
variables as mentioned above.
This commit reworks the packOne.bat script into a post-build step
invoked from VS/MSBuild as opposed to something that needs to be
run after the build finishes. It is part of a longer-term plan to
have VS/MSBuild drive the build for better error propagation,
incremental build support, and more.
A couple of hard-coded paths are also removed from packOne.bat.
A few harmless errors are printed when building balloon,
vioserial, and vioinput. This commit fixes two issues:
* Win10 drivers don't ship with WDF coninstallers so
WdfCoInstaller*.dll should not be copied over to Install.
* The Install directory may be empty or not exist, which
is worth checking before running del on its content.
Some of the buildAll files were capable of building only
one selected target, some were not. The command line options
required to do that also varied (e.g. Vista vs. Wlh).
This commit makes all buildAll behave the same way. Run
without any arguments, the script will build the driver for
all targets. To build only one target, the script accepts
two arguments, OS version and platform. For example:
buildAll Wlh 32
buildAll Win10 64
It takes a specially crafted set of both compiler and linker
options to build a kernel mode driver for a downlevel platform
using the legacy DDK and Visual Studio 2015. The new common
props file is a good place for these options/props.
This commit eliminates 2012-defines.h which was being generated
during build. The required version macros are now defined in
Driver.Common.props included from the project.
It is hard to imagine a situation when seeing the queue name as
a string in the debugger would be of any particular use. There is
a simple and unique mapping from queue indices to queue names for
each virtio device.
This commit deletes the name field from queue data structures
along with all the supporting code.
This commit renames VirtIOIsFeatureEnabled, VirtIOFeatureEnable,
and VirtIOFeatureDisable to virtio_is_feature_enabled,
virtio_feature_enable, and virtio_feature_disable, respectively.
A few redundant implementations are eliminated as well to keep
the logic in one place.
There's no reason why some of the functionality should be declared
in a separate header that all drivers need to include. This commit
adds a few virtio_ wrappers to completely abstract away the config
callbacks.
Yuri Benditovich