Bug 198715

Link to the wacom-hid-descriptors bug report, for reference: https://github.com/linuxwacom/wacom-hid-descriptors/issues/12

This appears to be related - same machine (HP Envy x360 with Ryzen):

[    7.650876] i2c_designware AMDI0010:00: ACPI slave is not supported yet
[    7.650913] i2c_designware AMDI0010:00: Standard-mode HCNT:LCNT = 642:749
[    7.650919] i2c_designware AMDI0010:00: Fast-mode HCNT:LCNT = 132:239
[    7.651103] i2c-dev: adapter [Synopsys DesignWare I2C adapter] registered as minor 5
[    7.651111] i2c i2c-5: adapter [Synopsys DesignWare I2C adapter] registered
[    7.651711] i2c i2c-5: client [ELAN0732:00] registered with bus id i2c-ELAN0732:00
[    7.677151] i2c_designware AMDI0010:00: Standard-mode HCNT:LCNT = 642:749
[    7.677157] i2c_designware AMDI0010:00: Fast-mode HCNT:LCNT = 132:239

I just tried kernel 4.16rc1
Touchscreen is still not operating. output very similar to 4.15 will attach another dmesg

(In reply to g.fitch from comment #2)
> This appears to be related - same machine (HP Envy x360 with Ryzen):
> 
> [    7.650876] i2c_designware AMDI0010:00: ACPI slave is not supported yet
> [    7.650913] i2c_designware AMDI0010:00: Standard-mode HCNT:LCNT = 642:749
> [    7.650919] i2c_designware AMDI0010:00: Fast-mode HCNT:LCNT = 132:239
> [    7.651103] i2c-dev: adapter [Synopsys DesignWare I2C adapter] registered
> as minor 5
> [    7.651111] i2c i2c-5: adapter [Synopsys DesignWare I2C adapter]
> registered
> [    7.651711] i2c i2c-5: client [ELAN0732:00] registered with bus id
> i2c-ELAN0732:00
> [    7.677151] i2c_designware AMDI0010:00: Standard-mode HCNT:LCNT = 642:749
> [    7.677157] i2c_designware AMDI0010:00: Fast-mode HCNT:LCNT = 132:239

Which kernel are you using? I dont even get this output.

Created attachment 274145 [details]
DMESG on 4.16rc1

I believe this problem to be related to the thread located here:
https://www.spinics.net/lists/linux-input/msg50784.html

I will attach disassembled ACPI tables in case they prove to be useful.

Created attachment 274147 [details]
Disassembled ACPI table for HP Envy x360 15z (ryzen 5 2500u)

(In reply to Aidan Hahn from comment #3)

> Which kernel are you using? I dont even get this output.

4.15-drm-next (fixes a nasty problem with 3 out of 5 boots locking up - still get irritating lock-ups when using X, and especially anything opengl). 

I turned on i2c debugging to see the status messages that the i2c-hid, elants_i2c etc. modules should be printing if they find the device but have some other communications problem. 

I'm new to this, so not sure what I'm looking at, but I think the touchscreen only identifies itself through ACPI, as an i2c slave at its own address, and drivers/i2c/i2c-core-slave.c can't enumerate that yet. So the device node doesn't get created, and the hid drivers have nothing to connect to.

I could be completely wrong, though - I'm good at being wrong :)

(In reply to g.fitch from comment #7)
> (In reply to Aidan Hahn from comment #3)
> 
> > Which kernel are you using? I dont even get this output.
> 
> 4.15-drm-next (fixes a nasty problem with 3 out of 5 boots locking up -
> still get irritating lock-ups when using X, and especially anything opengl). 
> 
> I turned on i2c debugging to see the status messages that the i2c-hid,
> elants_i2c etc. modules should be printing if they find the device but have
> some other communications problem. 
> 
> I'm new to this, so not sure what I'm looking at, but I think the
> touchscreen only identifies itself through ACPI, as an i2c slave at its own
> address, and drivers/i2c/i2c-core-slave.c can't enumerate that yet. So the
> device node doesn't get created, and the hid drivers have nothing to connect
> to.
> 
> I could be completely wrong, though - I'm good at being wrong :)

What model number are you running? I am using a 15-bq100.

Not sure what more information I should provide,
If there is more information needed to troubleshoot this issue please let me know.

Updated kernel to 4.16 (drm-next) and upon compile turned on some i2c debugging features. Now when I boot I recieve the following:

[    0.187816] i2c i2c-0: client [ELAN0732:00] registered with bus id i2c-ELAN0732:00
[    1.301023] acpi ELAN0732:00: GPIO: looking up 0 in _CRS

(the second entry is repeated ad nauseum)

libwacom-list-local-devices still cannot see this device.
I have attached my new DMESG which still has the ACPI Errors, among some additional interesting output from the i2c subsystem.

Am I missing something? Have I sent this bug to the right place?

Created attachment 274773 [details]
DMESG output after boot on 4.16 (drm-next)

I recently bought the same laptop and tried to look deeper into the problem.
I'm not a kernel developer or have any knowledge in kernel subsystems but what I found so far is that the AMD GPIO driver doesn't support ACPI for x86 platforms.(Kernel 4.16)
On HP Envy x360(Ryzen) the GPIO device is detected as ACPI device with an interrupt resource.

The driver calls for this case the function acpi_get_irq which is only defined on ARM64. On other platforms it returns a hardcoded -EIVAL (error -22).
I tried to hack a workround and used acpi_dev_resource_interrupt to get the IRQ from ACPI. The driver prints some warnings but the probe was successful.
The next problem is the i2c device itself.
The i2c-hid module fails to reset the device(error -61).
As dirty hack I deleted the timeout error, just to create a hidraw device by hid-multitouch but it doesn't report any input(it's detected as HID Input device).

It's possible:
- That there is still something missing in the AMD GPIO driver(especially at the gpio interrupts)
- My hack with the ACPI IRQ is completly crap
- The i2c device needs some magic bits or something to start working
I saw threads and bug reports in the internet with this touchscreen device but there was never a solution for the -61 error.

Of course there are more posibilities but that are the things I found out so far.
Pls tell me if some more info or debug is required.

Created attachment 275377 [details]
dmesg output from kernel 4.16(with hacks)

dmesg output from kernel with hacks included (the beginning is missing, maybe a limit of busybox but the relevant output is visible)

Created attachment 275381 [details]
possible fix for touchscreen

I think I found the problem.
There are 2 ACPI-related bugs which prevents the detection of the touchscreen.

1. As already mentioned, the AMD GPIO driver tries to get an IRQ for GPIO but the ACPI code is missing for x86.
2. The IRQ of the GPIO device is misconfigured. For some reason it sets the IRQ "edge, high" but in the ACPI table it's defined as "level, low".

I made a fix but it's only a temporary workround until someone who have more knowledge of the subsystems can implement it cleaner.
Could someone try this patch on a desktop enviroment? I just tested the output of hidraw which worked.

Hi Lukas,

I tested it with KDE 5 (17.12.3) with one of the drm-next kernels:
Linux tau-ceti 4.16.0-rc7-gc5902206599d-dirty #4 SMP PREEMPT Sun Apr 15 17:37:13 BST 2018 x86_64 AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx AuthenticAMD GNU/Linux


Your patch works fine for the touchscreen on this laptop - touchscreen is detectable and usable with both finger and the supplied pen.  

The relevant bit of dmesg is:

Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: ACPI slave is not supported yet
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: Standard-mode HCNT:LCNT = 642:749
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: Fast-mode HCNT:LCNT = 132:239
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: GPIO lookup for consumer scl
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: using ACPI for GPIO lookup
Apr 15 17:47:11 tau-ceti kernel: acpi AMDI0010:00: GPIO: looking up scl-gpios
Apr 15 17:47:11 tau-ceti kernel: acpi AMDI0010:00: GPIO: looking up scl-gpio
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: using lookup tables for GPIO lookup
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: lookup for GPIO scl failed
Apr 15 17:47:11 tau-ceti kernel: i2c-dev: adapter [Synopsys DesignWare I2C adapter] registered as minor 5
Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: adapter [Synopsys DesignWare I2C adapter] registered
Apr 15 17:47:11 tau-ceti kernel: acpi ELAN0732:00: GPIO: looking up 0 in _CRS
Apr 15 17:47:11 tau-ceti kernel: gpio gpiochip0: Persistence not supported for GPIO 89
Apr 15 17:47:11 tau-ceti kernel: i2c_hid i2c-ELAN0732:00: probe
Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: master_xfer[0] W, addr=0x10, len=2
Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: master_xfer[1] R, addr=0x10, len=30
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: i2c_dw_xfer: msgs: 2
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: enabled=0x1 stat=0x10
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: enabled=0x1 stat=0x504
Apr 15 17:47:11 tau-ceti last message repeated 9 times



The patch creates one issue, which is that the following warning now pops up at boot:

The battery in your keyboard ("ELAN0732:00 04F3:2537") is low, and the device may turn itself off at any time. Please replace or charge the battery as soon as possible. 

However all other peripherals and buttons work fine, so it's a minor nuisance.

Thank you for getting us this far!

Created attachment 275385 [details]
config for working system

4.16.0-rc7-gc5902206599d built against sources from git://people.freedesktop.org/~agd5f/linux --branch drm-next-4.18-wip

(In reply to g.fitch from comment #15)
> Hi Lukas,
> 
> I tested it with KDE 5 (17.12.3) with one of the drm-next kernels:
> Linux tau-ceti 4.16.0-rc7-gc5902206599d-dirty #4 SMP PREEMPT Sun Apr 15
> 17:37:13 BST 2018 x86_64 AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx
> AuthenticAMD GNU/Linux
> 
> 
> Your patch works fine for the touchscreen on this laptop - touchscreen is
> detectable and usable with both finger and the supplied pen.  
> 
> The relevant bit of dmesg is:
> 
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: ACPI slave is
> not supported yet
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: Standard-mode
> HCNT:LCNT = 642:749
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: Fast-mode
> HCNT:LCNT = 132:239
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: GPIO lookup for
> consumer scl
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: using ACPI for
> GPIO lookup
> Apr 15 17:47:11 tau-ceti kernel: acpi AMDI0010:00: GPIO: looking up scl-gpios
> Apr 15 17:47:11 tau-ceti kernel: acpi AMDI0010:00: GPIO: looking up scl-gpio
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: using lookup
> tables for GPIO lookup
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: lookup for GPIO
> scl failed
> Apr 15 17:47:11 tau-ceti kernel: i2c-dev: adapter [Synopsys DesignWare I2C
> adapter] registered as minor 5
> Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: adapter [Synopsys DesignWare I2C
> adapter] registered
> Apr 15 17:47:11 tau-ceti kernel: acpi ELAN0732:00: GPIO: looking up 0 in _CRS
> Apr 15 17:47:11 tau-ceti kernel: gpio gpiochip0: Persistence not supported
> for GPIO 89
> Apr 15 17:47:11 tau-ceti kernel: i2c_hid i2c-ELAN0732:00: probe
> Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: master_xfer[0] W, addr=0x10,
> len=2
> Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: master_xfer[1] R, addr=0x10,
> len=30
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: i2c_dw_xfer:
> msgs: 2
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: enabled=0x1
> stat=0x10
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: enabled=0x1
> stat=0x504
> Apr 15 17:47:11 tau-ceti last message repeated 9 times
> 
> 
> 
> The patch creates one issue, which is that the following warning now pops up
> at boot:
> 
> The battery in your keyboard ("ELAN0732:00 04F3:2537") is low, and the
> device may turn itself off at any time. Please replace or charge the battery
> as soon as possible. 
> 
> However all other peripherals and buttons work fine, so it's a minor
> nuisance.
> 
> Thank you for getting us this far!

It looks like upower/i2c-hid think the touchscreen has a battery (which is false) and reports a invalid power value of 0. When I get a working desktop I could take a look for it. Meanwhile switching CONFIG_HID_BATTERY_STRENGTH off should silence the warning if you don't rely on this feature.

(In reply to Lukas Kahnert from comment #14)
> Created attachment 275381 [details]
> possible fix for touchscreen
> 
> I think I found the problem.
> There are 2 ACPI-related bugs which prevents the detection of the
> touchscreen.
> 
> 1. As already mentioned, the AMD GPIO driver tries to get an IRQ for GPIO
> but the ACPI code is missing for x86.
> 2. The IRQ of the GPIO device is misconfigured. For some reason it sets the
> IRQ "edge, high" but in the ACPI table it's defined as "level, low".
> 
> I made a fix but it's only a temporary workround until someone who have more
> knowledge of the subsystems can implement it cleaner.
> Could someone try this patch on a desktop enviroment? I just tested the
> output of hidraw which worked.

Thanks Lukas, this makes it work!!!

BTW, are you getting hangs/freezes possibly related to the amdgpu driver?

Also Lukas, can you upstream this patch?

@Bráulio I'm sorry but I'm not a kernel developer and this patch is just a dirty hack, which only works on this notebook. On other hardware it could make the system unbootable.
For upstream it needs a cleaner solution.

I already made a bugreport for the IRQ issue:
https://bugzilla.kernel.org/show_bug.cgi?id=199523

For the bug in the AMD GPIO driver it's a missing ACPI feature(I think). My patch comments out this snippet which triggers the error but I'm absolutely unsure if it represents a correct behaviour for (all)x86/amd64 systems. As long the touchscreen and the other hardware works ok, it should be safe for the notebook.

Well, there is another temporary solution and that is fixing the ACPI table. 

I have seen this error for quite a long time, as the A10/A12 Envy X360 Notebooks made in 2016/2017 also have the same error. 

Based on the Howto of https://wiki.archlinux.org/index.php/DSDT 
you can extract the ACPI table, then increase the version (This number may be different on your installed firmware) number of the first row: 
-DefinitionBlock ("", "DSDT", 2, "HPQOEM", "83C6    ", 0x01072009)
+DefinitionBlock ("", "DSDT", 2, "HPQOEM", "83C6    ", 0x01072010)

and change the AMDGPIO part:
@@ -4447,7 +4447,7 @@
             {
                 Name (RBUF, ResourceTemplate ()
                 {
-                    Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
+                    Interrupt (ResourceConsumer, Edge, ActiveHigh, Shared, ,, )
                     {
                         0x00000007,
                     }



If you inject that modified and recompiled ACPI, the same fix should work for any kernel which supports the ELAN touch controller. 

If that can be double checked by the owners, it would be a chance to push this work back to HP to fix their ACPI table.

Created attachment 275675 [details]
"Fixing" the ACPI Error the other way around: patching the acpi table

Instead of adding a temporary hack into the kernel, it is also possible to patch the acpi table which is created by the HP Firmware. This should work with all kernels and this would show that the main work to do is on HPs side - not on the kernel developers side.

(In reply to Daniel Andersen from comment #22)
> Created attachment 275675 [details]
> "Fixing" the ACPI Error the other way around: patching the acpi table
> 
> Instead of adding a temporary hack into the kernel, it is also possible to
> patch the acpi table which is created by the HP Firmware. This should work
> with all kernels and this would show that the main work to do is on HPs side
> - not on the kernel developers side.

I can confirm that hand-patching the ACPI to change the GPIO interrupt type/level eliminates the same GPIO error on my HP M6AR004DX laptop, which has an FX-9800P.  The ELAN0732 touchscreen still isn't working (on to the next error)...with the patched ACPI:

[    8.464309] i2c_hid i2c-ELAN0732:00: i2c-ELAN0732:00 supply vdd not found, using dummy regulator
[   13.490200] i2c_hid i2c-ELAN0732:00: failed to reset device.
[   19.676718] i2c_hid i2c-ELAN0732:00: failed to reset device.
[   25.863360] i2c_hid i2c-ELAN0732:00: failed to reset device.
[   32.050080] i2c_hid i2c-ELAN0732:00: failed to reset device.
[   33.063523] i2c_hid i2c-ELAN0732:00: can't add hid device: -61
[   33.063732] i2c_hid: probe of i2c-ELAN0732:00 failed with error -61

I've been trying to find information on how to fix this darned touchscreen controller for about a year.  The comments in this thread are the first that have actually made any real progress forward, so thank you to those that were able to dig into this.

(In reply to m.kolesinski from comment #23)
> (In reply to Daniel Andersen from comment #22)
> > Created attachment 275675 [details]
> > "Fixing" the ACPI Error the other way around: patching the acpi table
> > 
> > Instead of adding a temporary hack into the kernel, it is also possible to
> > patch the acpi table which is created by the HP Firmware. This should work
> > with all kernels and this would show that the main work to do is on HPs
> side
> > - not on the kernel developers side.
> 
> I can confirm that hand-patching the ACPI to change the GPIO interrupt
> type/level eliminates the same GPIO error on my HP M6AR004DX laptop, which
> has an FX-9800P.  The ELAN0732 touchscreen still isn't working (on to the
> next error)...with the patched ACPI:
> 
> [    8.464309] i2c_hid i2c-ELAN0732:00: i2c-ELAN0732:00 supply vdd not
> found, using dummy regulator
> [   13.490200] i2c_hid i2c-ELAN0732:00: failed to reset device.
> [   19.676718] i2c_hid i2c-ELAN0732:00: failed to reset device.
> [   25.863360] i2c_hid i2c-ELAN0732:00: failed to reset device.
> [   32.050080] i2c_hid i2c-ELAN0732:00: failed to reset device.
> [   33.063523] i2c_hid i2c-ELAN0732:00: can't add hid device: -61
> [   33.063732] i2c_hid: probe of i2c-ELAN0732:00 failed with error -61
> 
> I've been trying to find information on how to fix this darned touchscreen
> controller for about a year.  The comments in this thread are the first that
> have actually made any real progress forward, so thank you to those that
> were able to dig into this.

Hear hear! Glad to see some progress on this! I've been trying to resolve the touchscreen issue since my purchase of the Envy x360 a few weeks ago. Kudos to those of you working on it. I'll be monitoring and look forward to a solution.

Lukas' patch works for me.

The touchscreen works with a patched Linux 4.17-rc3 on a HP ENVY x360 15-bq102ng with Ubuntu 18.04 :) Thank you so much!

Modifying the ACPI table gives me the same result that m.kolesinski@gmail.com described.

I hope there there will be some generic solution that can be mainlined.

Lukas' patch also worked for me. Ubuntu 18.04 patched to Linux kernel 4.17-rc4 on my HP Envy x360 15-bq100 Convertible. Thanks to all that contributed to this issue!

Hello!

I think I managed to apply Daniel's ACPI table patch, but the touchscreen still doesn't work. I now get this error in dmesg:

[    2.284918] i2c_hid i2c-ELAN0732:00: HID over i2c has not been provided an Int IRQ
[    2.286070] i2c_hid: probe of i2c-ELAN0732:00 failed with error -22

I don't really know what I'm doing (took me like two days to apply the patch) so I'm sorry if I've done something dumb. I reaaally want to get this touchscreen working.

(In reply to Nicola Sorace from comment #27)
> Hello!
> 
> I think I managed to apply Daniel's ACPI table patch, but the touchscreen
> still doesn't work. I now get this error in dmesg:
> 
> [    2.284918] i2c_hid i2c-ELAN0732:00: HID over i2c has not been provided
> an Int IRQ
> [    2.286070] i2c_hid: probe of i2c-ELAN0732:00 failed with error -22
> 
> I don't really know what I'm doing (took me like two days to apply the
> patch) so I'm sorry if I've done something dumb. I reaaally want to get this
> touchscreen working.

The ACPI variant still does not work at the moment. 
If you are using Ubuntu I can share the kernel image that I built with you.

(In reply to Marc from comment #28)
> (In reply to Nicola Sorace from comment #27)
> > Hello!
> > 
> > I think I managed to apply Daniel's ACPI table patch, but the touchscreen
> > still doesn't work. I now get this error in dmesg:
> > 
> > [    2.284918] i2c_hid i2c-ELAN0732:00: HID over i2c has not been provided
> > an Int IRQ
> > [    2.286070] i2c_hid: probe of i2c-ELAN0732:00 failed with error -22
> > 
> > I don't really know what I'm doing (took me like two days to apply the
> > patch) so I'm sorry if I've done something dumb. I reaaally want to get
> this
> > touchscreen working.
> 
> The ACPI variant still does not work at the moment. 
> If you are using Ubuntu I can share the kernel image that I built with you.

I'm running Arch unfortunately. Will I have to recompile the kernel with Lukas' patch applied or is there another way?

(In reply to Nicola Sorace from comment #29)
> I'm running Arch unfortunately. Will I have to recompile the kernel with
> Lukas' patch applied or is there another way?

As far as I know, there is no other way, currently.

Lukas' patch worked! Touchscreen worked immediately after booting into new kernel. Thank you all so much!

Hoping to keep discussion of this issue alive. I can also confirm that the patch works, though I found it very difficult to implement as someone who has not done any kernel patching before. And since I am trying to keep up with kernel updates in the hopes of solving various other issues, this needs to be done repeatedly. Any hope of a permanent solution?

I also made a question at AskUbuntu to discuss the other various issues with this laptop:
https://askubuntu.com/questions/1047374/hp-envy-x360-ryzen-5-status-of-known-issues

Is it possible for anyone to link to a compiled version of the kernel with the fix installed? I am having a heck of a time figuring out how to get it decompiled and the new code inserted.


Thanks ahead of time.

(In reply to ryanmcg from comment #32)
> Any hope of a permanent solution?

Someone will need to write a more permanent solution than Lukas' hack and get it mainlined. Any HP or AMD kernel devs on this bug report? :-)

I tried Lukas' patch on both the latest gen x360 15z and 13z (model is 13z-ag000), and while it sometimes work perfectly, on some boots I get a "irq 7: nobody cared (try booting with the "irqpoll" option)" line followed by a "Disabling IRQ #7" message in dmesg, and the touchscreen stops working.

Booting with "irqpoll" does ensure a working touchscreen, but it seems to have a negative impact on battery life due to there being 8-9k IRQs per second constantly. Also, some new warning messages appeared in dmesg once irqpoll is enabled: a "hpet1: lost 9601 rtc interrupts" message repeats every 1-2 seconds ("hpet=disable" removes this, but doesn't help with the high number of IRQs per second), and a "i2c_hid i2c-ELAN0732:00: i2c_hid_get_input: incomplete report (67/65535)" warning happens with every touchscreen event.

I have a dual-boot setup with Windows 10, and the issue seems to be somehow affected by the other OS - rebooting from Windows 10 seems to guarantee a non-working touchscreen; however, cold booting directly into Linux (I tried Fedora 28 & Fedora Rawhide) does not guarantee a working touchscreen.

Did anyone experience the same problem? Or have ideas what the root cause or any workarounds might be?

Created attachment 277793 [details]
DMESG with Lukas' patch and "irq 7: nobody cared" error

Created attachment 277795 [details]
DMESG with Lukas' patch and "irqpoll" option

Created attachment 277797 [details]
ACPI from the intel version of the Envy X360 15 (2018/2019 Model "15-CN)

Hi, 

Just for comparison the ACPI Table of the 2018/2019 Model of the HP Envy X360 15-CN0000 ( Intel 8th Gen CPU ). The ELAN config looks a bit more sophisticated. 

Amd 15-BQ Model:    Device (TPNL)
Intel 15-CN Model:  Device (TPL1)

(In reply to kk1987 from comment #35)
> I tried Lukas' patch on both the latest gen x360 15z and 13z (model is
> 13z-ag000), and while it sometimes work perfectly, on some boots I get a
> "irq 7: nobody cared (try booting with the "irqpoll" option)" line followed
> by a "Disabling IRQ #7" message in dmesg, and the touchscreen stops working.
> 
> Booting with "irqpoll" does ensure a working touchscreen, but it seems to
> have a negative impact on battery life due to there being 8-9k IRQs per
> second constantly. Also, some new warning messages appeared in dmesg once
> irqpoll is enabled: a "hpet1: lost 9601 rtc interrupts" message repeats
> every 1-2 seconds ("hpet=disable" removes this, but doesn't help with the
> high number of IRQs per second), and a "i2c_hid i2c-ELAN0732:00:
> i2c_hid_get_input: incomplete report (67/65535)" warning happens with every
> touchscreen event.
> 
> I have a dual-boot setup with Windows 10, and the issue seems to be somehow
> affected by the other OS - rebooting from Windows 10 seems to guarantee a
> non-working touchscreen; however, cold booting directly into Linux (I tried
> Fedora 28 & Fedora Rawhide) does not guarantee a working touchscreen.
> 
> Did anyone experience the same problem? Or have ideas what the root cause or
> any workarounds might be?

this behaviour occurs on my laptop when I reboot from windows. I need to complete power off/cold boot to workround the irq-issue. Sometimes the touchpad don't even get detected when I booted windows before. I think Linux lacks of some reset features for the ACPI IRQs on HP Envy x360.

I'm sorry but I'm too busy for debug the issue. I still hope a kernel developer comes and creates a real fix :)

Hej!

I'm new to how bug reporting works in Linux and have the same problem. (Hence me being here) How do we get the attention of a kernel developer? How can we find who to ask? Is there someone like a "package maintainer" for this?

(In reply to Lukas Kahnert from comment #39)
> (In reply to kk1987 from comment #35)
> > I tried Lukas' patch on both the latest gen x360 15z and 13z (model is
> > 13z-ag000), and while it sometimes work perfectly, on some boots I get a
> > "irq 7: nobody cared (try booting with the "irqpoll" option)" line followed
> > by a "Disabling IRQ #7" message in dmesg, and the touchscreen stops
> working.
> > 
> > Booting with "irqpoll" does ensure a working touchscreen, but it seems to
> > have a negative impact on battery life due to there being 8-9k IRQs per
> > second constantly. Also, some new warning messages appeared in dmesg once
> > irqpoll is enabled: a "hpet1: lost 9601 rtc interrupts" message repeats
> > every 1-2 seconds ("hpet=disable" removes this, but doesn't help with the
> > high number of IRQs per second), and a "i2c_hid i2c-ELAN0732:00:
> > i2c_hid_get_input: incomplete report (67/65535)" warning happens with every
> > touchscreen event.
> > 
> > I have a dual-boot setup with Windows 10, and the issue seems to be somehow
> > affected by the other OS - rebooting from Windows 10 seems to guarantee a
> > non-working touchscreen; however, cold booting directly into Linux (I tried
> > Fedora 28 & Fedora Rawhide) does not guarantee a working touchscreen.
> > 
> > Did anyone experience the same problem? Or have ideas what the root cause
> or
> > any workarounds might be?
> 
> this behaviour occurs on my laptop when I reboot from windows. I need to
> complete power off/cold boot to workround the irq-issue. Sometimes the
> touchpad don't even get detected when I booted windows before. I think Linux
> lacks of some reset features for the ACPI IRQs on HP Envy x360.
> 
> I'm sorry but I'm too busy for debug the issue. I still hope a kernel
> developer comes and creates a real fix :)

Hey thanks for the reply and for writing the patch.

In case anyone had the same question, I realized why cold booting didn't always work for me: it looks like the power cord must be unplugged at least once when the laptop is powered off. I'm using a USB type-C power adapter and haven't tried the original adapter, but I suspect it's the same.

(In reply to Bram Coenen from comment #40)
> Hej!
> 
> I'm new to how bug reporting works in Linux and have the same problem.
> (Hence me being here) How do we get the attention of a kernel developer? How
> can we find who to ask? Is there someone like a "package maintainer" for
> this?

Just a quick drive-by comment... The kernel has a "MAINTAINERS" file (see https://www.kernel.org/doc/linux/MAINTAINERS) which lists the people who maintain its various subsystems. Mika Westerberg might be a good person to check with since he maintains the I2C ACPI bits.

Does Lukas' patch work? with newer kernels?

How would I apply it? Does anyone have a precompiled version (or a pkgbuild) for arch? Or Ubuntu?

Created attachment 278229 [details]
turn on GSI on x86 platform

    Can someone test this patch. I think the developer keep the config disabled on x86 because the code is not well tested and may break the kernel on some buggy firmware. https://patchwork.kernel.org/patch/9474763/

drivers/acpi/irq.o: In function `acpi_gsi_to_irq':
irq.c:(.text+0x0): multiple definition of `acpi_gsi_to_irq'
arch/x86/kernel/acpi/boot.o:boot.c:(.text+0x1a0): first defined here
drivers/acpi/irq.o: In function `acpi_register_gsi':
irq.c:(.text+0x70): multiple definition of `acpi_register_gsi'
arch/x86/kernel/acpi/boot.o:boot.c:(.text+0x0): first defined here
drivers/acpi/irq.o: In function `acpi_unregister_gsi':
irq.c:(.text+0xf0): multiple definition of `acpi_unregister_gsi'
arch/x86/kernel/acpi/boot.o:boot.c:(.text+0x10): first defined here
drivers/acpi/irq.o:(.bss+0x0): multiple definition of `acpi_irq_model'
arch/x86/kernel/acpi/boot.o:(.bss+0x8): first defined here
make: *** [Makefile:1010: vmlinux] Error 1

After applying the patch I get the above on 4.18.5

I apologize if this is the wrong place to post this, but I've following this thread for a while and it could be related.

I bios update was released on the 29th of August for Ryzen HP Envy x360 13.3 inch version. (I assume it's also Ryzen, though) In the notes it says it fixes some issues with the touchscreen so I thought it might help.

Now, I can't even install any flavour of linux (I've tried Ubuntu 18.04.1 and the latest version of Pop!_OS) because as soon as I choose to boot from the install USB, it'll come up with the scrolling debug text and then go to a blackscreen where I can do nothing. I assume it's trying to access specific screen drivers and failing as the fans are still intermittently speeding up suggesting it's going through the usual process in the background.

Is there any way to troubleshoot this to find some specific errors?

Apologies if this is unrelated to the current issue at hand and deserves it's own bug report.

To be specific, the BIOS update that caused the issue was 'F.19 Rev.A'

It's patch notes list this fix: "Fixes an issue which causes the touch screen to stop functioning properly'

I'll try and rollback to an earlier BIOS to see if this was my specific issue.

@crab
I've added  CONFIG_ACPI_GENERIC_GSI=y
to the config and just patched the low/high issue (without the patch of platform.c) and the touchscreen now works. 
In theory it now should work with the acpi table modification and compiling with CONFIG_ACPI_GENERIC_GSI=y too.

@Thomas
could you link the patch(es) you applied?

@Maxime 
I've basically used Lukas' patch , but removed the upper part of it (the one modifying platform.c).

Patching the acpi table as described above does not work. The problem seems to be that the values from the table are overwritten somehow, so patching it seems useless?

Then I added the CONFIG_ACPI_GENERIC_GSI=y to the "config" file of the Arch Linux source (https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux). I don't think that this file should be modified, since its header comment says so. I think the clean way would be crab2313s way, however this fails with the errors from above.

@Sean This bug is not related to this report. But I can help you as I run into the same problem with the same laptop. The bios update cannot be reset. I tried and failed. The only way to get this working again is to use the new Kernel 4.19 which is due for release in october. However you can boot your linux with the command nomodeset instead of quiet splash in your grub config (depends on your distro). After you boot linux, you can install the RC-Version of Kernel 4.19. I use openSUSE Tumbleweed and they have a certain repo for new Kernels.

I was using Lukas' patch successfully until I also updated my BIOS hoping the "Fixes an issue which causes the touch screen to stop functioning properly" would fix having to patch the kernel. Now that I'm on 4.19-rc2 I applied the patch as I had been and the touchscreen isn't working again, I'm assuming they changed something in the new BIOS that also breaks that workaround?

@Ryan, which device? I still can't find a newer bios than the F.17 for my 15-bq101ng . 
Would you please provide your dmesg and dsdt?

Created attachment 278325 [details]
Ryan 15m-cp0012dx F.19 Rev.A dmesg

I am using an Envy x360 15m-cp0012dx. The bios is version F.19 Rev.A https://support.hp.com/us-en/drivers/selfservice/swdetails/hp-envy-15m-cp0000-x360-convertible-pc/20270308/model/21925604/swItemId/ob-217449-1

I'm new to this site so I hope this is the right way to comment and leave the attached files

Created attachment 278327 [details]
Ryan 15m-cp0012dx F.19 Rev.A dsdt.dat

Followed the instructions on the arch wiki to create this dsdt. let me know if that's the wrong file.

Hi! I've been following a bit this discussion: it seems that those patches work, right?
Now, I've also noticed I'm not the only person who is a total noob with linux kernels and their compiling. What I would like to ask is if anyone can make a few steps guide on how to apply the patch and recompile the kernel (and how to install it since I don't think the output would be a standard .deb package, isn't it?).
Thanks a lot in advance!

I'm not too familiar with Ubuntu but https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel would be a good place to start.
In a more general sense you need to get the kernel source, build it while applying the patch, install it in your boot directory, and update your boot loader to point at the new image.

https://askubuntu.com/questions/724900/how-to-apply-kernel-patches/724909#724909 Here is an example of how to patch the kernel in more detail on Ubuntu.

I'm using a 13-ag0502sa.

When I was running BIOS version F.17 the touchscreen wouldn't work with any of these patches.  I've upgraded to BIOS F.20 and the touchscreen works with Lukas' patch, but not with a modified DSDT and an unpatched kernel.

After reading the report, I suggest the original reporter to assign to ACPI Component-table component bug because it is clearly an ACPI error preventing the touchscreen and by extent stylus that comes with HP Envy x360 Ryzen series.
I am adding one of ACPI maintainer on the list to check out.

Created attachment 279245 [details]
attachment-20618-0.html

Would you please clarify which component you are suggesting I add this to?
I do not see one labelled "table"

On Mon, Oct 29, 2018 at 11:15 PM <bugzilla-daemon@bugzilla.kernel.org>
wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=198715
>
> Luya Tshimbalanga (luya@fedoraproject.org) changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |lv.zheng@intel.com
>
> --- Comment #59 from Luya Tshimbalanga (luya@fedoraproject.org) ---
> After reading the report, I suggest the original reporter to assign to ACPI
> Component-table component bug because it is clearly an ACPI error
> preventing
> the touchscreen and by extent stylus that comes with HP Envy x360 Ryzen
> series.
> I am adding one of ACPI maintainer on the list to check out.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.

My bad, I have assigned this bug properly.

Thank you!

(In reply to Luya Tshimbalanga from comment #59)
> After reading the report, I suggest the original reporter to assign to ACPI
> Component-table component bug because it is clearly an ACPI error preventing
> the touchscreen and by extent stylus that comes with HP Envy x360 Ryzen
> series.
> I am adding one of ACPI maintainer on the list to check out.

I want to be clear, this bug does not just affect Ryzen series CPUs/APUs, it also affects the previous gen CPUs, including the FX9800P in my x360, model m6-ar004dx.  It looks like they share the same GPIO config with respect to the i2c ELAN0734 touchscreen controller.

I would like to make sure whatever fix gets put in fixes all affected platforms, not just Ryzen.  I will gladly test driver/kernel patches and/or ACPI/DSDT patches.  I can also post my DSDT if it helps, it was very similar with regard to this GPIO to the one already discussed.

I have two identical laptops I can test with.

(In reply to Luya Tshimbalanga from comment #59)
> After reading the report, I suggest the original reporter to assign to ACPI
> Component-table component bug because it is clearly an ACPI error preventing
> the touchscreen and by extent stylus that comes with HP Envy x360 Ryzen
> series.
> I am adding one of ACPI maintainer on the list to check out.

I want to be clear, this bug does not just affect Ryzen series CPUs/APUs, it also affects the previous gen CPUs, including the FX9800P in my x360, model m6-ar004dx.  It looks like they share the same GPIO config with respect to the i2c ELAN0734 touchscreen controller.

I would like to make sure whatever fix gets put in fixes all affected platforms, not just Ryzen.  I will gladly test driver/kernel patches and/or ACPI/DSDT patches.  I can also post my DSDT if it helps, it was very similar with regard to this GPIO to the one already discussed.

I have two identical laptops I can test with.

(In reply to m.kolesinski from comment #63) 
> I want to be clear, this bug does not just affect Ryzen series CPUs/APUs, it
> also affects the previous gen CPUs, including the FX9800P in my x360, model
> m6-ar004dx.  It looks like they share the same GPIO config with respect to
> the i2c ELAN0734 touchscreen controller.
> 
Should the title renamed something like "Misconfigured ACPI config-table broke Elan touchscreen on HP Envy x360 series" for better clarification?

Updated title to reflect that this bug affects multiple HP x360 machines running AMD chips

I just found a documentation for debugging:
https://www.kernel.org/doc/Documentation/acpi/debug.txt

Enable kernel debugging and add the parameter like "acpi.debug_layer=0x000008 acpi.debug_level=0x4" to display table information. Should there be a better parameter,please post it.

I can provide log/debug information and test too. My notebook is HP 13M-AG0002DX.

Here is an example of debugging process I have used with the help of one of kernel maintainer once installed kernel debug. It basically replaces comment #66 :

https://bugzilla.kernel.org/show_bug.cgi?id=115021#c58

I don't know exactly which .c file display acpi table. Hopefully that will draw attention once the information is submitted. Thanks in advance.

First if all thank you Lukas, for pinpointing the problem. I don't see any really obvious nice answer here.

So I believe it is best to override the IRQ type manually in the AMD gpio driver to correct the acpi_get_override_irq() results from the ACPI core.

I've attached a patch doing this to bug 199523.

If someone who is seeing this issue can build and test a kernel with that patch (replacing Lukas patch) that would be great. To be clear please drop Lukas' patch  when testing mine!

If you test my patch, please provide the output of "dmesg" directly after boot and let me know if the patch fixes things (makes/keeps the touchscreen working).

I would test the patch but can't find it.

(In reply to Marc from comment #70)
> I would test the patch but can't find it.

My bad, I was updating the 3 different bugs about this all at the same time and I actually forgot to attach the patch, it is attached to bug 199523 now.

Created attachment 279529 [details]
Output of dmesg after booting kernel 4.19.2 with new patch

Unfortunately the new patch does not work on my ENVY 15-bq102ng.

I used linux kernel 4.19.2 from kernel.org, patched it with the ubuntu mainline patches and on top your patch (instead of Lukas patch).

(In reply to Marc from comment #73)
> Unfortunately the new patch does not work on my ENVY 15-bq102ng.
> 
> I used linux kernel 4.19.2 from kernel.org, patched it with the ubuntu
> mainline patches and on top your patch (instead of Lukas patch).

Thank you for testing. These 2 lines in the log seem to be the problem, these happen before my patch even comes into play:

[    1.445982] amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
[    1.446019] amd_gpio: probe of AMDI0030:00 failed with error -22

With -22 being -EINVAL.

Taking a closer look at things here I think I know what is going on here.

To be continued.

I am happy to test further patches.

When I come home I will test your Patch and report asap.


(In reply to Hans de Goede from comment #74)
> (In reply to Marc from comment #73)
> > Unfortunately the new patch does not work on my ENVY 15-bq102ng.
> > 
> > I used linux kernel 4.19.2 from kernel.org, patched it with the ubuntu
> > mainline patches and on top your patch (instead of Lukas patch).
> 
> Thank you for testing. These 2 lines in the log seem to be the problem,
> these happen before my patch even comes into play:
> 
> [    1.445982] amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
> [    1.446019] amd_gpio: probe of AMDI0030:00 failed with error -22
> 
> With -22 being -EINVAL.
> 
> Taking a closer look at things here I think I know what is going on here.
> 
> To be continued.

This error happens because your patch only fixes the mis-detection of the IRQ. There ist still https://bugzilla.kernel.org/show_bug.cgi?id=199529 which needs also bei fixed to get the touchscreen work.
One half of my Patch hides the affected code, so the gpio driver can probe successfully.

Created attachment 279539 [details]
[PATCH] ACPI / platform: Add SMB0001 HID to forbidden_id_list

Ok second attempt, a completely different patch which I think actually is better (if it works).

Please give this one a try (without any other patches for this same issue).

Again please attach dmesg output.

If this patch does not fix things, then also please attach the output of:

ls /sys/bus/platform/devices

I would like the output of that command for both a kernel without the patch as well as for one with the patch.

(In reply to Lukas Kahnert from comment #76)
> This error happens because your patch only fixes the mis-detection of the
> IRQ. There ist still https://bugzilla.kernel.org/show_bug.cgi?id=199529
> which needs also bei fixed to get the touchscreen work.

Right, I figured that out now, actually I believe that with your hack to drivers/acpi/resource.c the changes you made to drivers/base/platform.c should no longer be necessary.

We've been looking at the wrong part of the DSDT the culprit is not:

Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
                    {
                        0x00000007,
                    }

This uses an extended interrupt syntax, so acpi_dev_get_irqresource() gets called with legacy == false and the troublesome acpi_get_override_irq()
never happens.

I believe the real culprit is:

    Scope (_SB.PCI0)
    {
        Device (SMBD)
        {
            Name (_HID, "SMB0001")  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0B20,             // Range Minimum
                    0x0B20,             // Range Maximum
                    0x20,               // Alignment
                    0x20,               // Length
                    )
                IRQ (Level, ActiveLow, Shared, )
                    {7}
            })
        }
    }

Which does use a legacy style IRQ resource, this causes acpi_dev_get_irqresource() to be called with legacy == true and then the troublesome acpi_get_override_irq() happens.

I believe that this troublesome node gets parsed before the AMDI0030 node and then by the time the AMDI0030 node happens, inside acpi_dev_get_irqresource() we hit the else of:

        irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
        if (irq >= 0) {
                res->start = irq;
                res->end = irq;
        } else {
                acpi_dev_irqresource_disabled(res, gsi);
        }

Which sets the DISABLED flag, which is causing the issue in drivers/base/platform.c . The reason we hit the else path is because of the earlier enumeration of the same interrupt with conflicting trigger / polarity settings so the second one fails with -EBUSY (it would work if the flags would match).

My new attempt deals with this by adding the "SMB0001" HID to the blacklist for creating platform devices, so that acpi_dev_get_resources() does not get called on it at all, avoiding the call of acpi_dev_get_irqresource() with legacy == false.

The not creating of a platform_device for the "SMB0001" HID is not an issue since the driver for it is an acpi bus driver not a platform bus driver.

Created attachment 279541 [details]
Output of dmesg after booting kernel 4.19.2 with new patch v2 (touchscreen works)

Congratulations, this work!

(In reply to Marc from comment #79)
> Created attachment 279541 [details]
> Output of dmesg after booting kernel 4.19.2 with new patch v2 (touchscreen
> works)
> 
> Congratulations, this work!

Great and the "ACPI: IRQ 7 override to edge, high" message is gone. So you've proven my theory.

Now I need to improve the commit message and then this patch can be submitted upstream.

p.s.

I plan to add the following to the commit msg, please let me know if you've objections against this:

Reported-by: Lukas Kahnert <openproggerfreak@gmail.com>
Tested-by: Marc <suaefar@googlemail.com>

(In reply to Hans de Goede from comment #78)
> (In reply to Lukas Kahnert from comment #76)
> > This error happens because your patch only fixes the mis-detection of the
> > IRQ. There ist still https://bugzilla.kernel.org/show_bug.cgi?id=199529
> > which needs also bei fixed to get the touchscreen work.
> 
> Right, I figured that out now, actually I believe that with your hack to
> drivers/acpi/resource.c the changes you made to drivers/base/platform.c
> should no longer be necessary.
> 
> We've been looking at the wrong part of the DSDT the culprit is not:
> 
> Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
>                     {
>                         0x00000007,
>                     }
> 
> This uses an extended interrupt syntax, so acpi_dev_get_irqresource() gets
> called with legacy == false and the troublesome acpi_get_override_irq()
> never happens.
> 
> I believe the real culprit is:
> 
>     Scope (_SB.PCI0)
>     {
>         Device (SMBD)
>         {
>             Name (_HID, "SMB0001")  // _HID: Hardware ID
>             Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource
> Settings
>             {
>                 IO (Decode16,
>                     0x0B20,             // Range Minimum
>                     0x0B20,             // Range Maximum
>                     0x20,               // Alignment
>                     0x20,               // Length
>                     )
>                 IRQ (Level, ActiveLow, Shared, )
>                     {7}
>             })
>         }
>     }
> 
> Which does use a legacy style IRQ resource, this causes
> acpi_dev_get_irqresource() to be called with legacy == true and then the
> troublesome acpi_get_override_irq() happens.
> 
> I believe that this troublesome node gets parsed before the AMDI0030 node
> and then by the time the AMDI0030 node happens, inside
> acpi_dev_get_irqresource() we hit the else of:
> 
>         irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
>         if (irq >= 0) {
>                 res->start = irq;
>                 res->end = irq;
>         } else {
>                 acpi_dev_irqresource_disabled(res, gsi);
>         }
> 
> Which sets the DISABLED flag, which is causing the issue in
> drivers/base/platform.c . The reason we hit the else path is because of the
> earlier enumeration of the same interrupt with conflicting trigger /
> polarity settings so the second one fails with -EBUSY (it would work if the
> flags would match).
> 
> My new attempt deals with this by adding the "SMB0001" HID to the blacklist
> for creating platform devices, so that acpi_dev_get_resources() does not get
> called on it at all, avoiding the call of acpi_dev_get_irqresource() with
> legacy == false.
> 
> The not creating of a platform_device for the "SMB0001" HID is not an issue
> since the driver for it is an acpi bus driver not a platform bus driver.

Thanks for this good explanation :)

I can also confirm that your patch works on my laptop

(In reply to Hans de Goede from comment #81)
> p.s.
> 
> I plan to add the following to the commit msg, please let me know if you've
> objections against this:
> 
> Reported-by: Lukas Kahnert <openproggerfreak@gmail.com>
> Tested-by: Marc <suaefar@googlemail.com>

I'm glad that I could help :)

(In reply to Hans de Goede from comment #77)
> Created attachment 279539 [details]
> [PATCH] ACPI / platform: Add SMB0001 HID to forbidden_id_list
> 
> Ok second attempt, a completely different patch which I think actually is
> better (if it works).
> 
> Please give this one a try (without any other patches for this same issue).
> 
> Again please attach dmesg output.
> 
> If this patch does not fix things, then also please attach the output of:
> 
> ls /sys/bus/platform/devices
> 
> I would like the output of that command for both a kernel without the patch
> as well as for one with the patch.

It worked also on mine HP 13M-AG0002DX.

I tried to apply a patch but the kernel fails to compile. It only generated the headers file. There was a recipe for target error for retpoline-check-generic. Anyone know how I can fix this? Also, I am very new to all this but how long does a patch submission to appear in the next release?

I tried to apply a patch but the kernel fails to compile. It only generated the headers file. There was a recipe for target error for retpoline-check-generic. Anyone know how I can fix this? Also, I am very new to all this but how long does a patch submission to appear in the next release?

(In reply to Hans de Goede from comment #81)
> p.s.
> 
> I plan to add the following to the commit msg, please let me know if you've
> objections against this:
> 
> Reported-by: Lukas Kahnert <openproggerfreak@gmail.com>
> Tested-by: Marc <suaefar@googlemail.com>

I have no objections.
Thanks to everybody for finding a solution here :)

I applied the latest patch, it works but it makes my touchscreen show up as having a battery that's at 0%. The previous patch had the same behaviour on my system.

(In reply to Maxime from comment #87)
> I applied the latest patch, it works but it makes my touchscreen show up as
> having a battery that's at 0%. The previous patch had the same behaviour on
> my system.

Good to hear that this patch works for you to.

The battery at 0% is an unrelated issue, please file a new bug against product Drivers component HID (or input if there is no HID component) for this.

(In reply to Hans de Goede from comment #81)
> p.s.
> 
> I plan to add the following to the commit msg, please let me know if you've
> objections against this:
> 
> Reported-by: Lukas Kahnert <openproggerfreak@gmail.com>
> Tested-by: Marc <suaefar@googlemail.com>

I can also verify that the patch works on my HP Envy x360 15-bq100 Convertible! Thanks all, especially Hans and Lukas for a job well done!

(In reply to Stephen Owusu from comment #85)
> I tried to apply a patch but the kernel fails to compile. It only generated
> the headers file. There was a recipe for target error for
> retpoline-check-generic. Anyone know how I can fix this? Also, I am very new
> to all this but how long does a patch submission to appear in the next
> release?

I had a similar problem building on one machine and had to work through the missing packages to get a (nearly) complete build. Building on a fresh install of Ubuntu Xenial worked much better, without the problems of missing/mismatched packages. 

In both cases, I ended up with 7 deb files which installed and worked fine. The final perarch deb build failed, but doesn't seem to affect my system in any way that I've found so far. If anyone knows whether that's a problem, I'd like to know... The failure was a missing stdarg.h from the kernel.h include while building the perarch deb.

(In reply to Maxime from comment #87)
> I applied the latest patch, it works but it makes my touchscreen show up as
> having a battery that's at 0%. The previous patch had the same behaviour on
> my system.

Similar bug on https://bugzilla.kernel.org/show_bug.cgi?id=201121
It looks like the issue affecting Elan touchscreen and stylus models.

(In reply to Hans de Goede from comment #88)
> (In reply to Maxime from comment #87)
> > I applied the latest patch, it works but it makes my touchscreen show up as
> > having a battery that's at 0%. The previous patch had the same behaviour on
> > my system.
> 
> Good to hear that this patch works for you to.
> 
> The battery at 0% is an unrelated issue, please file a new bug against
> product Drivers component HID (or input if there is no HID component) for
> this.

What do you mean with a HID component in this case? A stylus?

(In reply to Maxime from comment #92)
> What do you mean with a HID component in this case? A stylus?

I mean the Product and Component fields in bugzilla, for the new bug. E.g. this bug has Product set the ACPI and Component set to Config-Tables.

*** Bug 199529 has been marked as a duplicate of this bug. ***

HP envy x360 13-ag0018au with Ryzen 7 here, the touchscreen issue is resolved with BIOS F.21.Rev.A and standard fedora kernel-4.19.3-300.fc29.x86_64

Is anyone else seeing the issue where the touchscreen/pen don't work when the computer is first powered on (needs to be rebooted at least once)? If so, was this supposed to be fixed by this or should that be a separate bug report?

(In reply to Addie Morrison from comment #96)
> Is anyone else seeing the issue where the touchscreen/pen don't work when
> the computer is first powered on (needs to be rebooted at least once)? If
> so, was this supposed to be fixed by this or should that be a separate bug
> report?

When this happens do you see any relevant messages in dmesg ?

In: https://bugzilla.redhat.com/show_bug.cgi?id=1644013

There is a report of the machine sometimes reporting:

[    5.739281] irq 7: nobody cared (try booting with the "irqpoll" option)
[    5.739284] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G         C        4.19.2-301.hdg1.fc29.x86_64 #1
[    5.739285] Hardware name: HP HP ENVY x360 Convertible 15-cp0xxx/8497, BIOS F.21 10/19/2018
[    5.739285] Call Trace:
[    5.739288]  <IRQ>
[    5.739294]  dump_stack+0x5c/0x80
[    5.739297]  __report_bad_irq+0x37/0xae
[    5.739298]  note_interrupt.cold.9+0xa/0x69
[    5.739300]  handle_irq_event_percpu+0x6a/0x80
[    5.739301]  handle_irq_event+0x27/0x44
[    5.739302]  handle_fasteoi_irq+0x7f/0x120
[    5.739305]  handle_irq+0xbf/0x100
[    5.739307]  do_IRQ+0x49/0xd0
[    5.739308]  common_interrupt+0xf/0xf
[    5.739309]  </IRQ>

After which the kernel disables IRQ 7 causing the touchscreen to not work again. 

If you're seeing this too, please open a new bug for the "irq 7: nobody cared" problem.

The patch fixing the IRQ not being assigned to the GPIO controller has been merged upstream now, so I'm closing this bug.

I was able to test the latest patch from Hans on Arch Linux with 4.19.4-arch1 on my HP M6-AR004DX AMD FX-9800p laptop, and can confirm that the ELAN0732 touchscreen finally works!  No need for the ACPI/DSDT edits.  No more GPIO errors in journalctl, and the device was detected and installed with hid_multitouch.

To add icing to the cake, it even worked on the login screen (GDM) and within Gnome 3, with no manual configuration steps required, and no calibration required.

I had a bear of a time testing the patch this time (no issue with the patch itself); the latest Arch build scripts have moved to pulling kernel source via a git clone (massive download...multiple gigs...I have a relatively slow connection, and git clone offers no restart ability if the download times out or fails partway...).  I had to manually download source with http and hack PKGBUILD to point at my local source copy (the latest Arch PKGBUILD also points to a newer kernel than the latest Arch release...seems like a problem), in addition to adding the patch file to prepare().

(In reply to Hans de Goede from comment #97)
> (In reply to Addie Morrison from comment #96)
> > Is anyone else seeing the issue where the touchscreen/pen don't work when
> > the computer is first powered on (needs to be rebooted at least once)? If
> > so, was this supposed to be fixed by this or should that be a separate bug
> > report?
> 
> When this happens do you see any relevant messages in dmesg ?
> 
> In: https://bugzilla.redhat.com/show_bug.cgi?id=1644013
> 
> There is a report of the machine sometimes reporting:
> 
> [    5.739281] irq 7: nobody cared (try booting with the "irqpoll" option)
> [    5.739284] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G         C       
> 4.19.2-301.hdg1.fc29.x86_64 #1
> [    5.739285] Hardware name: HP HP ENVY x360 Convertible 15-cp0xxx/8497,
> BIOS F.21 10/19/2018
> [    5.739285] Call Trace:
> [    5.739288]  <IRQ>
> [    5.739294]  dump_stack+0x5c/0x80
> [    5.739297]  __report_bad_irq+0x37/0xae
> [    5.739298]  note_interrupt.cold.9+0xa/0x69
> [    5.739300]  handle_irq_event_percpu+0x6a/0x80
> [    5.739301]  handle_irq_event+0x27/0x44
> [    5.739302]  handle_fasteoi_irq+0x7f/0x120
> [    5.739305]  handle_irq+0xbf/0x100
> [    5.739307]  do_IRQ+0x49/0xd0
> [    5.739308]  common_interrupt+0xf/0xf
> [    5.739309]  </IRQ>
> 
> After which the kernel disables IRQ 7 causing the touchscreen to not work
> again. 
> 
> If you're seeing this too, please open a new bug for the "irq 7: nobody
> cared" problem.
> 
> The patch fixing the IRQ not being assigned to the GPIO controller has been
> merged upstream now, so I'm closing this bug.


First of all thank you helping out Hans. I got the same problem with "irq 7: nobody cared" and made a bug report over here: https://bugzilla.kernel.org/show_bug.cgi?id=201817 . I'm new to bug reporting, so I hope I did it right!

(In reply to Bram Coenen from comment #99)
> First of all thank you helping out Hans. I got the same problem with "irq 7:
> nobody cared" and made a bug report over here:
> https://bugzilla.kernel.org/show_bug.cgi?id=201817 . I'm new to bug
> reporting, so I hope I did it right!

Thanks, lets continue this in the new bug.

Hi all, 

I have been following this bug and patch for a while for my bq-100, it's exhilarating to know that you guys solved the touch/flip issue and I can go back as running my laptop vm host on linux again.

I've been refreshing this daily to see when the RESOLVED changes into VERIFIED so I can DL a stable kernel, but I think it doesn't work this way.

Therefore, can someone please point to how do I get Hans de Goede's patch into an ubuntu 18.10 install?
Is it the patch command, or ukuu, or a clean compile of the kernel (and if so, any howto for ubuntu for required extras?).

I usually don't poke into my daily driver computer if it's not required, but this Windows as host OS was supposed to only be till October, it unbalances my zen :-)

So, wait till official patched Kernel (any time estimate)? 
Or patch the kernel?

Cheers all.

(In reply to Eran Benjamin from comment #101)
> Hi all, 
> 
> I have been following this bug and patch for a while for my bq-100, it's
> exhilarating to know that you guys solved the touch/flip issue and I can go
> back as running my laptop vm host on linux again.
> 
> I've been refreshing this daily to see when the RESOLVED changes into
> VERIFIED so I can DL a stable kernel, but I think it doesn't work this way.
> 
> Therefore, can someone please point to how do I get Hans de Goede's patch
> into an ubuntu 18.10 install?
> Is it the patch command, or ukuu, or a clean compile of the kernel (and if
> so, any howto for ubuntu for required extras?).
> 
> I usually don't poke into my daily driver computer if it's not required, but
> this Windows as host OS was supposed to only be till October, it unbalances
> my zen :-)
> 
> So, wait till official patched Kernel (any time estimate)? 
> Or patch the kernel?
> 
> Cheers all.

As far as I can tell, the patch is already included since the 4.19.8

I can confirm the patch is included in 4.19.7 as well.

(In reply to Robert Munn from comment #103)
> I can confirm the patch is included in 4.19.7 as well.

AFAIK, patches aren't normally part of a kernel release...those are up to your distro.

So, it sounds like some distros are including this in their patchsets they apply, but I see no mention of this issue in any of the changelogs yet for mainline kernel releases.  This is one aspect of this bug tracking system I find frustrating...I don't see a link from the bug pointing to the release it is fixed in, and vice versa.  The bug tracking and release systems are not tied together as best I can tell.

In order to patch my distro, I had to recompile from source, and hand-create a patch using the edits in the last attachment in this thread.  My biggest hassle was the fact that I have a slow and flaky internet connection, and git is just a pile o' crap when it comes to dealing with that (no download resume support...).  I opted to download the source manually, then hack the MAKEPKG for Arch to skip the whole process.  I could have just directly hand-edited the source at that point, but still opted to just create a patch file, and edited MAKEPKG to pull in my custom file.

You then have to add it to your boot loader, etc., just like any other kernel build.

(In reply to m.kolesinski from comment #104)
> (In reply to Robert Munn from comment #103)
> > I can confirm the patch is included in 4.19.7 as well.
> 
> AFAIK, patches aren't normally part of a kernel release...those are up to
> your distro.
> 

Right, let me be more specific. I'm on Ubuntu 18.10, I downloaded the latest kernel debs from:

https://kernel.ubuntu.com/~kernel-ppa/mainline/

which at the time was 4.19.7. These are not the official kernels in the Ubuntu repo, but they are builds from the Ubuntu team. You have to download and install them yourself. I did that with 4.19.7. I was not expecting the patch to be included, but a couple of days later I touched the screen to wipe off a speck of dust and the page scrolled.

Still takes some work and I would not recommend it to a novice, but it's quite a bit easier (and far less time consuming) than compiling from source.

I've just updated to 4.19.9, verified the patch was included, and I'm now getting:

cmi: probe of SMB0001:00 failed with error -5

I'm running the latest bios, F.31 Rev.A for my hp envy x360 15z. Has anyone else encountered this? I'm wondering if I'm missing some kernel config setting or if this latest bios has changed the ACPI table?

(In reply to Seth Shelnutt from comment #106)
> I've just updated to 4.19.9, verified the patch was included, and I'm now
> getting:
> 
> cmi: probe of SMB0001:00 failed with error -5

That error can be safely ignored, the CMI device is not used on your laptop, 4.20 will have a patch silencing this error.

I can confirm 4.19 from Ubuntu works well with Ubuntu 8.10, I've been using it for a couple of days now, it's fast and stable as long as you don't try to suspend (which freezes the machine).

I suspect that there is a long way to go for proper ACPI states support, but that's a whole different ticket :-)

Thanks all!

it is now working with vanilla kernel 4.9.10 and BIOS F.19 :smile:

I have installed archlinux and kernel 4.19.11-arch1-1-ARCH on my HP ENVY x360 – 15-bq101ng. I also installed Gnome and Gnome-extra, but still my Stylus and touchscreen do not work. Can some one help me please ?
Thanks

(In reply to Thomas from comment #110)
> I have installed archlinux and kernel 4.19.11-arch1-1-ARCH on my HP ENVY
> x360 – 15-bq101ng. I also installed Gnome and Gnome-extra, but still my
> Stylus and touchscreen do not work. Can some one help me please ?
> Thanks

I now even installed Ubuntu 18.10 with kernel 4.19.11 through ukuu but it still not work.

Ok it work the problem was, that I start Windows 10 and restart the PC to Archlinux or Ubuntu. In Archlinux there is a log 'Disabling IRQ #7' when the bug appears, in the startup time.

My work around:
If I cam from Windows shutdown for 10s and then start Archlinux/Ubuntu and the Stylus and Touchscreen works.(In reply to Thomas from comment #111)
> (In reply to Thomas from comment #110)
> > I have installed archlinux and kernel 4.19.11-arch1-1-ARCH on my HP ENVY
> > x360 – 15-bq101ng. I also installed Gnome and Gnome-extra, but still my
> > Stylus and touchscreen do not work. Can some one help me please ?
> > Thanks
> 
> I now even installed Ubuntu 18.10 with kernel 4.19.11 through ukuu but it
> still not work.

Ok it work the problem was, that I start Windows 10 and restart the PC to Archlinux or Ubuntu. In Archlinux there is a log 'Disabling IRQ #7' when the bug appears, in the startup time.

My work around:
If I cam from Windows shutdown for 10s and then start Archlinux/Ubuntu and the Stylus and Touchscreen works.

I am observing similar problems with HP Spectre x360 15-df0850nz.

It does not boot without **acpi=noirq**. With *acpi=noirq*:

* Touchpad does not work
* Touchscreen or pen does not work
* Does not wake up after suspending
* Keyboard sometimes does not work, but will be fine again after reboot

Here is the dmesg log from kernel 4.18.0: https://alexandria.adynathos.net/d/2528a04f758c409c85c4/
I also tried kernel 4.20 from https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable but the problem persists.

There are bugs filed on some of these topics, but they do not seem to cover the IRQ booting problem:

* https://bugzilla.kernel.org/show_bug.cgi?id=201775
* https://bugzilla.kernel.org/show_bug.cgi?id=201885

I am new to ACPI errors, could you tell me how to proceed to best report or try to fix this?
Thank you.

(In reply to Adynathos from comment #113)
> I am observing similar problems with HP Spectre x360 15-df0850nz.
> 
> It does not boot without **acpi=noirq**. With *acpi=noirq*:
> 
> * Touchpad does not work
> * Touchscreen or pen does not work
> * Does not wake up after suspending
> * Keyboard sometimes does not work, but will be fine again after reboot
> 
> Here is the dmesg log from kernel 4.18.0:
> https://alexandria.adynathos.net/d/2528a04f758c409c85c4/
> I also tried kernel 4.20 from
> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable but
> the problem persists.
> 
> There are bugs filed on some of these topics, but they do not seem to cover
> the IRQ booting problem:
> 
> * https://bugzilla.kernel.org/show_bug.cgi?id=201775
> * https://bugzilla.kernel.org/show_bug.cgi?id=201885
> 
> I am new to ACPI errors, could you tell me how to proceed to best report or
> try to fix this?
> Thank you.

acpi=noirq disables any hardware that makes use of irqs like the touchscreen.
If you have a dual boot you could be affected by this https://bugzilla.kernel.org/show_bug.cgi?id=201817 which triggers a kernel panic when you reboot from windows(without a complete poweroff in between).

(In reply to Lukas Kahnert from comment #114)
> (In reply to Adynathos from comment #113)
> > I am observing similar problems with HP Spectre x360 15-df0850nz.
> > 
> > It does not boot without **acpi=noirq**. With *acpi=noirq*:
> > 
> > * Touchpad does not work
> > * Touchscreen or pen does not work
> > * Does not wake up after suspending
> > * Keyboard sometimes does not work, but will be fine again after reboot
> > 
> > Here is the dmesg log from kernel 4.18.0:
> > https://alexandria.adynathos.net/d/2528a04f758c409c85c4/
> > I also tried kernel 4.20 from
> > https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable but
> > the problem persists.
> > 
> > There are bugs filed on some of these topics, but they do not seem to cover
> > the IRQ booting problem:
> > 
> > * https://bugzilla.kernel.org/show_bug.cgi?id=201775
> > * https://bugzilla.kernel.org/show_bug.cgi?id=201885
> > 
> > I am new to ACPI errors, could you tell me how to proceed to best report or
> > try to fix this?
> > Thank you.
> 
> acpi=noirq disables any hardware that makes use of irqs like the touchscreen.
> If you have a dual boot you could be affected by this
> https://bugzilla.kernel.org/show_bug.cgi?id=201817 which triggers a kernel
> panic when you reboot from windows(without a complete poweroff in between).

Just as a side note, I am not dual booting and get the bug (201817) now and again. A couple of shutdowns are sometimes needed in order to fix it.

> acpi=noirq disables any hardware that makes use of irqs like the touchscreen.
> If you have a dual boot you could be affected by this https://bugzilla.kernel.org/show_bug.cgi?id=201817 which triggers a kernel panic when you reboot from windows(without a complete poweroff in between).

Thanks for the link but I am afraid this is not same problem.
My model has an intel CPU. I don't get the kernel panic message, nor the "IRQ nobody cared" message. 
New lines stop appearing after `intel-lpss - enabling device (0000 -> 0002)` (when IRQ is not disabled), maybe thats device is guilty.

(In reply to Thomas from comment #111)
> (In reply to Thomas from comment #110)
> > I have installed archlinux and kernel 4.19.11-arch1-1-ARCH on my HP ENVY
> > x360 – 15-bq101ng. I also installed Gnome and Gnome-extra, but still my
> > Stylus and touchscreen do not work. Can some one help me please ?
> > Thanks
> 
> I now even installed Ubuntu 18.10 with kernel 4.19.11 through ukuu but it
> still not work.

(In reply to Bráulio Bhavamitra from comment #109)
> it is now working with vanilla kernel 4.9.10 and BIOS F.19 :smile:

Thing is, it's not in the commit logs for any vanilla kernel, so perhaps you had a different problem.

To my knowledge this is not in the mainline kernel yet, I don't know what the holdup is.

Hello together,

im testing with a HP Envy13-ag0001ng with a AMD Ryzen 5 2500U and Vega 8.
I just tried to merge Lukas' patch into the latest 4.20 kernel. Has anyone already tried this or can tell me why it wouldn't work?


I freshly installed a Ubuntu 18.10 before i read this article. In Ubuntu 18.10 the touchstreen wasn't recognized at all with xinput.

I downloaded the linux kernel 4.20, merged Lukas' changes and built/installed it.

With xinput i get the ELAN0732:00 touchscreen listed as an input device but the touchscreen still doesn't work.

Don't hesitate to ask for logs or files. I've never been that deep in the matter to do changes with the kernel so excuse me if i'm missing an important point.

(In reply to Lukas Kahnert from comment #114)
--- snip ---
> acpi=noirq disables any hardware that makes use of irqs like the touchscreen.
> If you have a dual boot you could be affected by this
> https://bugzilla.kernel.org/show_bug.cgi?id=201817 which triggers a kernel
> panic when you reboot from windows(without a complete poweroff in between).

Not Windows dependent, not poweroff dependent. Whatever was done, the machine will not reliably boot. Sometimes works on first power up, sometimes has to be power cycled 2, 3, or more times.  Is this a regression caused by this patch or something else?

(In reply to JerryD from comment #119)
> (In reply to Lukas Kahnert from comment #114)
> --- snip ---
> > acpi=noirq disables any hardware that makes use of irqs like the
> touchscreen.
> > If you have a dual boot you could be affected by this
> > https://bugzilla.kernel.org/show_bug.cgi?id=201817 which triggers a kernel
> > panic when you reboot from windows(without a complete poweroff in between).
> 
> Not Windows dependent, not poweroff dependent. Whatever was done, the
> machine will not reliably boot. Sometimes works on first power up, sometimes
> has to be power cycled 2, 3, or more times.  Is this a regression caused by
> this patch or something else?

Try to boot with the psmouse.synaptics_intertouch=1 kernel param. This (and reporting it as a bug) is what the log file recommends when booting up with working touchpad.

FYI, this patch seems to be in the Arch disto now (not sure when, or if it's in mainline...this bug tracking system doesn't tell you squat about that).

I just did a full sys upgrade to 4.20.12-arch1-1-ARCH (been holding off, since I had my patched kernel working), and the touchscreen works without a custom kernel build!

I can confirm that the fix is in Kubuntu 19.04 (and Ubuntu) with kernel 5.0.0-13-generic.

Works without a custom kernel build like the commented above.

Touchscreen still not working out of the box for HP ENVY x360 15m-bq021dx (AMD FX-Series FX-9800P) on Ubuntu 19.04. Kernel 5.0.0-15-generic.

I'm sorry to report that this bug is not resolved for the HP Envy x360 edition I have: Hardware name: HP HP ENVY x360 Convertible 13-ag0xxx/8496, BIOS F.35 04/02/2019. This model sports an AMD Ryzen 7 2700U paired with an AMD Radeon RX Vega 10.

I've tested this hardware with Kubuntu 19.04 given this comment, https://bugzilla.kernel.org/show_bug.cgi?id=198715#c122, the current Fedora Workstation 30 kernel as well as the Arch Linux 5.1.5 kernel. In all cases the touch screen remains non-functional.

The typical dmesg entry:

[   10.728105] irq 7: nobody cared (try booting with the "irqpoll" option)
[   10.728110] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.0.9-301.fc30.x86_64 #1
[   10.728111] Hardware name: HP HP ENVY x360 Convertible 13-ag0xxx/8496, BIOS F.35 04/02/2019
[   10.728112] Call Trace:
[   10.728115]  <IRQ>
[   10.728123]  dump_stack+0x5c/0x80
[   10.728128]  __report_bad_irq+0x35/0xa7
[   10.728131]  note_interrupt.cold+0xb/0x63
[   10.728133]  handle_irq_event_percpu+0x6f/0x80
[   10.728135]  handle_irq_event+0x28/0x48
[   10.728138]  handle_fasteoi_irq+0x86/0x130
[   10.728141]  handle_irq+0xbf/0x100
[   10.728144]  do_IRQ+0x4b/0xe0
[   10.728146]  common_interrupt+0xf/0xf
[   10.728148]  </IRQ>
[   10.728152] RIP: 0010:cpuidle_enter_state+0xc4/0x450
[   10.728154] Code: e8 c1 34 95 ff 80 7c 24 0f 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 61 03 00 00 31 ff e8 13 e6 9a ff fb 66 0f 1f 44 00 00 <45> 85 e4 0f 88 8c 02 00 00 49 63 cc 4c 2b 6c 24 10 48 8d 04 49 48
[   10.728155] RSP: 0018:ffffb99b80da7e88 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffdb
[   10.728158] RAX: ffff9477d7d60fc0 RBX: ffffffff8e2d8a80 RCX: 000000000000001f
[   10.728158] RDX: 0000000000000000 RSI: 000000003a3d894c RDI: 0000000000000000
[   10.728159] RBP: ffff9477d60c5800 R08: 000000027f71bac7 R09: 0000000000000002
[   10.728160] R10: 00000010f106a1ae R11: ffff9477d7d5fe44 R12: 0000000000000002
[   10.728161] R13: 000000027f71bac7 R14: 0000000000000002 R15: ffffffff8e2d8a80
[   10.728164]  ? cpuidle_enter_state+0x9f/0x450
[   10.728167]  do_idle+0x1dd/0x260
[   10.728170]  cpu_startup_entry+0x19/0x20
[   10.728174]  start_secondary+0x1a7/0x200
[   10.728177]  secondary_startup_64+0xa4/0xb0
[   10.728179] handlers:
[   10.728184] [<00000000d2b11251>] amd_gpio_irq_handler [pinctrl_amd]
[   10.728185] Disabling IRQ #7

(In reply to James from comment #123)
> Touchscreen still not working out of the box for HP ENVY x360 15m-bq021dx
> (AMD FX-Series FX-9800P) on Ubuntu 19.04. Kernel 5.0.0-15-generic.

After an accidental reboot into Linux, touchscreen and tablet mode are now working for multiple days. Maybe somebody else can delve into why it's not working for some on live media and fresh installs (tried Arch and Fedora live disks). To clarify, I updated and restarted after the install to no avail. Unfortunately this was the first time I had tried the touchscreen since then, so I don't know when it would have started working. It is like booting into Windows and back into Linux fixed whatever the problem was.

Possible relationship between this bug and the one linked here:

https://bugzilla.kernel.org/show_bug.cgi?id=201817

Regarding that possible relationship absolutely right - if anyone on this bug is still following, there is an updated patch attached to https://bugzilla.kernel.org/show_bug.cgi?id=201817#c92

It would be good if someone who was affected by this bug could confirm that patch still helps and doesn't cause further problems.

* If you can check and it causes problems please speak up there.
* If you can check and it doesn't cause problems, I would appreciate a comment there and a
     Tested-by: User Name <user.name@email.com>  
clause that I can include in the patch to submit it upstream and have a way to refer back if further problems stem from it.