[Fw_Os_Forum] UEFI pre-boot issues with Microsoft surface pro 4

[Aaron.Pop at congatec.com]

Hi Venkat,

>>The UEFI specification (2.6) recommends using OpenProtocol in place on 
HandleProtocol. Does it really matter which one we use?
I don't think this matters for your preboot application.

>>Once we get the absolute pointer protocol interface handle, is there any 
guidance on when to call the Reset() function? 
If you are worried that the device was not initialized or if the device is 
not working as you would expect it to, you can call the reset function. 

>>- When calling GetState function on the protocol interface, how do you 
differentiate between finger touch/ press and release events?
I think you have some assumptions about how the 
EFI_ABSOLUTE_POINTER_PROTOCOL is supposed to work, and I think those 
assumptions are incorrect. In the simplest terms, the absolute pointer 
protocol is going to give you the current position of the pointer device. 
I don't believe that it was intended to provide information as involved as 
start of touch and end of touch, or anything else that is associated with 
multi touch device.  I think it would be easier if you though of the 
protocol as giving you a snapshot of the current position of the pointer, 
and the current status of the input buttons (if they exist).







From:   Venkat Gorla <venkatagorla at gmail.com>
To:     fw_os_forum at mailman.uefi.org
Date:   05/26/2016 12:15 AM
Subject:        [Fw_Os_Forum] UEFI pre-boot issues with Microsoft surface 
pro 4
Sent by:        fw_os_forum-bounces at mailman.uefi.org



Hi,

We are facing few issues with the absolute pointer protocol on Microsoft 
surface pro 4 in the UEFI pre-boot environment. So I am sending this email 
looking for some guidance/ recommendations on how to resolve them.

- In order to query the protocol interface handle we are currently calling 
HandleProtocol(). The UEFI specification (2.6) recommends using 
OpenProtocol in place on HandleProtocol. Does it really matter which one 
we use?
- Once we get the absolute pointer protocol interface handle, is there any 
guidance on when to call the Reset() function? We are seeing inconsistent 
behavior with the Reset function on different hardware models such as 
Microsoft surface pro 1 and pro 3.
- For example, on one model calling Reset is giving the desired behavior 
while on the other model, not calling it is working.

- When calling GetState function on the protocol interface, how do you 
differentiate between finger touch/ press and release events?
This is what we are currently doing in our code, pseudo code:

while (true)
{
    status = BS->WaitForEvent(<Array containing "WaitForInput" event of 
the protocol interface>);

    if (status is successful)
    {
        EFI_ABSOLUTE_POINTER_STATE PointerState;
        status = GetState(pAbsolutePointerProtocol, &PointerState);

        // Check return value of GetState and process the touch/ release 
event.
        if (PointerState.ActiveButtons & EFI_ABSP_TouchActive)
        {
            // This is the finger touch/ press event.
        }
        else if (PointerState.ActiveButtons & EFI_ABS_AltActive)
        {
            // We ignore this event.
        }
        else
        {
            // This is the finger release event.
        }
    }
}

- Our expectation is that every time you touch and release, we should be 
getting *two* events that get processed by our code.
- However on Microsoft surface pro 4, we are not always getting the touch 
and release events in pairs and that is throwing off our code.

- Looking at the pseudo code is there something that is missing that could 
be causing this behavior?
- Additionally are there any known touch related issues with surface pro 4 
and is there any specific guidance on how to resolve them?

Please let me know if you need any additional info to help answer my 
questions.

Thanks,
    Venkat
_______________________________________________
Fw_os_forum mailing list
Fw_os_forum at mailman.uefi.org
http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mailman.uefi.org/pipermail/fw_os_forum/attachments/20160526/3fc1c9ae/attachment.html>