Ubuntu 15.10 HP Envy x360 Сенсорный экран не работает после выхода из режима ожидания

1417
Sion

У меня есть ноутбук HP Envy x360 при начальной загрузке, сенсорный экран работает. но после приостановки сенсорный экран больше не работает. В некоторых исследованиях я считаю, что ответственным за это является модуль hid_multitouch. Перезагрузка модуля через rmmod hid_multitouch && modprobe hid_multitouch(как суперпользователя конечно), похоже, не влияет на проблему.

lspci: http://pastebin.com/AGkiSp5L lsusb: http://pastebin.com/RNnahs11

Кажется, я даже не могу найти устройство через lsusb или lspci. Какими еще способами я смогу идентифицировать устройство? Есть ли дополнительный модуль, который необходимо будет одновременно перезагружать?

2

1 ответ на вопрос

1
nimda

If running sudo rmmod hid_multitouch after a reboot disables your touchscreen try this: 

su -c "echo "SUSPEND_MODULES="hid_multitouch"" >> /etc/pm/config.d/modules"

This will unload that module prior to suspend, hopefully fixing your problem.

If that's not the case, run xinput --list while the touchscreen is working and when the touchscreen is not working, compare the output, if something is missing when you resume from a suspend, you'll have to re.

Example output:

⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ ITE Tech. Inc. ITE Device(8595) id=11 [slave pointer (2)] ⎜ ↳ ITE Tech. Inc. ITE Device(8595) Touchpad id=12 [slave pointer (2)] ⎜ ↳ SYNA7508:00 06CB:77B2 id=14 [slave pointer (2)]

My touchscreen device is SYNA7508:00 06CB:77B2 id=14

Try running xinput set-prop DEVICE_ID "Device Enabled" 0 && xinput set-prop DEVICE_ID "Device Enabled" 1 replacing the ID with your device ID post suspend.

If that command fixes it, try replacing it with the rmmod&&modprobe found here (dont forget to chmod u+x the file making it executable): https://bugs.launchpad.net/ubuntu/+source/xinput/+bug/1275416/comments/28 However, if the device does not show up after suspend, you'll have to reattach it, here's another example: https://bugs.launchpad.net/ubuntu/+source/xinput/+bug/1275416/comments/19

(Очевидно, я никогда не замечал, что получил ответ на этот вопрос. Упс.) Трюк с приостановкой не сработал, но я запустил diff для файлов xinput и получил его обратно. Http://pastebin.com/UCN2xv5j Оставшись после приостановки и правый пост загрузки. Единственное, что выглядит иначе - это порядок тачпада и тачскрина. Я даже попробовал трюк с отключением / включением как на сенсорном экране, так и на своем «пером». Sion 7 лет назад 0
Я чувствую вашу боль, какое ядро ​​вы используете? У меня была похожая проблема на ядрах до 4.0. Кроме того, извините, я не понял, что вы упомянули, что rmmod hid_multitouch не помогает в вашем вопросе: P nimda 7 лет назад 0
Похоже, я использую "4.4.8-040408-generic", так что это решает потенциал ядра до 4.0. (Если бы люди не могли легко пропустить вещи, мир был бы скучным.) Sion 7 лет назад 0
Хм, неужели `rmmod hid_multitouch` мешает работе вашего сенсорного экрана и мыши? Также не могли бы вы опубликовать свои журналы, связанные с сенсорным экраном. Я не эксперт, но я думаю: `grep -iER" synaptic | hid_multitouch "/ var / log / *` должен работать, если это правильный модуль. nimda 7 лет назад 0
Да, похоже, что rmmod hid_multitouch снимает сенсорный экран при новой загрузке, а затем modprobe hid_multitouch с радостью возвращает его обратно. (мышь / тачпад не зависит от выгрузки и загрузки модуля hid_multitouch) Вывод из grep meaty, много данных. Я даже не уверен, как начать сортировку по нему, что вы ищете ?: http://pastebin.com/ 7wtLZtfU Sion 7 лет назад 0
Хорошо. Я надеялся найти ошибку pm-util. Оказывается, `/ etc / pm / suspend.d` нельзя использовать. Возможно, вы захотите попробовать http://askubuntu.com/a/615384/583129, но замените `ExecStart = / bin / systemctl restart network-manager.service` на` ExecStart = / bin / rmmod hid_multitouch && / bin / modprobe hid_multitouch` nimda 7 лет назад 0
В другом случае pm-utils неправильно читает файл модулей из-за проблем с разрешениями. Это можно исправить с помощью `chmod 777 / etc / pm / config.d / modules` или правильных привилегий, если вы не ленивы,` + rw`, я думаю? nimda 7 лет назад 0
Проверьте права доступа к файлу `/ etc / pm / config.d / modules` и, как следует, у root есть RW, а у всех остальных есть права на чтение. Создание предложенного сценария systemd, по-видимому, не имело никакого эффекта из-за снятия и перезапуска модуля перед его приостановкой (насколько я понимаю), создала новый здесь: http://pastebin.com/DWMaBRWp, который должен его удалить перед приостановить и вернуть его после возобновления. К сожалению, это тоже не оказало никакого влияния. Sion 7 лет назад 0
Черт. Я действительно надеялся, что это сработает. Ну, у меня заканчиваются идеи. Вы пытались вживую загрузиться с debian, linux mint, fedora и т. Д.? Или попытался сделать ловушку PM-Suspend? nimda 7 лет назад 0
Черт!. У меня давно закончились идеи. Я полагаю, я мог бы загрузить Live и посмотреть, отличаются ли модули или список xinput, но это было бы все, что я мог сделать. С этого момента похоже, что модуль может быть поврежден при приостановке (или что-то ...). Придется попробовать ловушку pm-suspend, но я думаю, что systemd по крайней мере на ubuntu игнорирует то, что говорит pm-utils. Sion 7 лет назад 0

Похожие вопросы