Skip to content
This repository has been archived by the owner on Jan 30, 2019. It is now read-only.

Building HIDInjector for x64 gives error #522

Open
hansmbakker opened this issue Sep 2, 2017 · 10 comments
Open

Building HIDInjector for x64 gives error #522

hansmbakker opened this issue Sep 2, 2017 · 10 comments

Comments

@hansmbakker
Copy link

hansmbakker commented Sep 2, 2017

The HIDInjector sample cannot be built on x64.

Line 502 in HidInjectorKd.c gives an error because size_t is 64 bit on x64 and ULONG is 32 bit.

@FansteKaRiNa1998
Copy link

Did it work for you on x32? I am trying to make it work last 6 months, but it's like vhf isn't really making the changes with reportsubmit method. All this time I was testing a copy of the sample on x64

@hansmbakker
Copy link
Author

hansmbakker commented Sep 5, 2017

I didn't try it on Win IoT Core yet or on Win x32. For me it worked when I deployed it to a tablet running Win 10 x64 (build 16278). I had to use Visual Studio 2015+WDK 15063 since the Insider Preview WDK (16267) has a bug that makes it impossible to build drivers. As a quick hack I did a cast to ULONG but I think that's not the cleanest solution. Probably changing the ReportSize type would be better so that the cast can be avoided.

Since that tablet does not have a supported NIC I couldn't do kernel debugging there; and when I changed the code to my own HID descriptors it didn't work anymore.

@FansteKaRiNa1998
Copy link

Wait, did you say that when you decided to change the report descriptor (for example to gamepad, joystick, etc), it didn't work?

@hansmbakker
Copy link
Author

hansmbakker commented Sep 5, 2017

Exactly. The sample app + sample driver worked (at least the keyboard part, I didn't try the mouse or touch input); it injects something like Aa in the terminal.

But after I changed it to other HID descriptors (I wanted to emulate a surface dial using https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/radial-controller-sample-report-descriptors), it didn't work anymore. I verified that these HID descriptors do work, though, with an Arduino.

I couldn't debug it with my tablet so I don't know where it goes wrong yet. Hopefully I can debug it with an Intel NUC.

If you find out more, please let me know.

@FansteKaRiNa1998
Copy link

Thank you for the insight. Unfortunately, I don't have any more clues than you have. To be frank, this is the first time someone shares his experience with me about VHF HID. I commented on their official page, but nobody haven't replied to me yet. https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/virtual-hid-framework--vhf-
Maybe, if you comment on that section too, will wake up the developers and have a conclusion. I highly think this is an unfinished technology, possibly reasoned because it's very young (less than a year), but that should naturally justify their attention which is at the moment zero.

@hansmbakker
Copy link
Author

The odd thing is that the report descriptor is read properly (Windows shows the Wheel tab in the settings app) but the actual reports seem to be not delivered. When I know more I'll post it here, but let's discuss it in a new topic. This topic is for a request to make the code compile on x64.

@FansteKaRiNa1998
Copy link

FansteKaRiNa1998 commented Sep 5, 2017

Try copying the code to a new project, works for me. I have the exact same problem with delivering actual report.

When transfering a project to x64, additional dependencies are deleted. That's why you must add in the project properties -> linker -> input -> additional dependencies
next line: (DDK_LIB_PATH)vhfkm.lib

@hansmbakker
Copy link
Author

@FansteKaRiNa1998 please comment in #523, this topic is for a request to make the code compile on x64.

@ooeygui @Daniel-Walther @parameshbabu @serusako can you have a look at how the code should be properly changed for x64? C++ is not my "native" programming language.

HID_XFER_PACKET cannot be changed since it is part of hidclass.h, reportBufferLen is an ULONG there. EVT_WDF_IO_QUEUE_IO_WRITE (where the report length comes from) cannot be changed since it is part of wdfio.h. Is a simple cast good enough or should something else be taken into account?

@FansteKaRiNa1998
Copy link

After some time, there happen to be some strange bugs, for example, it deploys an old version although I clean and build or just click on rebuild. Another example is when targeting x64, it removes additional dependencies from the Linker -> Input section.
My safest bet is always to create an empty KMDF driver and put everything there. It always works for me, and it costs the least amount of time.

@FansteKaRiNa1998
Copy link

@Wind-rider A simple cast is good enough, I have verified it on x64.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants