Unknown-1 Display causing screen flickering on main display

After doing this I’m now facing a new problem:

There is Unknown-1 display in display configuration settings which I want to remove:

If this is enabled, the main display keeps flickering. I have disabled it so currently I don’t have issues. But I wish to remove Unknown-1 display if that is possible.

Here is inxi -Ga

Graphics:
  Device-1: Intel Alder Lake-N [UHD Graphics] driver: i915 v: kernel
    alternate: xe arch: Gen-12.2 process: Intel 10nm built: 2021-22+ ports:
    active: eDP-1 empty: DP-1, DP-2, HDMI-A-1, HDMI-A-2, HDMI-A-3
    bus-ID: 00:02.0 chip-ID: 8086:46d0 class-ID: 0300
  Device-2: Realtek USB2.0 camera driver: uvcvideo type: USB rev: 2.0
    speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-6.1:10 chip-ID: 0bda:5830
    class-ID: 0e02 serial: J2023111601
  Device-3: Sunplus Innovation USB 2.0 Camera driver: uvcvideo type: USB
    rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-6.2:13
    chip-ID: 1bcf:284d class-ID: 0e02 serial: J20231116V1
  Display: wayland server: X.org v: 1.21.1.13 with: Xwayland v: 24.1.2
    compositor: kwin_wayland driver: X: loaded: modesetting
    alternate: fbdev,intel,vesa dri: iris gpu: i915 display-ID: 0
  Monitor-1: eDP-1 res: 1440x960 size: N/A modes: N/A
  API: EGL v: 1.5 hw: drv: intel iris platforms: device: 0 drv: iris
    device: 1 drv: swrast gbm: drv: iris surfaceless: drv: iris wayland:
    drv: iris x11: drv: iris
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 24.2.2-arch1.1
    glx-v: 1.4 direct-render: yes renderer: Mesa Intel Graphics (ADL-N)
    device-ID: 8086:46d0 memory: 7.55 GiB unified: yes display-ID: :1.0
  API: Vulkan v: 1.3.295 layers: N/A device: 0 type: integrated-gpu
    name: Intel Graphics (ADL-N) driver: mesa intel v: 24.2.2-arch1.1
    device-ID: 8086:46d0 surfaces: xcb,xlib,wayland

My device specs by fastfetch:

OS: EndeavourOS x86_64
Host: StarLite (1.0)
Kernel: Linux 6.10.10-arch1-1
Uptime: 42 mins
Shell: bash 5.2.32
Display (BOE0B36): 2160x1440 @ 60 Hz (as 1440x960) in 13″ [Built-in]
DE: KDE Plasma 6.1.5
WM: KWin (Wayland)
Terminal: konsole 24.8.1
CPU: Intel(R) N200 (4) @ 3.70 GHz
GPU: Intel UHD Graphics @ 0.75 GHz [Integrated]
Memory: 4.28 GiB / 15.47 GiB (28%)
Swap: 0 B / 512.00 MiB (0%)
Disk (/): 13.72 GiB / 467.39 GiB (3%) - ext4
Disk (/media/mihirr/1tb-sandisk): 381.67 GiB / 953.49 GiB (40%) - btrfs
BIOS Version: 24.08
Firmware Version: 24.8

Visit StarLite MK V page: https://starlabs.systems/pages/starlite

Seems like one of those virtual displays. Did you create one through obs or something else that uses the wayland screensharing portal? There are also ways to create one using built in tools and drivers. Did you attempt to create a virtual display through one of those means?

I used none of those ways. My tablet was not booting if I used kernel v6.10.10.
I had to do an early kms start of i915 for my tablet to boot properly. It is only after this that I was seeing that Unknown-1 display.

I don’t have any external monitors attached, nor did I use any of the apps/wayland screensharing portal/tools.

Did you undo the init_call blacklist stuff from your last post?

Yes, I have removed it.

Well, I’m out of ideas as to what is causing it then. If it isn’t a virtual display.

On Wayland, display-relevant logs are created by the DM (assuming SDDM in your case). You may find more info in journal (sddm, sddm-greeter) and/or at $HOME/.local/share/sddm/.
Does this Unknown monitor show in xrandr?

IMHO, since you disable this virtual monitor in KDE settings, it should remain disabled.
Also, until some future problem occurs, you may just forget it till then.

This issue may be related to the framebuffer-related messages in kernel logs (or not at all :man_shrugging: ). coreboot cases are not a usual case :smile: . You might want to ask your vendor’s support about it, they should definitely know more and better :wink: .

I checked journalctl logs for sddm & sddm-greeter but found nothing relevant.
Checked ~/.local/share/sddm/ there was just 1 empty log file.
xrandr shows that unknown display only when it is enabled in display configuration in system settings.

Can confirm, it is staying disabled so far.
I’ll contact the manufacturer on this regard.

Thanks for the pointers!

1 Like

So I contacted the Vendor. They advise me to use Kernel v6.8.0 as they have extensively tested their devices on that version.

But if alternate solutions exist, I’m willing to go through it.

On a side note, connecting an external display causes some flickering & ultimately freezes on the main display (complete black on external monitor).
This is on kernel v6.10.10.
I will downgrade to 6.8.x soon & post updates here

I’m afraid this is not how this works in Arch Linux. You may try linux-lts , which is now v.6.6.51.
Or you may try AKM (an EnOS utility) that you should find in the Welcome app.

linux-lts does work without problems (didn’t test conencting external monitor)
And I tried AKM, but it doesn’t have otions for 6.8.x

I feel that my device isn’t ready for newer kernels & that EndeavourOS is not for me, atleast in this current device.

To conclude, there may be ways to remove this Unknown-1 display, but I’m not courageous enough to actually do it :sweat_smile: (I don’t wanna brick my device)
Still for those who stumble across this post:

  1. Try this arch way - After updating kernal - framebuffer coreboot8: probe with driver framebuffer failed with error -17 - #3 by Ultima_Thulee
  2. Simply disable Unknown-1 display & never connect external monitors if you are on kernel 6.10+
  3. Manually downgrade to kernel 6.8.x. Starlabs support said that this device is extensively tested on kernel 6.8.0
  4. Wait until there are fixes available for it or sufficient testing is done by Starlabs

Although I do like EndeavourOS, but I feel that this device isn’t ready for it. And I’m switching to Fedora 40.
Perhaps when I get a new device, I will definitely install EOS on it as my daily driver.

Thank you all for the support!

1 Like

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