Display resolution on Thinkpad X1E locked to 1280x1024, should be 4k

  • KDE Plasma
  • X11
  • Tumbleweek

This system has hybrid Intel/NVIDIA GPUs. During installation of Tumbleweed I had to add nomodeset to the launch parameters to fix a black screen. I’ve installed the proprietary NVIDIA driver following the Automated Installation instructions and it seems that they’re installed. I haven’t removed nomodeset yet, and from what I can glean from the wiki, I don’t think I’m supposed to for these drivers.

Anyway, my built-in display is a 4k display. I know this from its previous life as a Windows dev machine. However, Tumbleweed’s display manager has it locked to 1280x1024 and claims that this is the only resolution it supports. Why isn’t it detecting the full capabilities of the monitor?

adam@localhost:~> inxi -G
Graphics:
  Device-1: Intel CometLake-H GT2 [UHD Graphics] driver: N/A
  Device-2: NVIDIA TU117M [GeForce GTX 1650 Ti Mobile] driver: nvidia
    v: 580.82.07
  Device-3: IMC Networks Integrated Camera driver: uvcvideo type: USB
  Display: x11 server: X.Org v: 21.1.15 with: Xwayland v: 24.1.8 driver: X:
    loaded: modesetting,nvidia unloaded: vesa gpu: nvidia
    resolution: 1280x1024~60Hz
  API: EGL v: 1.5 drivers: kms_swrast,nvidia,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: mesa v: 25.2.2
    renderer: llvmpipe (LLVM 20.1.8 256 bits)
  API: Vulkan v: 1.4.321 drivers: nvidia,llvmpipe surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor gpu: nvidia-smi wl: wayland-info
    x11: xdpyinfo, xprop, xrandr

You need to remove nomodeset or the Nvidia drivers are not active. This parameter was only needed prior installation of the Nvidia drivers.

And better provide
inxi -GSax

I’m using GRUB2 BLS, so I don’t have a file at /etc/default/grub. Where do I find the launch command to remove the nomodeset? Do I need to run a different command to rebuild my initrd too?

Here’s the output of inxi -GSax

System:
  Host: localhost.localdomain Kernel: 6.16.5-1-default arch: x86_64 bits: 64
    compiler: gcc v: 15.2.0 clocksource: tsc avail: acpi_pm
    parameters: BOOT_IMAGE=(hd0,gpt1)/opensuse-tumbleweed/6.16.5-1-default/linux-bafd92b58a971b71acc8509f002cf956fd36445a
    nomodeset splash=silent quiet security=selinux selinux=1 mitigations=auto
    root=/dev/mapper/cr_root rootflags=subvol=@/.snapshots/1/snapshot
    systemd.machine_id=950bf0bbe4aed5c3fc4fc97668c1d1c4
  Desktop: KDE Plasma v: 6.4.4 tk: Qt v: N/A info: frameworks v: 6.17.0
    wm: kwin_x11 tools: avail: xscreensaver vt: 2 dm: SDDM Distro: openSUSE
    Tumbleweed 20250909
Graphics:
  Device-1: Intel CometLake-H GT2 [UHD Graphics] vendor: Lenovo driver: N/A
    alternate: i915 arch: Gen-9.5 process: Intel 14nm built: 2016-20
    bus-ID: 00:02.0 chip-ID: 8086:9bc4 class-ID: 0300
  Device-2: NVIDIA TU117M [GeForce GTX 1650 Ti Mobile] vendor: Lenovo
    driver: nvidia v: 580.82.07 alternate: nouveau,nvidia_drm
    non-free: 550-580.xx+ status: current (as of 2025-08; EOL~2026-12-xx)
    arch: Turing code: TUxxx process: TSMC 12nm FF built: 2018-2022 pcie:
    gen: 1 speed: 2.5 GT/s lanes: 16 link-max: gen: 3 speed: 8 GT/s
    bus-ID: 01:00.0 chip-ID: 10de:1f95 class-ID: 0300
  Device-3: IMC Networks Integrated Camera driver: uvcvideo type: USB
    rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-8:3 chip-ID: 13d3:5405
    class-ID: fe01 serial: 0000
  Display: x11 server: X.Org v: 21.1.15 with: Xwayland v: 24.1.8
    compositor: kwin_x11 driver: X: loaded: modesetting,nvidia unloaded: vesa
    alternate: fbdev,intel,nouveau,nv gpu: nvidia display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1280x1024 s-dpi: 96 s-size: 338x270mm (13.31x10.63")
    s-diag: 433mm (17.03")
  Monitor-1: Unknown-1 mapped: None-1 res: mode: 1280x1024 hz: 60
    scale: 100% (1) size: N/A modes: 1280x1024
  API: EGL v: 1.5 hw: drv: nvidia platforms: device: 0 drv: nvidia device: 2
    drv: swrast gbm: drv: kms_swrast surfaceless: drv: nvidia x11: drv: swrast
    inactive: wayland,device-1
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: mesa v: 25.2.2 glx-v: 1.4
    direct-render: yes renderer: llvmpipe (LLVM 20.1.8 256 bits)
    device-ID: ffffffff:ffffffff memory: 30.25 GiB unified: yes
  API: Vulkan v: 1.4.321 layers: 3 device: 0 type: discrete-gpu name: NVIDIA
    GeForce GTX 1650 Ti with Max-Q Design driver: nvidia v: 580.82.07
    device-ID: 10de:1f95 surfaces: N/A device: 1 type: cpu name: llvmpipe
    (LLVM 20.1.8 256 bits) driver: mesa llvmpipe v: 25.2.2 (LLVM 20.1.8)
    device-ID: 10005:0000 surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor gpu: nvidia-smi wl: wayland-info
    x11: xdpyinfo, xprop, xrandr

It should be in one of the files under /boot/loader/entries/
Other users of grub2-bls might need to chime in as i don’t use it.

There is no directory loader in /boot

/etc/kernel/cmdline

You do not need to rebuild initrd to change kernel options. You do need to update loader entries after changing /etc/kernel/cmdline:

sdbootutil update-all-entries

/boot/efi/loader

@arvidjaar shouldn’t update-bootloader --del-option nomodeset work here?

No. It only changes /etc/kernel/cmdline and you still need to invoke update-bootloader --config to apply the changes (which will internally call sdbootutil update-all-entries.

But you are right, update-bootloader is the openSUSE way to change bootloader configuration without knowing the underlying implementation. I am just tired explaining it all these years and still seeing the grub2-mkconfig offered as alternative to the YaST Bootloader module.

1 Like

OK, I updated /etc/kernel/cmdline removing nomodeset. However, the command to update loader entries failed:

adam@localhost:~> sdbootutil update-all-entries
ERROR: Can't determine root subvolume

@Adam3394 you need to be root user…

Oops, of course. I should have realized that, and would have if I got a permission-based error. Thanks, continuing…

Hmm, concerning output. I have another thread going where I’m getting help troubleshooting TPM support. It seems I’ll need to get that resolved first before I can continue here.

Should I revert my edits to /etc/kernel/cmdline and re-run this command to attempt to restore prior bootloader state or just rely on the last snapshot?

adam@localhost:~> sudo sdbootutil update-all-entries
[sudo] password for root: 
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Garbage after device path end, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Garbage after device path end, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Garbage after device path end, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Device path size does not match, ignoring.
Garbage after device path end, ignoring.
WARNING:esys:src/tss2-esys/api/Esys_PolicyOR.c:286:Esys_PolicyOR_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/api/Esys_PolicyOR.c:100:Esys_PolicyOR() Esys Finish ErrorCode (0x000001c4) 
Failed to add OR policy to TPM: tpm:parameter(1):value is out of range or is not correct for the context
Failed to submit super PCR policy: State not recoverable
Error creating the systemd-pcrlock policy!

The error has nothing to do with nomodeset. It simply means that the current state of TPM (PCR values) does not match the state expected by the policy, so sdbootutil (strictly speaking, systemd-pcrlock) cannot update the policy automatically. If you mean that your root is encrypted and is not unlocked automatically - yes, it has the same reason.

Just to put a line under this, after fixing my TPM issue in the other thread, I re-ran sdbootutil update-all-entries just in case something didn’t apply correctly on the first attempt. I was then able to reboot with no FDE PW prompts and my built-in display is now showing a full range of supported resolutions. Thank you to everyone who replied!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.