Bàn phím không hoạt động sau khi tắt máy (ASUS Zenbook 13 OLED UM325S)

Tôi vừa cài đặt Ubuntu 20.04 trên ASUS Zenbook 13 OLED UM325S mới của mình.

Bàn phím không hoạt động sau khi khởi động nguội. Bàn phím sẽ bắt đầu hoạt động trong lần khởi động tiếp theo, nếu thiết bị được khởi động lại ở giai đoạn Cryptsetup trở lên. Cryptsetup cũng bị ảnh hưởng, vì vậy không thể truy cập cài đặt được mã hóa nếu không có bàn phím ngoài.

mục grub của tôi; GRUB_CMDLINE_LINUX_DEFAULT="giật gân yên tĩnh"

Khám phá được thực hiện

1. serio_raw mô-đun hạt nhân không tải khi bạn khởi động nguội. Khám phá được thực hiện trong này ý chính.
2. Bàn phím AT Translated Set 2 là bàn phím máy tính xách tay. Điều này không hiển thị sau khi khởi động nguội mà là sau khi khởi động lại. Ý chính ở đây.
3. Tôi không thể sử dụng xinput để quản lý các thuộc tính của thiết bị như đề xuất của @ Sancho.s trong câu trả lời bên dưới. Đôi khi xinput không hiển thị bất kỳ bàn phím nào được đính kèm, nó chỉ hiển thị các thiết bị ảo. libinput mặt khác, hiển thị đúng tất cả các thiết bị.
4. WMI Các phím nóng của ASUS đang hoạt động, vì vậy đôi khi tôi thấy các điều chỉnh độ sáng, âm thanh, v.v. hoạt động khi F1-F12 được sử dụng kết hợp với phím fn Chìa khóa.

Nỗ lực để làm cho nó hoạt động

1. Tôi đã tải lực lượng serio_raw cả hai sử dụng initramfs và tải-mô-đun.d không thành công. Tải mô-đun, nhưng không ảnh hưởng đến vấn đề bàn phím.
2. đã thử chạy xinput set-prop "Bàn phím AT Translated Set 2" "Đã bật thiết bị" 1 tuy nhiên, xinput không tìm thấy thiết bị.

Cách giải quyết lúc này là kết nối bàn phím ngoài, đợi Cryptsetup bắt đầu rồi nhấn CTRL+ALT+DEL rồi khởi động bình thường. Nếu tôi khởi động lại từ GRUB, nó không có tác dụng.

Cảm ơn

Tôi sẽ xây dựng trên công việc tốt của bạn xác định sự khác biệt giữa "điều kiện làm việc" (WKC) và "điều kiện không làm việc" (NWC).
Ghi chú: Tôi ngạc nhiên là bạn phải làm bất kỳ điều gì được gợi ý bên dưới, nhưng nếu nó hiệu quả... thì tốt cho bạn.

Bạn có thể cần phải buộc tải mô-đun một cách rõ ràng serio_raw qua hệ thống lúc khởi động. Hãy thử thêm nó vào /etc/mô-đun (nguồn). Hoặc tạo tập tin /etc/modules-load.d/serio_raw.conf có chứa serio_raw. Khởi động nguội và đăng phản hồi (điều này ảnh hưởng như thế nào đến sự khác biệt mà bạn đã tìm thấy trước đây? xem cái này để kiểm tra việc chèn mô-đun).

Nếu bạn cần tải mô-đun trước đó (bạn đề cập đến "cryptsetup đang yêu cầu mật khẩu của tôi trên ổ đĩa được mã hóa của tôi"), trong khi tải khởi động với ban đầu, bạn có thể dùng công cụ initramfs hoặc bản nháp. Cái này và cái này có thể giúp. Xem thêm thông tin chính thức, hoặc cái này.

Nếu điều đó một mình không hoạt động, giả sử khi bạn thực hiện danh sách xin nhập Dưới WKC không có bàn phím ngoài, Bàn phím AT Translated Set 2 là bàn phím bên trong (nguồn).

Thêm tự động thực thi lệnh

$ xinput list-props "Bàn phím AT Translated Set 2"

khi khởi động để xem nếu bạn nhận được một cái gì đó như

Thiết bị 'Bàn phím AT Translated Set 2':
    Thiết bị đã bật (124): 0
    ...

khi khởi động nguội. Nếu vậy, hãy thêm tự động thực thi lệnh

$ xinput set-prop "Bàn phím AT Translated Set 2" "Đã bật thiết bị" 1

và khởi động lạnh một lần nữa. Xin vui lòng gửi thông tin phản hồi.

Bạn cũng có thể kiểm tra trạng thái hệ thống của mình trong NWC qua sshnhập vào nó. Có lẽ điều này "ít xâm phạm" hơn so với việc sử dụng bàn phím ngoài nếu xét về cấu hình bàn phím.

Có liên quan:

1. https://unix.stackexchange.com/questions/89538/how-to-tell- which-keyboard-was-used-to-press-a-key

Câu hỏi của bạn chỉ ra rằng nhân Linux hoàn toàn không phát hiện ra bàn phím. Nó dường như không chỉ liên quan đến X-Server. Nếu không, bạn có thể nhập mật khẩu để giải mã đĩa hoặc trên thiết bị đầu cuối ảo.

Mặc dù ngày nay bàn phím máy tính để bàn thường được kết nối qua USB, nhưng bàn phím máy tính xách tay có thể đặc biệt. Ví dụ, bàn phím của bàn phím DELL Precision 5520 của tôi được kết nối với bộ điều khiển Bàn phím i8042 của chip SuperIO. Đây thường là trường hợp của bàn phím AT- cũng như PS/2 tiêu chuẩn. Nếu nó được biên dịch thành một mô-đun, thì mô-đun đó sẽ được gọi là "i8042". Tuy nhiên, Ubuntu biên dịch serio_i8042 trực tiếp vào kernel (xem: https://kernel.ubuntu.com/~kernel-ppa/config/hirsute/linux/5.10.0-14.15/amd64-config.flavour.generic ).

Nếu bạn tìm kiếm i8042 và "Zenbook", dường như có vấn đề đã biết với trình điều khiển và Zenbooks liên quan đến việc Zenbooks đã vô hiệu hóa tính năng tự kiểm tra i8042. Điều này từng gây ra sự cố với bàn phím sau khi tạm dừng/tiếp tục.Lần đầu tiên sự cố này được vá với cam kết 77b425399f6d vào năm 2016 và gần đây đã có một bản vá khắc phục sự cố này cho Zenbook Flip với Kernel 5.4.243 (xem: https://lore.kernel.org/lkml/[email protected]/ ). Có vẻ như bản vá Convertible đã hỏng thứ gì đó trước Kernel 5.11.057 đã được sửa vào tháng 3 năm 2021. ( https://lore.kernel.org/lkml/[email protected]/ ). Ubuntu của tôi hiện đang chạy Kernel 5.11.0-34, điều đó có nghĩa là nó vẫn gặp sự cố này - kernel của bạn cũng vậy. Tôi khuyên bạn nên thử cập nhật lên kernel mới hơn và xem điều này có khắc phục được sự cố của bạn không.

Bạn có thể tải xuống các gói .deb cho kernel sau này từ: https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D - hoặc bạn có thể sử dụng công cụ chính để cài đặt kernel mới hơn:

Sudo add-apt-repository ppa:cappelikan/ppa
cập nhật sudo apt
sudo apt cài đặt dòng chính
sudo mainline --install-latest

Sau đó, bạn phải khởi động lại và chọn Kernel gần đây nhất từ ​​bộ tải khởi động của mình (thường là grub).

Nếu sự cố liên quan đến kernelbug, bàn phím của bạn sẽ hoạt động. bạn cũng có thể xem /proc/bus/input/devices để xem bàn phím của bạn có hiển thị ở đó không.

Có một lỗi hạt nhân một vài phiên bản trở lại điều đó sẽ ảnh hưởng đến một số bàn phím máy tính xách tay. Mặc dù bản sửa lỗi đã được phát hành cho 5.8.0-20, đây có thể là một con đường để khám phá.

Thử cái này:

0. Mở Terminal (nếu chưa mở)
1. Xác định loại khung máy của bạn:

   mèo /sys/class/dmi/id/chassis_type
   

   Nếu giá trị là 31 hoặc 32, bỏ qua phần còn lại của câu trả lời này.
2. Kiểm tra xem nếu intel_vbtn Nó đã nạp đầy:

   sudo dmesg | grep intel-vbtn
   

   Nếu không có đầu ra, bỏ qua phần còn lại của câu trả lời này.
3. Trong trường hợp bạn đã đi xa đến mức này, giải pháp có thể là chặn intel_vbtn từ được tải:

   1. Tạo một tệp mới trong /etc/modprobe.d:

      sudo vi /etc/modprobe.d/intel-vbtn.conf
      

      ^{Ghi chú: Vui lòng sử dụng trình soạn thảo văn bản bạn chọn. Việc sử dụng vi trong ví dụ là bộ nhớ cơ nhiều hơn là sự chứng thực.}

   2. Sao chép phần sau vào tệp:

      # Mô-đun này phá vỡ bàn phím, vì vậy đừng tải nó
      danh sách đen intel_vbtn
      

   3. Lưu file và thoát:

      Nếu bạn đang sử dụng vi, điều này sẽ Thoát ra, sau đó : ⢠w ⢠q ⢠đi vào đến wnghi thức và quit các biên tập viên.

4. Tắt và khởi động lại để xác minh rằng bàn phím hoạt động sau khi khởi động nguội

Tôi gặp vấn đề tương tự trên ASUS Zenbook UM325UA của mình.

Một bưu kiện tại linux.org đã chỉ đến một mục trong Arch wiki có vấn đề tương tự đối với một ASUS ZenBook khác với một giải pháp mơ hồ nhưng hiệu quả.

Sau một số thử nghiệm và sai sót, tôi phát hiện ra rằng việc tải i8042 cần có mô-đun để bàn phím hoạt động khi khởi động. Về lý do tại sao nó hoạt động mà không có nó sau khi khởi động lại, tôi vẫn không biết.

Trên Arch Linux, mô-đun sau phải được đưa vào /etc/mkinitcpio.conf:

# Đối với bàn phím (initramfs) sớm
# Trong phần MÔ-ĐUN
MÔ-ĐUN=(i8042)

Sau đó, hình ảnh initramfs phải là tái tạo.

Trên Ubuntu, theo công cụ initramfs trang chủ, các i8042 mô-đun nên được liệt kê trong /etc/initramfs-tools/modules tập tin, sau đó hình ảnh phải được tạo lại với cập nhật-initramfs -u.

Mình không dùng Ubuntu nên chưa test được, nếu được thì báo mình với.

Mở một bảng điều khiển ảo với, ví dụ: Điều khiển+thay thế+F3

Bàn phím có hoạt động ở đó không?
Sau đó thử cài đặt từ đó:

sudo apt cài đặt xserver-xorg-input-all

và thử cập nhật:

cập nhật sudo apt
nâng cấp sudo apt

Sau đó thử chấm dứt X với

sudo /etc/init.d/gdm dừng lại

Sau đó, hãy thử cấu hình lại X

sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.backup
sudo dpkg-cấu hình lại xserver-xorg

Cuối cùng, khởi động lại X với

sudo /etc/init.d/gdm bắt đầu