[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.
Venkat
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