8000 Fixed OLED geometry detection logic for non-CM4 devices by Maotechh · Pull Request #192 · pikvm/kvmd · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fixed OLED geometry detection logic for non-CM4 devices #192

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

Fixed OLED geometry detection logic for non-CM4 devices #192

wants to merge 1 commit into from

Conversation

Maotechh
Copy link

On a Raspberry Pi Zero 2 W with a 128×64 OLED display, the screen was incorrectly initialized as 128×32 due to hardcoded logic relying solely on device model and USB presence. This caused display issues for non-CM4 boards with 64px-high screens.

@Maotechh
Fixed OLED geometry detection logic for non-CM4 devices
cc31678 
On a Raspberry Pi Zero 2 W with a 128×64 OLED display, the screen was incorrectly initialized as 128×32 due to hardcoded logic relying solely on device model and USB presence. This caused display issues for non-CM4 boards with 64px-high screens.
@mdevaev
Copy link
Member
mdevaev commented May 31, 2025

Hello.

I don't want to accept it because of too much magic here. If you're using a very custom build, just create systemd override and pass the correct --width and --height parameters to the display service.

@mdevaev mdevaev closed this May 31, 2025
@Maotechh
Copy link
Author
Maotechh commented Jun 2, 2025

Hi, thanks for the feedback.

I understand the concern about adding too much "magic" or implicit behavior. However, I’d like to clarify that this change doesn’t introduce unpredictable logic—it simply adds a lightweight and robust auto-detection fallback only when the display parameters aren’t explicitly provided.

Here’s why I think it’s justified:

  1. The current detection logic is already a heuristic (CM4 + USB → 64px) and fails silently for many real-world cases like the Raspberry Pi Zero 2 W with a 128×64 OLED. So the existing code already contains "magic"—but it’s fragile and incorrect in certain scenarios.

  2. The proposed detection is non-intrusive:

    • It only runs if no width/height is explicitly configured.
    • It tries to read the actual display height using existing drivers (SSD1306/SH1106).
    • It gracefully falls back to the current logic if detection fails.
      There’s no added configuration burden or required dependencies beyond what's already in use.

  3. Telling users to write a systemd override adds unnecessary complexity, especially for less technical users. For most people using standard 128×64 OLEDs, this patch makes the software just work, which improves out-of-the-box experience.

  4. This change improves compatibility without breaking anything. It retains full backward compatibility and existing behavior for known devices.

If you'd prefer, I can refactor the detection logic under a try_detect_oled_height() helper function to make it clearer and less "magical." But I do believe this behavior is practical and user-friendly, and it resolves a real hardware mismatch without requiring per-user hacks.

@mdevaev
Copy link
Member
mdevaev commented Jun 2, 2025 •
edited
Loading
  • Firstly, the current logic is not fragile and incorrect. It works exactly for what it was written for: to determine which of the official device models is running kvmd-oled.
  • DIY builds do not assume the presence of OLED due to additional connections that can confuse the user. I2C also consumes GPIO lines, which the user could use at his discretion and it would be a surprise if they were occupied by I2C.
  • If you assemble the device according to our DIY instructions, but go beyond them, it is assumed that you know what you are doing. We don't stop you in any way and even help you by providing the necessary options.
  • If you know what you're doing, then you won't have any problems creating a systemd override.
  • Among other things, this code is useless on its own. Kvm-oled will not work on DIY PiKVM without manual enabling of I2C kernel module and an I2C overlay. That is, in any case, you will have to edit at least two configs to use it. The presence or absence of an additional one will not affect the situation too much.
  • For obvious reasons of the need to maintain backward compatibility so as not to break existing installations, I will not enable I2C by default too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@Maotechh @mdevaev
0