search

ms-iot / samples

Windows 10 IoT Core Samples
MIT License
1.2k stars 1.33k forks source link

Building HIDInjector for x64 gives error #522

Open hansmbakker opened 7 years ago

hansmbakker commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

hansmbakker commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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