touchpad works in legacy BIOS but not after uefi

[BenLunt]

Hi guys, I am actually on the other side here and am asking for help. :-)
(Sorry if my post seems like I am rambling on a bit. I have found if I write in a way that asks questions as well as giving statements, I find that I can usually answer my own questions)

A while back, a fellow reader contacted me and pointed out a few errors with my work. I have been using Bochs, Qemu, and VirtualBox for some time and have had quite a bit of success. However, with the contact (thank you ThatOSDev), I decided to purchase a, maybe not quite so recent, but recent enough expendable desktop and laptop to actually test my work.

Wouldn't you know it, I had quite a few bugs and errors that only manifested on real hardware. My ACPI had a bug that didn't let the desktop boot past the ACPI initialization. My xHCI currently has an issue on the laptop, but works in all emulators and other physical machines I have tested with.

Anyway, one of the issues I am having, the laptop, a Dell Latitude 7490, has a touchpad that my code doesn't seem to be receiving interrupts when "movement" is found on the touchpad.

Here is my understanding along with a few remarks:

• The touchpad, whether it is emulated via USB or not, should show up as a standard PS2 Mouse at bootup.
• I believe this particular touchpad is a AlpsAlpine touch pad and is IC2, not USB.
• I wrote some code a few years back that I thought I would try. Since it is/was written for real mode in a Legacy BIOS environment, I modified the laptop's setup to boot in Legacy mode and booted to FreeDOS via a USB thumb drive. The first time I tried the code, it didn't work. After a little trial and error, I found that the PS2 didn't like the KEY_CMD_TEST_MP command (0xA9). Once I "removed" that code, the code ran just as expected. I got interrupts and the touchpad operated just like a normal mouse. (Please note I am not using any BIOS services. It is all hardware)
• To this point, the touchpad works in the BIOS/UEFI setup, in a FreeDOS environment using the code in the last bullet, and in Win10 booted via UEFI. Therefore, it isn't a faulty touchpad.
• However, the exact same code, now in my project, booted via UEFI in a 64-bit environment, doesn't produce interrupts (before you assume my interrupt mechanism is at fault, please continue reading).
• All of the commands that are written are accepted, I get an ACK back from all of them.
• Depending on the sequence and/or addition/subtraction of certain commands, I can get one to two interrupts during initialization and nothing more.
• I checked my interrupt mechanism. Same results with Legacy PIC or the APIC/IOAPIC.
• Just for fun, I placed a KEY_CMD_EN_SECOND command (A8 = enable mouse port) in the interrupt routine and I get a single additional interrupt, which means as long as the command is in the IRQ, I receive back to back interrupts, but not because the mouse moved. I believe it is because of the A8 command triggering the interrupt. Anyway, this proves that my interrupt mechanism is working just fine.
• I checked to make sure that the machine didn't have PS2 Multiplexing capability, to make sure that wasn't in the way.
• I found a comment in the Linux source code that a RESET command (0xFF) is mandatory for certain Dell Latitude laptops, which is one of the first things I do. :-)
• Not that it really matters, but just as a point, my code works in Qemu and Bochs just fine, though it is an emulated mouse, not a touchpad.

Again, the touchpad works within the BIOS/UEFI setup, when booted to Win10 via UEFI, and when booted to FreeDOS via Legacy BIOS using the code linked above.

I tried many different combinations, down to the point of simply enabling IRQ 12, doing no PS2 initialization at all, hoping the UEFI had set the PS2 and all I had to do was accept interrupts. This didn't work either.

I am wondering if anyone has seen or had this or a similar issue? Again, the code I refer to works just fine in a Legacy BIOS FreeDOS environment, but the exact same code doesn't work in my UEFI 64-bit environment.

This tells me one of a few things:

• There is some SMM code that is probably disabling/manipulating the touchpad as I try to initialize it.
• The Legacy BIOS does or doesn't do something the that UEFI does or doesn't do.
• The UEFI has set the PS2 Mouse/Touchpad to an unknown state. However, shouldn't the reset command fix that?
• The UEFI might turn off PS2 emulation and doesn't turn it back on before ExitBootServices is called. However, all commands sent and bytes read are as expected, I just don't get any interrupts when "movement" is made.

I'll admit, there might be something my boot code is doing well before I get to the PS2 initialization. However, I have checked numerous times to see what it could be.

I am at a loss and am hoping that someone here has seen or have actually had similar issues and can shine some light on the subject. Maybe I am missing something simple and just can't seem to find it.

Anyway, thanks for reading this far. It has been quite a while since I have actually asked for help, so please understand I do appreciate all of those who regularly post replies to this forum.

Thank you,
Ben

[BenLunt]

After a lot of searching (a lot of searching) I think I might have found a solution.

The article explains almost exactly what I am experiencing as well as the exact Kaby Lake chipset I am experiencing it on.

It looks like I need to look at my ACPI code a bit more. (That would explain why my code works in Legacy BIOS mode and not in UEFI mode.)

I will post an update if I can get it fixed.

UPDATE: A superficial initialization of the 'OSYS' variable in my ACPI code and the touchpad now works as expected. Thank you Joshua Stein (the author of the article given above), I too, spent many hours trying to figure this out. Thank you.

UPDATE: After a little bit of tweaking my ACPI driver with the new information from Joshua's article, the xHCI issue I mentioned is behaving a little different, now not triggering IOAPIC interrupts (at least not the one I think it should), though MSI interrupts are just fine. Looks like it is time to overhaul my ACPI driver a bit.

Thanks,
Ben

- https://www.fysnet.net/osdesign_book_series.htm

[BenLunt]

Following up with this issue, I decided to have a look at uACPI. After a little work to get it to build with my project, it boots just fine, though the touchpad still has the exact same issue.

Since I did not see any place on the uACPI project page for discussions, only issues and pull requests, I thought I would post here inquiring to see if someone who has considerable knowledge of the uACPI project can help me out.

I have posted a trace log at https://www.fysnet.net/temp/trace_7490.txt.

The touchpad still has the same exact issue as discussed in the previous posts of this thread. However, if I add the following two lines to the source tree:

Code: Select all

//  namespace.c:  Line 20
static uacpi_namespace_node 
predefined_namespaces[UACPI_PREDEFINED_NAMESPACE_MAX + 1] = {
    [UACPI_PREDEFINED_NAMESPACE_ROOT] = MAKE_PREDEFINED('\\', 0, 0, 0),
    [UACPI_PREDEFINED_NAMESPACE_GPE] = MAKE_PREDEFINED('_', 'G', 'P', 'E'),
    [UACPI_PREDEFINED_NAMESPACE_PR] = MAKE_PREDEFINED('_', 'P', 'R', '_'),
    [UACPI_PREDEFINED_NAMESPACE_SB] = MAKE_PREDEFINED('_', 'S', 'B', '_'),
    [UACPI_PREDEFINED_NAMESPACE_SI] = MAKE_PREDEFINED('_', 'S', 'I', '_'),
    [UACPI_PREDEFINED_NAMESPACE_TZ] = MAKE_PREDEFINED('_', 'T', 'Z', '_'),
    [UACPI_PREDEFINED_NAMESPACE_GL] = MAKE_PREDEFINED('_', 'G', 'L', '_'),
    [UACPI_PREDEFINED_NAMESPACE_OS] = MAKE_PREDEFINED('_', 'O', 'S', '_'),
    [UACPI_PREDEFINED_NAMESPACE_OSI] = MAKE_PREDEFINED('_', 'O', 'S', 'I'),
    [UACPI_PREDEFINED_NAMESPACE_OSYS] = MAKE_PREDEFINED('O', 'S', 'Y', 'S'),  // <-------------------------
    [UACPI_PREDEFINED_NAMESPACE_REV] = MAKE_PREDEFINED('_', 'R', 'E', 'V'),
};

and

Code: Select all

//  namespace.h:  Line 16
typedef enum uacpi_predefined_namespace {
    UACPI_PREDEFINED_NAMESPACE_ROOT = 0,
    UACPI_PREDEFINED_NAMESPACE_GPE,
    UACPI_PREDEFINED_NAMESPACE_PR,
    UACPI_PREDEFINED_NAMESPACE_SB,
    UACPI_PREDEFINED_NAMESPACE_SI,
    UACPI_PREDEFINED_NAMESPACE_TZ,
    UACPI_PREDEFINED_NAMESPACE_GL,
    UACPI_PREDEFINED_NAMESPACE_OS,
    UACPI_PREDEFINED_NAMESPACE_OSI,
    UACPI_PREDEFINED_NAMESPACE_OSYS,  // <------------------------------
    UACPI_PREDEFINED_NAMESPACE_REV,
    UACPI_PREDEFINED_NAMESPACE_MAX = UACPI_PREDEFINED_NAMESPACE_REV,
} uacpi_predefined_namespace;

The touchpad now works as expected.

However, since I added this node, when the uACPI code reaches the actual 'OSYS' field in the DSDT, the uACPI system aborts any further parsing of the DSDT, therefore any remainder configuration is missed.

If you will look in my trace log, the line

Code: Select all

[uACPI][TRACE] detected PCI device PCI0 @ 0000:00:00:00

appears once, then the line

Code: Select all

[uACPI][TRACE] detected PCI device PXSX @ 0000:00:00:00

appears multiple times after. This is concerning to me. Shouldn't it find multiple PCI devices, not just the root, multiple times? I checked the code and the uAPCI code does find and reads the _ADR and _BBN fields, however, they are both returning zeros for each PCI device found. Notice also that each line states that the device is the PXSX device.

Please note I added a few extra trace lines that aren't included in uACPI, though these are just to help me figure this out.

If someone is familiar with and uses uACPI in their project and has a bootable image I can write to a USB drive, I am willing to boot that image on this laptop to see if the touchpad works or not via their code. Even better if their code can show the trace log as to allow me to compare to mine.

Thank you,
Ben
- https://www.fysnet.net/osdesign_book_series.htm

[marv7000]

You can open an issue here: https://github.com/uACPI/uACPI/issues
It would be nice to get an AML dump from the machine as well.