<div dir="ltr">Hi Aaron,<div><br></div><div>I spoke a bit too soon regarding the usage of EDK in my product.</div><div><br></div><div>Browsing the code repository of my product, I just discovered that EDK is already available :)</div><div><br></div><div>I am now actively investigating how I can incorporate the suggestions that you provided regarding EDK.</div><div><br></div><div>Thanks much,</div><div>Venkat </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 5, 2016 at 4:05 PM, Venkat Gorla <span dir="ltr"><<a href="mailto:venkatagorla@gmail.com" target="_blank">venkatagorla@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Aaron, for the detailed explanation. That was really helpful.<div><br></div><div>I am new to the UEFI world and still trying to get the hang of it.</div><div><br></div><div>It seems EDK and the console splitter absolute pointer abstraction that you described, is an open source development environment for the UEFI specification. Unfortunately we have some very tight restrictions in our company when it comes to using open source components in our shipping products. As such using EDK right now isn't a realistic option for me.</div><div><br></div><div>The idea itself is very interesting though; what is the best/ recommended way to get the handle for a device that supports the absolute pointer protocol? If there is something that can be done using just the UEFI specification, please let me know.</div><div><br></div><div>Btw, to get the array of handles for the absolute pointer protocol in my code, I am calling EFI API LocateHandle(). There is also a related API called LocateHandleBuffer(). The only difference between these functions seems to be whose responsibility it is to allocate space for the handle buffer array. Otherwise, functionally they seem to be the same.</div><div><br></div><div>Please let me know if there is reason to be using one function over the other.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Venkat </div></font></span><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 11:56 PM, <span dir="ltr"><<a href="mailto:Aaron.Pop@congatec.com" target="_blank">Aaron.Pop@congatec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font size="2" face="sans-serif">Hi Venkat,</font>
<br>
<br><font size="2" face="sans-serif">Your original question was "How
do I determine if I have a physical touch device attached to the system?".
Locating a handle buffer of absolute pointer protocols and going
through the handles to determine if any of them contain a device path will
answer that. </font>
<br>
<br><font size="2" face="sans-serif">If, however, you want to interact with
the absolute pointer devices, then you should only use the absolute pointer
protocol that does not have a device path.</font>
<br>
<br><font size="2" face="sans-serif">The console splitter, which I described
in the previous email, collects all absolute pointer devices under a single
abstracted absolute pointer protocol interface. It abstracts away
the information regarding the current settings of the screen. I'll give
you a case to help understand what I mean.</font>
<br>
<br><font size="2" face="sans-serif">Consider that you have two touch screen
devices attached to the system. The first is a digitizer that sit on top
of the monitor, and the second is a tablet like device (like a wacom tablet).
Each of these touch devices installs their own absolute pointer instance
with their own EFI_ABSOLUTE_POINTER_MODE interface descriptions. The
monitor touch screen device returns absoluteX and absoluteY information
that is not tied to the current video resolution (i.e absolutex is 800,
absolutey is 600, and the monitor is currently in 1920x1080 resolution).
If you attempt to use this data directly, then you will only be
able to access 800x600 of hte total 1920x1080 resolution. This same
limitation will be experienced with the wacom device. </font>
<br>
<br><font size="2" face="sans-serif">The console splitter's absolute pointer
protocol abstraction has information about the current video display resolution,
and it will perform a translation of the individual device's absolute pointer
information to map the information into the current display resolution.
For example, if the monitor's absolute pointer returns that the display
is at pixel 799x599, then that would be mapped by the console splitter
to approximately the 1919x1079 pixel.</font>
<br>
<br><font size="2" face="sans-serif">So to answer your second question, you
should not be enumerating handles when you want to use an absolute pointer.
You should be using the absolute pointer protocol from the console splitter,
which can be retrieved by opening the protocol on the gST->ConInHandle.</font>
<br>
<br><font size="2" face="sans-serif">As to why your individual device is
not working when you use the first handle in the handle buffer, I do not
know. It is probably something that you will have to investigate.
Are you sure that your device is conforming to the absolute pointer
protocol description in the EFI specification? Are there any assumptions
in your test code that conflict with the EFI specification? Is there
a bug in the EDK2 console splitter's absolute pointer abstraction (freely
available to view online at </font><a href="https://github.com/tianocore/edk2" target="_blank"><font size="2" face="sans-serif">https://github.com/tianocore/edk2</font></a><font size="2" face="sans-serif">
under MdeModulePkg/Universal/Console/ConSplitterDxe).</font>
<br>
<br>
<br>
<br>
<br>
<br><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">Venkat Gorla <<a href="mailto:venkatagorla@gmail.com" target="_blank">venkatagorla@gmail.com</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif"><a href="mailto:Aaron.Pop@congatec.com" target="_blank">Aaron.Pop@congatec.com</a>,
</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Cc:
</font><font size="1" face="sans-serif"><a href="mailto:fw_os_forum@mailman.uefi.org" target="_blank">fw_os_forum@mailman.uefi.org</a>,
<a href="mailto:fw_os_forum-bounces@mailman.uefi.org" target="_blank">fw_os_forum-bounces@mailman.uefi.org</a></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">03/04/2016 01:50 AM</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">Re: [Fw_Os_Forum]
How to detect devices that support touch</font>
<br>
<hr noshade><div><div>
<br>
<br>
<br><font size="3">Thanks Aaron. Now when I get the list of handles, I am
testing for the device path protocol in addition to the absolute pointer
protocol.</font>
<br>
<br><font size="3">By doing so, I am able to filter out the negative scenarios.</font>
<br>
<br><font size="3">I have another related question on this topic.</font>
<br>
<br><font size="3">On some of the touch hardware on which we are testing
our product changes, when enumerating the handles, if we select the first
handle that has both absolute pointer protocol and device path protocol,
it doesn't seem to function always -- touch events aren't being received.</font>
<br>
<br><font size="3">On the other hand, if we select the **last** handle that
has both protocols, it seems to work always.</font>
<br>
<br><font size="3">So is there something about this first handle vs last
handle that will explain this behavior?</font>
<br>
<br><font size="3">Venkat </font>
<br>
<br><font size="3">On Thu, Mar 3, 2016 at 11:38 PM, <</font><a href="mailto:Aaron.Pop@congatec.com" target="_blank"><font size="3" color="blue"><u>Aaron.Pop@congatec.com</u></font></a><font size="3">>
wrote:</font>
<br><font size="2" face="sans-serif">EDK implements a console splitter for
input device. This console splitter creates a absolute pointer protocol
instance that does not contain a device path.</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
You can locate a handle buffer of all the handles that contain an absolute
pointer protocol, and then you can go through the handles and make sure
that there is a handle that contains a device path. If there are
no absolute pointer instances that contain a device path.</font><font size="3">
<br>
<br>
<br>
<br>
<br>
</font><font size="1" color="#5f5f5f" face="sans-serif"><br>
From: </font><font size="1" face="sans-serif">Venkat
Gorla <</font><a href="mailto:venkatagorla@gmail.com" target="_blank"><font size="1" color="blue" face="sans-serif"><u>venkatagorla@gmail.com</u></font></a><font size="1" face="sans-serif">></font><font size="3">
</font><font size="1" color="#5f5f5f" face="sans-serif"><br>
To: </font><a href="mailto:fw_os_forum@mailman.uefi.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>fw_os_forum@mailman.uefi.org</u></font></a><font size="1" face="sans-serif">,
</font><font size="1" color="#5f5f5f" face="sans-serif"><br>
Date: </font><font size="1" face="sans-serif">03/03/2016
01:06 AM</font><font size="3"> </font><font size="1" color="#5f5f5f" face="sans-serif"><br>
Subject: </font><font size="1" face="sans-serif">[Fw_Os_Forum]
How to detect devices that support touch</font><font size="3"> </font><font size="1" color="#5f5f5f" face="sans-serif"><br>
Sent by: </font><a href="mailto:fw_os_forum-bounces@mailman.uefi.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>fw_os_forum-bounces@mailman.uefi.org</u></font></a><font size="3">
<br>
</font>
<hr noshade>
<br><font size="3"><br>
<br>
<br>
Hello, <br>
<br>
We are making some product changes that are specific to touch devices (such
as a tablet) in the Windows pre-boot UEFI environment. I am referring the
following document for the UEFI specification: </font><font size="3" color="blue"><u><br>
</u></font><a href="http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_3_1.pdf" target="_blank"><font size="2" color="#0060a0" face="Arial"><u>http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_3_1.pdf</u></font></a><font size="3">
<br>
<br>
However I haven't been able to definitively check for touch devices vs
non-touch devices using the specification. <br>
<br>
For example, querying for the absolute pointer protocol interface succeeds
even on a non-touch device such as a laptop or a desktop. Additionally,
the absolute max X and max Y values are also being reported as non-zero
when I query the "Mode" of the protocol interface. <br>
<br>
So my question is how do I filter out the negative scenarios (devices that
don't support touch) using the UEFI specification? <br>
<br>
Any pointers or help will is much appreciated. <br>
<br>
Thanks, </font>
<br><font size="3">Venkat </font><tt><font size="2">_______________________________________________<br>
Fw_os_forum mailing list</font></tt><tt><font size="2" color="blue"><u><br>
</u></font></tt><a href="mailto:Fw_os_forum@mailman.uefi.org" target="_blank"><tt><font size="2" color="blue"><u>Fw_os_forum@mailman.uefi.org</u></font></tt></a><font size="3" color="blue"><u><br>
</u></font><a href="http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum" target="_blank"><tt><font size="2" color="blue"><u>http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum</u></font></tt></a><font size="3">
</font>
<br>
<br></div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>