Wasn't sure whether to post this in the linux or windows forum, but since I'm guessing this is an issue with the Grub bootloader itself, I figured I would post it here.
So basically, I decided to dual boot my windows 10 laptop with linux mint a while ago, and have been mainly been using it as a linux machine which has worked great, but it has recently come to my attention that the touchscreen is not detected by windows when I now boot into windows. Note that the touchscreen works perfectly fine when booting into linux, but when booting into windows, I can't even find any touchscreen device in Windows' device manager.
Touchscreen worked fine on windows before dual-booting, so at this point I am assuming that Grub is missing some sort of hand-off to allow windows access to the touchscreen.
I've already poked around in the bios for the laptop, and it is extremely bare-bones, and doesn't even give me a legacy/uefi boot option (it's forced UEFI only as far as I can tell).
What are some steps I can take to start looking into this issue to see what may be going on? Any other advice? It's all appreciated, thank you!
Note: Current GNU Grub version is: 2.02~beta2-36ubuntu3.8
It was worth a shot, but that didn't seem to fix my issue.
Uninstalled the device and driver from the Device Manager (even though it wasn't detected), rebooted and nothing. Also tried re-downloading and installing official drivers from Asus (my laptop vendor) website, but that didn't seem to fix the problem either. It's like windows doesn't even know the hardware is there.
I think the people in that thread were having driver issues upgrading to windows 10, but I already had my touchscreen working fine before installing Grub, and other than that the windows installation hasn't changed, so it must be something else.
I'm sticking with the idea that there must be some hand-off of some sort that isn't properly happening when booting into windows via the Grub bootloader.
Grub does not come between Windows and the hardware if Windows is installed on bare metal.
Grub is just a bootloader, nothing more, it has no hardware functionality at all.
The ideapad has a touch function that requires two hardware components, one of which is a serial device of some sort, probably I²C or the likes. The problem is probably there.
I would suggest removing Mint and live booting or installing Fedora. It has a modern kernel that knows this kind of hardware (unlike Mint), and it will allow you to see what is working and what not, simply by running dmesg after boot.
Since the touchscreen only stopped working after installing and dual booting with mint, I assumed the issue was with the boot loader, but clearly I'm mistaken. Thanks for the insight.
Error code 45 is simply a generic code indicating that the hardware isn't detected (i.e. not plugged in, etc).
So virtually every device with a driver installed could have an error 45. Unfortunately it doesn't shed too much light on the issue at hand, other than the fact that it tells me that windows does not see the hardware for some unknown reason.
Sometimes, there is a UEFI setting purporting to the touchscreen/touchpad, with the option to switch it to default mode and advanced mode or dual serial mode or something like that. It is basically the on/off switch for the I²C or D-BUS secondary serial interface to these devices. If you use these on linux, you want that on, but on Windows, it is often switched off on OEM pre-installed systems, with OEM drivers to go that compensate for the non-use of that serial connection. Windows then goes ahead and "updates" those drivers to WHQL drivers that don't have the same functionality, and often, the drivers for I²C or similar interfaces do not install automatically in Windows. So either you then find separate drivers (which is unlikely), or you do the same as you do with Intel drivers: you use the drivers supplied by the OEM and force-install those, then use Powershell to exclude those drivers from being updated by Windows. On linux, if you enable the secondary serial interface for all the multi-touch features in UEFI, the system will just recognize the interface automatically and configure it automatically, providing you have a modern enough kernel for the particular hardware.
Not entirely sure why that would have fixed the issue, or why installing grub would have caused that unchanged setting in the UEFI to start affecting windows to begin with, but the issue is fixed. Not entirely sure what host controller interface it's using now that xhci is disabled, but I suppose everything works.