From venkatagorla at gmail.com Tue Mar 8 04:40:35 2016 From: venkatagorla at gmail.com (Venkat Gorla) Date: Tue, 8 Mar 2016 15:10:35 +0530 Subject: [Fw_Os_Forum] How to detect devices that support touch In-Reply-To: References: Message-ID: 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 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 > 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, 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 >>> 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: