[Fw_Os_Forum] How to detect devices that support touch

Venkat Gorla venkatagorla at gmail.com
Sat Mar 5 06:20:27 EST 2016 

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/20160305/af909bbc/attachment.html>

More information about the Fw_os_forum mailing list