[Fw_Os_Forum] How to detect devices that support touch

Venkat Gorla venkatagorla at gmail.com
Tue Mar 8 04:40:35 EST 2016

Hi Aaron,

Thanks for your suggestions.

Using the UEFI shell, I listed all the handles in the database of my touch
device and the console splitter is listed in the output - along with the
absolute pointer protocol.

However when I call OpenProtocol using gST->ConsoleInHandle, I am
getting EFI_UNSUPPORTED error.


On Sat, Mar 5, 2016 at 4:50 PM, Venkat Gorla <venkatagorla at gmail.com> wrote:

> Hi Aaron,
> I spoke a bit too soon regarding the usage of EDK in my product.
> Browsing the code repository of my product, I just discovered that EDK is
> already available :)
> I am now actively investigating how I can incorporate  the suggestions
> that you provided regarding EDK.
> Thanks much,
> Venkat
> On Sat, Mar 5, 2016 at 4:05 PM, Venkat Gorla <venkatagorla at gmail.com>
> wrote:
>> Thanks Aaron, for the detailed explanation. That was really helpful.
>> I am new to the UEFI world and still trying to get the hang of it.
>> 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.
>> 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.
>> 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.
>> Please let me know if there is reason to be using one function over the
>> other.
>> Venkat
>> On Fri, Mar 4, 2016 at 11:56 PM, <Aaron.Pop at congatec.com> wrote:
>>> Hi Venkat,
>>> 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.
>>> 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.
>>> 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.
>>> 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.
>>> 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.
>>> 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.
>>> 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
>>> https://github.com/tianocore/edk2 under
>>> MdeModulePkg/Universal/Console/ConSplitterDxe).
>>> From:        Venkat Gorla <venkatagorla at gmail.com>
>>> To:        Aaron.Pop at congatec.com,
>>> Cc:        fw_os_forum at mailman.uefi.org,
>>> fw_os_forum-bounces at mailman.uefi.org
>>> Date:        03/04/2016 01:50 AM
>>> Subject:        Re: [Fw_Os_Forum] How to detect devices that support
>>> touch
>>> ------------------------------
>>> 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.
>>> By doing so, I am able to filter out the negative scenarios.
>>> I have another related question on this topic.
>>> 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.
>>> On the other hand, if we select the **last** handle that has both
>>> protocols, it seems to work always.
>>> So is there something about this first handle vs last handle that will
>>> explain this behavior?
>>> Venkat
>>> On Thu, Mar 3, 2016 at 11:38 PM, <*Aaron.Pop at congatec.com*
>>> <Aaron.Pop at congatec.com>> wrote:
>>> EDK implements a console splitter for input device.  This console
>>> splitter creates a absolute pointer protocol instance that does not contain
>>> a device path.
>>> 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.
>>> From:        Venkat Gorla <*venkatagorla at gmail.com*
>>> <venkatagorla at gmail.com>>
>>> To:        *fw_os_forum at mailman.uefi.org* <fw_os_forum at mailman.uefi.org>,
>>> Date:        03/03/2016 01:06 AM
>>> Subject:        [Fw_Os_Forum] How to detect devices that support touch
>>> Sent by:        *fw_os_forum-bounces at mailman.uefi.org*
>>> <fw_os_forum-bounces at mailman.uefi.org>
>>> ------------------------------
>>> Hello,
>>> 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:
>>> *http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_3_1.pdf*
>>> <http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_3_1.pdf>
>>> However I haven't been able to definitively check for touch devices vs
>>> non-touch devices using the specification.
>>> 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.
>>> So my question is how do I filter out the negative scenarios (devices
>>> that don't support touch) using the UEFI specification?
>>> Any pointers or help will is much appreciated.
>>> Thanks,
>>> Venkat _______________________________________________
>>> Fw_os_forum mailing list
>>> *Fw_os_forum at mailman.uefi.org* <Fw_os_forum at mailman.uefi.org>
>>> *http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum*
>>> <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/20160308/95d2b0f0/attachment.html>

More information about the Fw_os_forum mailing list