Why does TOUCH not work like MOUSE events for disable?

[JonathanS]

The goal is to disable user INPUT on the SERVER SIDE when someone has connected remotely ...
- works great to disable keyboard/mouse
- works great to disable the screen (goes blank)
But for some strange reason if the screen is a TOUCH SCREEN enabled device (which most of our kiosks are) even if the INPUT is disabled and SCREEN is blank if the user PRESSES their input is still active and causes problems when we have remotely connected.

Is this a DEFECT in UltraVNC? Is there a separate option for TOUCH? Do I need to configure my TOUCH differently?

Any help, feedback, or suggestions would be greatly appreciated!
Thanks,

[Rudi De Vos]

Isn't this fixed in the 1.3.3 dev builds. ( Mar 25, 2021)
This code part is in de vnchook.dll, you can use the vnchook.dll from the latest dev build and test it with any release.

Touch generate injected mouse command, but vnc also inject mouse commands.
Some extra filter was added to block also non vnc injected mouse command.
Not tested, i don't have touch screen

[JonathanS]

This is fantastic news - we are for sure using a much older version (and mixed) - does this fix require us to upgrade both the CLIENT and SERVER or could we simply upgrade one of them to the latest (1.3.3)? Obviously best to upgrade both to be consistent (know that) but we added custom-code to the solution over the past decades so trying to reduce the risks.

[Rudi De Vos]

only vnchook.dll, this part is responsible for blocking local input.
It's compatible with the older version of vnc. make sure to copy the correct 32/64 version

[JonathanS]

We've attempted to simply drop-and-replace the VNCHook.dll with the one you recommended and it did not resolve the issue - we can still clearly see that TOUCH is enabled and responsive when the screen is black. Could there be some configuration or options we need to set to disable touch for example?

Here is our test environment:
- Edition Windows 10 Enterprise 2016 LTSB Version 1607
- VNC Server (v1.2.1.2)
- VNC Client (v1.2.1.2)
- Rebooted both stations after dropping the new VNCHook.dll

[Rudi De Vos]

I have been testing with a touchscreen and a touchpad, moves and clickes are blocked.
The hook block all MOUSEEVENTF_FROMTOUCH events.

But for that, the hook must be active

The only thing i can think of is that the hook fail, but then local mouse/keyboard would also not be blocked.

Sorry, but don't see anything i can change for it.

[JonathanS]

Our VNC Server configuration looks a bit different from yours - but here are the properties in the ultravnc.ini and it looks as if EnableHook (towards the bottom) is set to 1; if this was failing would there be a log/trace evidence we could check? Could it maybe be a side effect of the version we are using? But all of this is very odd that it only occurs with seemingly double-tap? Have you tried (on debug) to catch the event that is raised when you double-tap quickly and see what it corresponds to in UltraVNC?

[ultravnc]
passwd=
passwd2=
[Permissions]
[admin]
UseRegistry=0
MSLogonRequired=0
NewMSLogon=0
DebugMode=1
Avilog=0
path= C:\Program Files (x86)\UltraVNC
accept_reject_mesg=
DebugLevel=0
DisableTrayIcon=0
rdpmode=0
LoopbackOnly=0
UseDSMPlugin=0
AllowLoopback=1
AuthRequired=1
ConnectPriority=0
DSMPlugin=No Plugin Detected
AuthHosts=
DSMPluginConfig=
AllowShutdown=1
AllowProperties=1
AllowEditClients=1
FileTransferEnabled=1
FTUserImpersonation=1
BlankMonitorEnabled=0
BlankInputsOnly=0
DefaultScale=1
primary=1
secondary=1
SocketConnect=1
HTTPConnect=1
AutoPortSelect=1
PortNumber=5900
HTTPPortNumber=5800
IdleTimeout=0
IdleInputTimeout=0
RemoveWallpaper=0
RemoveAero=0
QuerySetting=2
QueryTimeout=10
QueryAccept=0
QueryIfNoLogon=1
InputsEnabled=1
LockSetting=0
LocalInputsDisabled=0
EnableJapInput=0
kickrdp=0
clearconsole=0
service_commandline=
FileTransferTimeout=1
KeepAliveInterval=0
RemoveEffects=0
RemoveFontSmoothing=0
[admin_auth]
group1=
group2=
group3=
locdom1=0
locdom2=0
locdom3=0
[poll]
TurboMode=1
PollUnderCursor=0
PollForeground=0
PollFullScreen=1
OnlyPollConsole=0
OnlyPollOnEvent=0
MaxCpu=40
EnableDriver=0
EnableHook=1
EnableVirtual=0
SingleWindow=0
SingleWindowName=

[Rudi De Vos]

This looks ok.

Perhpas....

VNC can use schook and vnchook, but keylocking is only implemented in vnchook

If that's the case rename or remove schook.dll, so vnc is forced to use vnchook

[JonathanS]

We attempted to rename/remove schook.dll and it did not change the touchscreen issue - so we did a bit of trial and error ...
- If we use 1.3.4 as-is your fix seems to work (mouse, keyboard, AND TOUCH are disabled)
- but if we take 1.2.1 and drop only VNCHook.dll (as recommended) we see the issue with TOUCH not working again

Is it possible there are more files then just VNCHook.dll which could be needed - or could there be some kind of compatibility issue?

[Rudi De Vos]

What if you drop the 1.2.1 winvnc.exe in the 1.3.4 folder ?

[JonathanS]

That actually seems to have worked - we are going to validate if this is a solution we can move forward with but there is a lot of risk in hat complete package replacement (as we have lots of custom code over the past decade in VNC Server/Client which is at risk with he approach of taking the .EXE only.

But it does means that VNCHook.dll is not the only dependency needed no? What other specific files could be required?

[Rudi De Vos]

Normal 2/3 file are needed
winvnc.exe
vnchook.dll :keyboard blocking + hint screen changes ( All OS)
ddengine.dll :capture screen changes ( win8 >=)

All other are optional and didn't changed for a long time.

[JonathanS]

We continue to struggle with this item and it has caused many issues where users are pressing on the screen (when it goes blank) thinking something s broken but really someone has simply taken remote control - and seeing as there is no way to SHOW a screen to the user (like DO NOT TOUCH) this has increasingly become an issue. From our last tests back in October'2021 we confirmed that the latest UltraVNC seems to work to disable touch (v1.3.4) but we cannot easily upgrade without risking all our customizations in v1.2.1 (this is what we have been trying for the past months).

In the last post @Rudi you indicates 3 files are normally needed - and the KEY there I believe is WinVNC.exe; simply adding vnchook.dll and ddengine.dll did not seem to do the trick.

In parallel to us trying to find a way to upgrade successfully to v1.3.4 (the last version we tested) I have some questions:
- Is it easy to identify the CODE in v1.3.4 which is used for managing TOUCH? If we can import just that part into v1.2.1 (if it is easily ported) then we could save a lot of problems; is this isolated somewhere which can be identified?
- Is there anything in v.1.3.5 or v.1.3.6 (latest versions) which could help in this area and might be worth investigating (we are still using v1.3.4)?

Much appreciated!

[Rudi De Vos]

The only real code change is in the vnchook.dll. This dll need to block the input.
There is no TOUCH code in winvnc.

it could that 1.2.1 use the hook functions different.
Don't look for Touch code, but how the vnchook functions are called.

[JonathanS]

Not being an expert in the area myself I've taken a quick look and not sure I fully understand what you mean - I've asked one of my partners to see if this clarifies a possible area of confusion - in parrallel I wanted to ask if you had an example to illustrate how the hooks could be different?

[Chris_L]

Issue found and addressed. The problem is in the 1.2.1 server code. The mouse hook is not activate\deactivate properly when client disable\enable server inputs

[Rudi De Vos]

Glad you found it.