Difficulty with Touchscreen on Samsung Galaxy Book 12 Tablet
An EFI boot manager utility
Status: Beta
Brought to you by:
srs5694
Menu
▾
▴
I'm trying to get the touchscreen on a Samsung Galaxy Book 12 tablet working in Refind, and unfortunately I'm having some difficulty. I've tried enabling both touch and mouse support (separately) in the refind.conf file, doublechecked my EFI drivers listing, and even tried a binary created last year for a person experiencing a similar difficulty ( https://sourceforge.net/p/refind/discussion/general/thread/e4a5b299/?limit=25 ), without much luck.
It's worth noting that, unlike in their case, the touchscreen is fully operational in this machine in the firmware settings, and in Windows 10's boot menu, so the hardware ~is~ active at boot time. And it's operating on an i²c bus (The hardware ID reads SYNP:1234 )
If it's of any interest, this is what my UEFI drivers listing looks like:
D Y C I
R P F A
V VERSION E G G #D #C DRIVER NAME IMAGE NAME
== ======== = = = == == =================================== ==========
50 00000013 D - - 1 - AMI USB Driver Uhcd
52 00000013 B - - 1 7 USB bus Uhcd
53 00000002 D - - 4 - USB Hid driver Uhcd
54 00000001 D - - 1 - USB Mass Storage driver Uhcd
73 00000001 D - - 2 - <null string=""> MouseDriver
79 00010000 ? - - - - AMI NTFS Driver NTFS
7B 00000001 B - - 1 1 AMI AHCI BUS Driver Ahci
80 00000001 ? - - - - AMI NVMe BUS Driver Nvme
BD 00000010 D - - 1 - Intel(R) PCH Serial ATA Controller SataController
CC 00000010 B - - 1 1 AMI Console Splitter Text Out Drive ConSplitter
CD 00000010 B - - 3 3 AMI Console Splitter Text In Driver ConSplitter
CE 00000010 B - - 1 1 AMI Console Splitter Pointer Driver ConSplitter
D1 00000010 D - - 1 - AMI Graphic Console Driver GraphicsConsole
D2 0000000A D - - 11 - Generic Disk I/O Driver DiskIoDxe
D3 0000000B B - - 3 8 Partition Driver(MBR/GPT/El Torito) PartitionDxe
D5 00000000 ? - - - - Touch Input Filter Driver TouchInputFilterDriver
D7 00000001 ? - - - - AMI IDE BUS Driver IdeBusSrc
D9 00A5010C B - - 1 22 <null string=""> PciBus
DB 00000010 D - - 1 - AMI PS/2 Driver Ps2Main
DC 0000000A ? - - - - HttpDxe HttpDxe
DD 0000000A ? - - - - HttpDxe HttpDxe
DE 00000000 ? - - - - DNS Network Service Driver DnsDxe
DF 00000000 ? - - - - DNS Network Service Driver DnsDxe
E1 0000000A D - - 3 - FAT File System Driver Fat
EB 00002036 ? - X - - Realtek UEFI UNDI Driver FvFile(3A190517-3D2C-46E8-A418-B921491EB009)
EC 00002016 ? - X - - Realtek USB UNDI Driver FvFile(4A226765-C78B-404F-AA6D-A2FD36CCDD0F)
133 00000010 B - - 1 1 AMI SDIO Driver SdioDriver
143 09000425 B - - 1 1 Intel(R) GOP Driver [9.0.1061] MemoryMapped(0x3,0x87873018,0x878830D8)
Please let me know if there's any other useful information I can provide.
It's surprising that the touchscreen works in the firmware settings but not rEFInd, but there may be other factors at play.
I'm not sure when I'll be able to, but I've been meaning to put together a touchscreen diagnostic tool. I'll let you know when I do, and maybe we can figure out what's happening.
The 0.11.2 sources show that the pointer (touchscreen) support is IFDEFed out for 32-bits.
This effectively eliminates pointer support for all our goofy 32-bit UEFIs (pronounced Goofie Ufie). This means if you downloaded the current SF binaries (as I did), the included refind_ia32.efi doesn't really have touchscreen support built into it.
@CJ:
Is this because there's an issue with the code performance/correctness under 32-bits?
@The Mighty Quinn:
The UEFI setup support for touchscreen is probably enough, but if you want confirmation of your tablet's ability to support touchscreening in the pre-boot EFI environment, check out the McAfee testing tool:
https://kc.mcafee.com/corporate/index?page=content&id=KB78050
The McAfee tool worked fine when I launched it from my 32-bit EFI shell (though it doesn't offer an exit-- I used Ctrl-Alt-Del and my tablet rebooted). Note that it wants to create a logfile automatically (so I sand-boxed mine in a small, extra FAT32 partition I made on my eMMC).
As for rEFInd, we can hope there will be a 0.11.3 release that addresses this issue, or take it on ourselves, I suppose.
FWIW
Just a quick follow-up... I built 0.11.2 myself, with one small change, and it works great.
The resulting refind_ia32.efi has the touchscreen fully supported, and appears "working as designed", at least, thus far.
Of course, my testing is preliminary, and the ramifications of the change are a huge unknown. All I've done is one boot-iteration, using the arrows to move through my choices, selecting the Info choice, backing out by touching the highlighted Return line, and then selecting one of my boot options. All of that worked as expected. But that's not much testing...
Still, so far so good.
The change is to the pointer.c source file, just a simple search & replacement of the EFI32 macro with a new macro NOEFI32 (changing the semantics). Since this new macro is not defined anywhere, the file is compiled just like its x64 cousin. A real revision/patch would/should probably just remove all of those blocking macros.
Unless...
That code has been ifdef'ed out as far back as I've looked (the past three releases), so there must be some reason Rod/CJ bracketed and disabled it.
I looked for tickets but there don't seem to be any.
In any case... rEFInd does indeed have support for touch, you just have to build it yourself.
Aha, I hadn't considered that it might be 32-bit.
When initially working on this, Rod pointed out that he's had issues in the past that seem to be related to dividing 64-bit integers on a 32-bit machine. They would compile correctly with GNU-EFI, but crash or otherwise misbehave upon execution. They wouldn't compile at all with TianoCore. The protocols for pointing devices use UINT64 and I need to divide them, so this is a problem.
Casting them to UINT32 could work for some systems, but certainly not all. On my SP4 the coordinates returned are often far beyond what 32 bits can hold.
In an effort to make it compile correctly for multiple architectures, I have used UINTN everywhere even though I know it should be UINT64, and used those macros to ensure that only 64-bit machines can use this feature.
The biggest issues here are that I don't know of a good solution that will work for all systems, and I have no testing capability for 32-bit support.
It is curious that it works for you.
Good news! I think I have found a solution for IA32 builds (though only with EDK2, not GNU-EFI). Try this build, and if it works I'll submit a merge request.
I just did a quick smoke test of your build, and it worked for me.
And, as a bonus, your EDK2 build consumes 38k less than my quick & dirty build from yesterday (GNU-EFI: I see that Rod says that the gnu-efi build is fatter, now I know what he means).
I've been testing on an Acer Iconia Tab 8W (which is a Bay Trail chipset).
I have another tablet with 32-bit firmware (a Toshiba Encore Mini, also Bay Trail), and I will test on it too, when I get the chance-- but I expect it will behave the same (we'll see).
My ESPs are cluttered with many experimental loaders/efi-apps, so rEFInd gives me a lot of choices to scroll through (I'm touching the blue triangles a lot).
Here's what I did in my smoke test-
Booted my tablet to a USB stick-
1) Grub, first, with my hand-coded entries newly-edited with your build as a choice.
2) Refind, experimental-- three minutes of finger-dancing around my long list.
3) Shell (EDK2). A few minutes of work there, then, cd into my /EFI/refind dir, and
4) launch Refind experimental again -> give Windows 10 the finger (boot an OS)...
Everything appears to work.
Thank you-- I don't know what happened to the OP, but I appreciate your quick response.
Oops... yeah, well, the Toshiba crashed, so you may want to hold off on that merge...
I'll give some more time to this at a later date. But for now, here's an outline of the differences between my two 32-bit tablets.
The crashing Toshiba Encore Mini has a screen size of 1024x600, and defaults to landscape mode (from the firmware Setup screen through Windows loading its sensor drivers).
The successful Acer Iconia is 1280x800, defaults to portrait.
Refind displays properly on both.
I invoked the Toshiba crash (booting from the same USB stick as an hour ago with the Acer) by poking at the right blue triangle (which is pretty much what I did with the Acer).
There was no immediate response, so I poked it a few more times, until I poked a hole in it (spontaneous reboot).
I'll be comparing the ACPI tables and guids for both, and examining the firmware differences, and maybe run that McAfee test tool, and I'll get back to you.
Okay, here's a quick report on a difference I found immediately:
With the Acer, the Absolute Pointer appears in the device tree (devtree from the EFI shell) and in the list returned by devices.
With the Toshiba, those entries are absent. The Toshiba publishes the proper guids, but those guids are lies!
Here, by way of illustration, is my Notepad++ search result (through my text captures of EFI shell sessions on each tablet):
Search "Pointer" (11 hits in 6 files) J:\PE\EFI\Notes\Acer\dmpstore.txt (2 hits) Line 1513: Variable BS 'ShellProtId:SimplePointer' DataSize = 10 Line 1515: Variable BS 'ShellProtId:AbsolutePointer' DataSize = 10 J:\PE\EFI\Notes\Acer\efidevs.txt (1 hit) Line 7: 117 D - - 2 - - Primary Absolute Pointer Device J:\PE\EFI\Notes\Acer\efidtree.txt (2 hits) Line 18: Ctrl[117] Primary Absolute Pointer Device Line 37: Ctrl[117] Primary Absolute Pointer Device J:\PE\EFI\Notes\Acer\efiguids.txt (2 hits) Line 23: SimplePointer : 31878C87-0B75-11D5-9A4F-0090273FC14D Line 24: AbsolutePointer : 8D59D32B-C655-4AE9-9B15-F25904992A43 J:\PE\EFI\Notes\Toshiba\dmpstore.txt (2 hits) Line 1651: Variable BS 'ShellProtId:SimplePointer' DataSize = 10 Line 1653: Variable BS 'ShellProtId:AbsolutePointer' DataSize = 10 J:\PE\EFI\Notes\Toshiba\guid.txt (2 hits) Line 23: SimplePointer : 31878C87-0B75-11D5-9A4F-0090273FC14D Line 24: AbsolutePointer : 8D59D32B-C655-4AE9-9B15-F25904992A43Note from the Acer file, the proper presence of Primary Absolute Pointer Device in the referenced efidevs.txt (output of the devices command) and in efidtree.txt-- the corresponding Toshiba captures lack these entries...
Just goes to show, some of dem OEMs just didn't get it right...
Regards
One last bit o good news to go to sleep on... the McAfee touch test tool also failed on the Toshiba.
That is to say, it displayed properly, but did not respond to touch. This is in sharp contrast to the tool's performance on the Acer, where it was accurate and responsive. It did not crash, but also did not recognize any touch, and I had to three-finger-salute to boot.
So, I surmise from this that the Toshiba, despite supporting touch in the (meager) firmware setup, and despite its publication of the Pointer guids, is not properly configured to supply that device driver to the boot services environment.
FWIW
Afterthought-
Refind might not have crashed, but simply timed-out, while I was pokin-n-hopin...
This is all excellent information to have, thanks!
If it's not crashing, I believe this is good enough to go ahead and submit. Worst case: it doesn't work for a few people, but works for most (which is still better than none).
As the mouse and touch support is disabled by default, I would accept an MR that might fail on some systems.
Looks like I made it just in time for 0.11.3!
For clarity: the pointer support for 32-bit systems is now equivalent to 64-bit (i.e. as long as the firmware supports it, it should work).
As usual, thanks Rod!