| Summary: | РОСА Хром 12.7 х86_64 - Ноутбук Позитрон Проксима 15 ЛНФТ. 466226.002 тачпад глюк | ||
|---|---|---|---|
| Product: | [ROSA-based products] ROSA Fresh | Reporter: | AleXandr <a.avdonin> |
| Component: | Hardware-specific, drivers | Assignee: | Mikhail Novosyolov <m.novosyolov> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | v.potapov |
| Priority: | Normal | ||
| Version: | Plasma5 | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Platform: | --- | ROSA Vulnerability identifier: | |
| RPM Package: | Upstream: | ||
| Attachments: | Патч в апстрим v1 | ||
|
Description
AleXandr
2026-02-17 15:51:37 MSK
Проверь, пожалуйста, утверждения производителя про 6.6 )) Ядро 6.12 обновлял до последней версии в репах (6.12.47-5)? (Ответ для Mikhail Novosyolov на комментарий #1)
> Проверь, пожалуйста, утверждения производителя про 6.6 ))
> Ядро 6.12 обновлял до последней версии в репах (6.12.47-5)?
Миш, я писал, что проверил на 6.6 - такая же ситуация.
Ядро 6.12 не обновлял, т.к. смотрел на Fedora 43 с ядром 6.17
Саш, смотри, что нужно, чтобы ты проверил. Я, честно говоря, так толком и не понял, что ты проверил)) 1. 6.6. версии, что была из коробки в 12.6 2. 6.6 актуальной версии 3. 6.12 актуальной версии (а не та, что в 12.7 из коробки) Ядра разных версий есть в https://mirror.rosa.ru/repo-archive/ Мы просто исправляли регрессию, возникшую в 6.6.х и в 6.12.х, которой раньше в 6.6 не было. Может, это она и есть,а, может, и нет. И 6.1 актуальной версии из репозитория можно проверить Проверил на Хром 12.6 (6.6.47) - тачпад номально включается и отключается по сочетанию клавиш Fn+F5, но при этом на экран не выводится картинка об отключении/включении, просто срабатывает и все. Проверил так же на Хром 13 - поведение такое же как на Хром 12.7 (6.12.47). А на 6.12.47 какое поведение? На 6.12.47 корректно не работает, как в описании в первом посте. Мы с Александром выяснили, что: 1. 12.6 (6.6.47 - из коробки - работает) 2. 12.7 (6.6.106 - не работает) 3. 12.7 (6.12.47 - не работает) Нужно проверить 6.6.78, 6.6.94 из repo-archive. Проверил сам. 6.6.27 - норм 6.6.47 - норм 6.6.78 - в gdm норм, в kde нет 6.6.94 - в gdm норм, в kde нет То есть сломалось между 6.6.47 и 6.6.78 6.18.xm1 (xanmod) - gdm норм, kde нет Значит ищем проблему между 6.6.47 и 6.6.78 6.6.52 (https://abf.io/build_lists/5547944) - норм 6.6.77 (https://abf.io/build_lists/5547945 ) - уже нет. Ищем между 6.6.52 и 6.6.77 6.6.64 (https://abf.io/build_lists/5547954) - норм. Ищем между 6.6.64 и 6.6.77 6.6.70 (https://abf.io/build_lists/5548408) - норм. Ищем между 6.6.70 и 6.6.77. 6.6.74 (https://abf.io/build_lists/5548415) - норм. Остается попробовать 6.6.75 и 6.6.76. 6.6.75 (https://abf.io/build_lists/5548416) - плохо. 6.6.75 - первое сломанное ядро. Под Wayland на 6.6.74 тачпад не работает вообще, в dmesg при нажатии Fn+F5: [Ср фев 18 02:55:32 2026] atkbd serio0: Unknown key pressed (translated set 2, code 0x6e on isa0060/serio0). [Ср фев 18 02:55:32 2026] atkbd serio0: Use 'setkeycodes 6e <keycode>' to make it known. На 6.6.75 и 6.6.х новее и на 6.18 в dmesg такого нет, но тачпад не работает. На 6.6.74 и ниже в dmesg такое есть. Очень интересно. Похоже, что это коммит https://github.com/gregkh/linux/commit/dc8c9c171ef3285ac62589c6faef0bf4d5e6b29b . Надо проверить. Собрал ядро 6.6.106-4 с откаченным коммитом https://github.com/gregkh/linux/commit/dc8c9c171ef3285ac62589c6faef0bf4d5e6b29b https://abf.io/build_lists/5548418 Проблема ушла, теперь в X11 тачпад корректно отключается и включается. Начиная с ядра 6.17, есть дальнейшие правки на эту тему: https://github.com/gregkh/linux/commit/17eabb792740cea3f24b236e150f9fee8cd344f3 Большой вопрос, сколько разных ноутбуков затрунуло это изменение... В ядре 6.6 сделаем просто откат коммита, а вот в более новых ядрах - надо думать. Проверил на rosa13 + KDE 6 + X11 + 6.12, все то же самое. Еще ему нужна более новая linux-firmware, ее как раз пора обновить. *********** QA ADVISORY *********** kernel-6.6 6.6.126-1 - updated from 6.6.106 to 6.6.126 - reverted regressive commit rosa2021.1 https://abf.io/build_lists/5548433 https://abf.io/build_lists/5548434 rosa13 https://abf.io/build_lists/5548431 https://abf.io/build_lists/5548432 ********************************** linux-firmware 2-23.git3a0e2.20260214.1 - updated snapshot rosa2021.1 https://abf.io/build_lists/5548480 https://abf.io/build_lists/5548481 https://abf.io/build_lists/5548482 rosa13 https://abf.io/build_lists/5548476 https://abf.io/build_lists/5548477 https://abf.io/build_lists/5548478 ********************************** Created attachment 6343 [details]
Патч в апстрим v1
Отправил в апстрим патч, который исправляет проблему для конкретного ноутбука. Подождем реакции, но, скорее всего, применим такой подход для новых ядер и будем проблемные железки вручную вносить в список.
Описывал суть проблемы словами попроще, скопирую судя для истории. Нажатие кнопки Fn на этом ноуте выдает код клавиши 0x6e - F23. Зачем - непонятно, в биосе что-то наворочено. Майкрософт недавно решили, что было бы хорошо использовать F23, который никем не используется (на клавиатурах вообще только F1-F12), для клавиши вызова их помощника с искусственным интеллектом Copilot. На некоторых ноутбуках появилась такая клавиша (возможно, нужно нажать Fn+какую-то другую клавишу). Не знаю, зачем кому-то понадобилось изнутри линукса ловить событие ее нажатия, видимо, чтобы можно было использовать для чего-то более полезного (привязать к выполнению какого-то действия) или для вызова ИИ-помощника в каком-нибудь китайском Deepin Linux. Но поскольку F23 ранее никогда не использовалась, в ядре ОС, т.е. в ядре Linux, в, грубо говоря, драйвере клавиатуры, не была предусмотрена F23. Ее добавили простым изменением: https://github.com/gregkh/linux/commit/dc8c9c171ef3285ac62589c6faef0bf4d5e6b29b Перенесли эту правку в стабильные ядра, в т.ч. в обновления ядра 6.6.х, начиная с 6.6.75. Получилось, что раньше на этом ноутбуке нажатие Fn выдавало никому непонятный код 0x6e, ОС просто писала в лог ядра, что пришло событие нажатия непонятной клавиши, а теперь начала понимать, и то, что случайно работало раньше в условиях кривого биоса, перестало работать. Пока для ядра 6.6. просто откатил это изменение. (In reply to Mikhail Novosyolov from comment #25) > *********** QA ADVISORY *********** > > kernel-6.6 6.6.126-1 > - updated from 6.6.106 to 6.6.126 > - reverted regressive commit > > rosa2021.1 > https://abf.io/build_lists/5548433 > https://abf.io/build_lists/5548434 > > rosa13 > https://abf.io/build_lists/5548431 > https://abf.io/build_lists/5548432 > ********************************** > > linux-firmware 2-23.git3a0e2.20260214.1 > - updated snapshot > > rosa2021.1 > https://abf.io/build_lists/5548480 > https://abf.io/build_lists/5548481 > https://abf.io/build_lists/5548482 > > rosa13 > https://abf.io/build_lists/5548476 > https://abf.io/build_lists/5548477 > https://abf.io/build_lists/5548478 > ********************************** Обновления linux-firmware в другом баге, в этом оставляем только kernel-6.6 (In reply to AleXandr from comment #0) > # cat /etc/udev/hwdb.d/99-fn-fix.hwdb > -------------- > # Отключаем обработку Fn (F23) на системной клавиатуре > evdev:input:b0011v0001p0001* > KEYBOARD_KEY_6e=unknown # сканкод 0x6e (Fn) игнорируем > KEYBOARD_KEY_7005e=unknown # альтернативный сканкод если не сработает > -------------- Теперь в systemd hwdb будет так: https://github.com/systemd/systemd/commit/9aad3336ff0174428a8a1ee138190b6d5122af81 *** This bug has been marked as a duplicate of bug 19983 *** systemd с обновлением базы hwdb, чтобы этой проблемы не было и на 6.12, в баге https://bugzilla.rosa.ru/show_bug.cgi?id=20016 для rosa13 И для rosa2021.1 systemd здесь: https://bugzilla.rosa.ru/show_bug.cgi?id=20052 Ядро 6.6 с откатом регрессивного коммита здесь: https://bugzilla.rosa.ru/show_bug.cgi?id=19983 systemd правится, чтобы работало и без отката регрессивного коммита в ядре. |