I was reading up on the current Ubuntu daily builds yesterday, and I noticed that X86 support has officially been implemented into the current dev builds of Ubuntu touch.This opens up a WHOLE bunch of new opportunities. I got to tinkering with an X86 emulator, using a modified Nexus 7 android bootloader in place of the traditional BIOS. I was able to get Ubuntu Touch running (slow as molasses, and not without the odd graphical issue), it was all going great, until U-T tried initializing the battery and the radio. It all crashed after that, even corrupted the image I was using to do it. However, this proves that Ubuntu Touch is capable of running on X86 hardware.
Now I'm pretty good with virtual hardware, but I suck when it comes to actually trying anything out on real hardware. I have no idea how to port an android bootloader to specific devices, much less attempting to manipulate Ubuntu touch into running on the disgraceful 32-bit UEFI firmware that comes with the majority of Windows (baytrail) tablets.
we are working for a 22" touch panel and windows (newest drivers should be correctly installed).
There is a scene in which we orbit around an object with a camera (by swiping over the screen, or by click-dragging the mosue).
We want an event to be triggered on object click / touch, when we touch/click on the object. This is working fine with the mouse.
But when we try to trigger it with fingers on the touch panel, nothing happens. Then, when we swipe over the panel
to rotate the camera around the object, the event triggers. It does not matter, where we start to swipe (whether the finger is over the object or somewhere else). So the event is kind of delayed by one touch.
It seems like this issue is a focus problem. As if the actor (which has the click/touch events implemented) does not know, that he is focused yet. Only when we click into another area (which has no interaction/collision/implementation at all), the actor seems to know that he was clicked. By further clicking the actor, it lags one click behind.
Considering the 2) approach:
I Wrote a WPF c# application that is always on top and when it recognizes touch input (touch down/pressed/up) it tries to bring VMWare to foreground and send a mouse_event to that, but the mouse click is not registering. Also tried putting the application within VMWare, but stuff like System.Timers.timer and System.threading.Thread are not running.
I then searched what Kuka is. Perhaps the guest OS you have is 32-bit Windows 7 Embedded and it looks like not all Windows 7 Embedded supports touch. I am not familiar with Embedded editions of Windows with the exception perhaps unknowingly used one with an ATM or some customer kiosk. It looks like WES7P supports touch but not WES7E.
If the user needs to touch/tap not exactly on the VM buttons but somewhere near it, perhaps the Surface Pro has display scaling turned on (which usually is by default) and maybe the Windows 7 VM hasn't and as a result the two are disagreeing as to where the current touch/mouse pointer location should be. The having to click somewhere near but not exactly on a button/widget also occurs on Fusion VMs on the macOS platform or even those not involving VMs but Remote Desktop Protocol (RDP) terminal sessions.
Unfortunately, adding the line neither changes what is shown under computer properties nor the behavior.
Does it matter where in the file the line is placed? (also the device is a tablet, and some googling suggests that this only works for external usb touch inputs)
This doesn't happen only with my program, but even with simple explorer windows.
It definitely has to do something with how input is perceived in a win 7 VM.
I tried changing touch input behavior on the host system (win 10) but to be honest, this "teleporting-to-where-I-touch" window behavior only happens in VMWare and not on the host, so I doubt it's a feature.
The VM OS needs to have its own touch properties otherwise the touch that you make on the Surface Pro becomes more like a "grab" and translate to mouse movement. For example, without that line, a Windows 10 VM on Surface Pro would also show not having Pen and Touch capabilities and gestures like scroll, pinch, stretch are not recognised in the VM.
Yes, I powered it off / on , removed it, re-added the line, tried to change it's location.
After multiple tries It still displays "no pen or touch". I find it equally weird as you.
Anyway, here is my vmx file, in case you spot something off:
Yes, it is a windows 7 32 system and yes embedded version
I didn't notice and to be honest I had never seen embedded versions until now.
Could this potentially affect other stuff as well? (like sending input to the vm with commands like "mouse_event"? - I might have to open a new ticket for that-)