[Fw_Os_Forum] How to detect devices that support touch
Aaron.Pop at congatec.com
Aaron.Pop at congatec.com
Wed Mar 16 13:26:15 EDT 2016
Hi Venkat,
You are right, It appears that your BIOS's console splitter does not
contain a virtual absolute pointer device instance.
It also appears that your system has two absolute pointer device attached,
a usb based device and another (maybe an on screen software keyboard, or a
i2c device).
If you are trying to use the absolute pointer devices in your preboot
application, this means you have more work to do. You will have to
perform the mapping from the touch screen devices to overlay to the screen
resolution in the same way that the consplitter's abs pointer would have.
Best Personal Regards,
Aaron Pop
Senior Software Engineer
Phone: +1 858-457-2600 Ext. 705
Fax: +1 858-457-2602 | Email: Aaron.Pop at congatec.com
congatec, Inc. | 6262 Ferris Square | San Diego CA 92121 | USA |
www.congatec.us
Any e-mail sent from congatec may contain information which is
confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete
this e-mail and any copies from your systems.
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/15/2016 03:07 AM
Subject: Re: [Fw_Os_Forum] How to detect devices that support touch
Hi Aaron,
Yes, that is what I tried.
Below is a listing of all the handles and protocols supported on them, on
one of the touch devices that we are using for testing.
May be it will provide some additional insight into the issues we are
facing.
Thanks,
Venkat
Handles returned via LocateHandle specifying "absolute pointer protocol"
as the search criteria:
# Handles: 2
** Listing protocols for handle 0:
Protocols: 9
0xC7A7030C // Unknown
0x8D59D32B // Absolute pointer
0x31878C87 // Simple pointer
0x0ADFB62D // AMI_EFIKEYCODE_PROTOCOL_GUID
0xDD9E7534 // Simple text input ex protocol
0x387477C1 // Simple text input protocol
0x1FEDE521 // Unknown
0x09576E91 // Device path protocol
0x2B2F68D6 // USB IO protocol
** Listing protocols for handle 1:
Protocols: 2
0x09576E91 // Device path protocol
0x8D59D32B // Absolute pointer
** Listing protocols from ConsoleInHandle:
Protocols: 7
0x31878C87 // Simple pointer
0x0ADFB62D // AMI_EFIKEYCODE_PROTOCOL_GUID
0xDD9E7534 // Simple text input ex protocol
0x387477C1 // Simple text input protocol
0xF42F7782 // Console control protocol
0x387477C2 // Simple text out protocol
0xB295BD1C // Unknown
In this protocol listing, you can see that absolute pointer protocol isn't
listed on the console in handle which explains the "OpenProtocol" function
call failure.
On Wed, Mar 9, 2016 at 11:54 PM, <Aaron.Pop at congatec.com> wrote:
Hi Venkat,
It sounds like your OpenProtocol call is failing, because EFI_UNSUPPORTED
is returned when the protocol is not found on the device handle. Is your
open protocol formatted like the below snippet?
Status = gBS->OpenProtocol( gST->ConInHandle,
&gEfiAbsolutePointerProtocolGuid,
&AbsolutePointerProtocol,
gImageHandle,
NULL,
EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL);
Best Personal Regards,
Aaron Pop
Senior Software Engineer
Phone: +1 858-457-2600 Ext. 705
Fax: +1 858-457-2602 | Email: Aaron.Pop at congatec.com
congatec, Inc. | 6262 Ferris Square | San Diego CA 92121 | USA |
www.congatec.us
Any e-mail sent from congatec may contain information which is
confidential. If you are not the intended recipient, you may not
disclose, copy or use it; please notify the sender immediately and delete
this e-mail and any copies from your systems.
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/08/2016 01:41 AM
Subject: Re: [Fw_Os_Forum] How to detect devices that support touch
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> 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>
To: 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
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
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
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/20160316/acf84726/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3451 bytes
Desc: not available
URL: <http://lists.mailman.uefi.org/pipermail/fw_os_forum/attachments/20160316/acf84726/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3451 bytes
Desc: not available
URL: <http://lists.mailman.uefi.org/pipermail/fw_os_forum/attachments/20160316/acf84726/attachment-0003.gif>
More information about the Fw_os_forum
mailing list