Using a Raspberry Pi 4 as a desktop computer, I faced a few hardware-related issues. I diagnosed and fixed them with the help of AI assistants, which suggested specific commands and configurations.
Low Monitor Resolution
The first was the low resolution of the monitor. I have BenQ PD2500Q with a native resolution of 2560x1440, but RPi recognised it only as Full HD (1920x1080).
After some research, I found a suggestion to check the output of edid file from the /sys subsystem:
sudo cat /sys/class/drm/card*/card*HDMI*/edid| edid-decode
The output revealed the issue: the monitor was advertising 2560×1440 as a DTD (Detailed Timing Descriptor) in Block 0, but the CTA-861 extension block (Block 1) only listed standard HD modes up to 1920×1080 as native. The Pi's Wayland compositor (the display server protocol used by Raspberry Pi OS) was prioritizing the CTA block and stopping at 1080p.
The DTD timing can be explicitly set in the /boot/firmware/config.txt:
[HDMI:0]
hdmi_group=2
hdmi_mode=87
hdmi_force_hotplug=1
hdmi_timings=2560 1 47 32 81
1440 1 3 5 33 0 0 0
60 0 241500000 6
However, after a restart, the resolution reverted to 1080p. Further investigation revealed that the window manager (labwc) also needed the custom mode to be set. I added the following line to ~/.config/labwc/autostart:
wlr-randr --output HDMI-A-1 --custom-mode 2560x1440@59.95 &
Very Slow Mouse
My mouse was lagging significantly. I first tried adjusting the mouse speed in the desktop environment settings, but it didn’t help.
After some research, I found that the issue could be resolved by adjusting the usbhid.mousepoll parameter in /boot/firmware/cmdline.txt. This parameter controls how often the USB mouse is polled for input (in milliseconds). Lower values mean more frequent polling and smoother cursor movement, but setting it too low can cause system instability.
I ended up with the following setting:
usbhid.mousepoll=4Network Card Dropping Connection
The third problem was much easier to diagnose. I left RPi running, but when I returned, the WiFi connection had dropped. The logs revealed repeated failures during the 4-way handshake authentication process, with NetworkManager unable to retrieve the stored WiFi password.
The root cause was that the connection details were saved into a user session keyring (e.g., GNOME Keyring) rather than the system keyring. A user keyring unlocks when you log in and stays unlocked while your session is active; then it locks again, and NetworkManager cannot retrieve the password.
The solution was to set the password storage to system-level keyring using the nmcli tool:
sudo nmcli connection modify "YOUR_network" wifi-sec.psk "your-password" sudo nmcli connection modify "YOUR_network" connection.permissions ""
The first command sets the WiFi password for the specified network connection, while the second removes any permission restrictions, allowing all users to access the connection.
Note: For security, avoid hardcoding passwords in commands. Instead, use nmcli interactively or a secure password manager.
Links
No comments:
Post a Comment