[HP ENVY x360 - 15-bq102ng] Touchscreen does not work

Bug #1752437 reported by Marc Rene Schädler on 2018-02-28
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Low
Unassigned

Bug Description

The touch screen on my HP ENVY x360 15-bq102ng does not work with stock kernel or with mainline kernel 4.16-rc3.

marc@snapbug:~$ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Video Bus id=7 [slave keyboard (3)]
    ↳ Video Bus id=8 [slave keyboard (3)]
    ↳ Power Button id=9 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
    ↳ HP Wireless hotkeys id=14 [slave keyboard (3)]
    ↳ HP WMI hotkeys id=15 [slave keyboard (3)]
    ↳ HP Wide Vision FHD Camera: HP I id=11 [slave keyboard (3)]
    ↳ HP Wide Vision FHD Camera: HP W id=10 [slave keyboard (3)]

WORKAROUND: Use the patch labeled "possible fix for touchscreen" with 4.17-rc3:
https://bugzilla.kernel.org/attachment.cgi?id=275381

from upstream report:
https://bugzilla.kernel.org/show_bug.cgi?id=198715

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: xorg 1:7.7+19ubuntu3
Uname: Linux 4.16.0-041600rc2-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
BootLog:
 No key available with this passphrase.
 /dev/mapper/nvme0n1p2_crypt: clean, 621596/15597568 files, 54013381/62389248 blocks
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Wed Feb 28 22:34:50 2018
DistUpgraded: Fresh install
DistroCodename: artful
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:15dd] (rev c4) (prog-if 00 [VGA controller])
   Subsystem: Hewlett-Packard Company Device [103c:83c6]
InstallationDate: Installed on 2018-01-16 (42 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
MachineType: HP HP ENVY x360 Convertible 15-bq1xx
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.16.0-041600rc2-generic root=UUID=415eb027-1fd5-4b75-9860-5cac88a630db ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/26/2018
dmi.bios.vendor: AMI
dmi.bios.version: F.16
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 83C6
dmi.board.vendor: HP
dmi.board.version: 63.18
dmi.chassis.type: 31
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAMI:bvrF.16:bd01/26/2018:svnHP:pnHPENVYx360Convertible15-bq1xx:pvr:rvnHP:rn83C6:rvr63.18:cvnHP:ct31:cvrChassisVersion:
dmi.product.family: 103C_5335KV HP Envy
dmi.product.name: HP ENVY x360 Convertible 15-bq1xx
dmi.sys.vendor: HP
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.85-4~a~padoka0
version.libgl1-mesa-dri: libgl1-mesa-dri 1:17.3.2-0~a~padoka0
version.libgl1-mesa-glx: libgl1-mesa-glx 1:17.3.2-0~a~padoka0
version.xserver-xorg-core: xserver-xorg-core 2:1.19.5-0ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.10.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20170309-0ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2

Created attachment 274057
dmesg output after boot

I have an HP Envy x360 with a ryzen 5 2500U processor and I am running kernel 4.15.0-staging. When I am running windows 10 my touchscreen does work, and is detected as a hid-compliant touchscreen. I was able to pull some driver information from windows event viewer. It looks like windows is using the following driver: HID\ELAN0732&Col01\4&2e44c06e&0&0000 .
I have been communicating with people at the wacom-hid-descriptors repository and was advised that this is a kernel issue.
It does seem like the kernel can see my devices at
/sys/devices/platform/AMDI0010:00/i2c-0/i2c-ELAN0732:00 and
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/AMDI0010:00/ELAN0732:00 .
however even after loading the hid-touchscreen module, the i2c-hid module, and the elants-i2c module my touchscreen is not working.
I do have some ACPI errors in my dmesg log (attached) but I am not sure they are related. Let me know if there is additional information I can get you.

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
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
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.

18 comments hidden view all 131 comments
Marc Rene Schädler (suaefar) wrote :
19 comments hidden view all 131 comments

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

summary: - Touchscreen on HP ENVY x360 15-bq102ng does not work
+ [HP ENVY x360 - 15-bq102ng] Touchscreen does not work
description: updated
18 comments hidden view all 131 comments

Marc Rene Schädler, thank you for reporting this and helping make Ubuntu better.

Given I'm not seeing evidence of touchscreen recognition, for now I'll move to linux for further review.

While waiting, it is best to continually test the latest mainline kernel (now 4.16-rc6) as it becomes released, and report back the results.

affects: xorg (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: Undecided → Medium

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
18 comments hidden view all 131 comments

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
DMESG output after boot on 4.16 (drm-next)

18 comments hidden view all 131 comments
Marc Rene Schädler (suaefar) wrote :

The device seems to be a "ELAN0732".

There were attempts to include the missing bits already which, however, was not successful [1].

[1] https://www.spinics.net/lists/linux-input/msg50518.html

Kai-Heng Feng (kaihengfeng) wrote :

This is the reason why your touchpad doesn't work:
[ 0.948213] amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
[ 0.948487] amd_gpio: probe of AMDI0030:00 failed with error -22

Marc Rene Schädler (suaefar) wrote :

Thank you for pointing out the reason.

Is there anything I can do about it?
Report another bug?

Marc Rene Schädler (suaefar) wrote :

Thanks, I tried it.

marc@snapbug:~$ uname -a
Linux snapbug 4.15.0-14-generic #15~lp1752437 SMP Thu Mar 29 17:32:02 CST 2018 x86_64 x86_64 x86_64 GNU/Linux

However the error is still there and the touchpad does not work:

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

I attached the full output of dmesg.
Would the Differentiated System Description Table of any help?

There is also an interesting discussion on kernel.org about this issue [1].

[1] https://bugzilla.kernel.org/show_bug.cgi?id=198715#c6

Quentin Iorio (qman) wrote :

This problem also affects me. I have a similar model HP ENVY x360 15-bq0xx

Linux fireball-x360 4.13.0-38-generic #43-Ubuntu SMP Wed Mar 14 15:20:44 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Same gpio error:

[ 0.989418] amd_gpio AMD0030:00: Failed to get gpio IRQ.
[ 0.989500] amd_gpio: probe of AMD0030:00 failed with error -22

Entire dmesg is attached.

I would be more than willing to help in debugging.

Kind regards

14 comments hidden view all 131 comments

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
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
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
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
"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 <email address hidden> 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.

tags: added: bios-outdated-f.17 kernel-bug-exists-upstream-4.16-rc1 needs-upstream-testing
description: updated
29 comments hidden view all 131 comments
Marc Rene Schädler (suaefar) wrote :

Which BIOS is the most recent?
I thought ist was: F.17 Rev.A from 11. Apr. 2018 (17.7 MB)

Luya Tshimbalanga (luya) wrote :

The issue affects all distributions running on HP touchscreen laptop powered with AMD processors. The culprit is a misconfiguration of ACPI table impacting the touchscreen function. Some users attempted to workaround the problem but needed input from upstream.

no longer affects: fedora
Changed in kernel:
importance: Unknown → Medium
status: Unknown → Confirmed
80 comments hidden view all 131 comments

(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 <email address hidden>
Tested-by: Marc <email address hidden>

Download full text (3.2 KiB)

(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@...

Read more...

(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?

1 comments hidden view all 131 comments

(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 <email address hidden>
> Tested-by: Marc <email address hidden>

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 <email address hidden>
> Tested-by: Marc <email address hidden>

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.

Changed in kernel:
status: Confirmed → Fix Released

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.

1 comments hidden view all 131 comments

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.

description: updated

Marc Rene Schädler, as per upstream https://bugzilla.kernel.org/show_bug.cgi?id=198715#c97 a patch was merged upstream. Hence, to confirm your issue is resolved upstream, could you please revert any custom patched kernels, and test https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.8/ (no custom patches) and advise to the results?

if resolved, then when Ubuntu 18.10 rebases to kernel 4.19 as per https://launchpad.net/ubuntu/+source/linux you would be able to upgrade for resolution.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
1 comments hidden view all 131 comments

(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.

no longer affects: linux (Ubuntu)
affects: kernel → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: Medium → Undecided
status: Fix Released → New
importance: Undecided → Low
status: New → Incomplete
Kai-Heng Feng (kaihengfeng) wrote :

Does this still happen on an up-to-date system?

Displaying first 40 and last 40 comments. View all 131 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.