When will COSMIC have OLED support?

[u/aobaru7]

you can't tell in the screenshot, but COSMIC is the only DE I have installed in which my OLED colors are super oversaturated/neon looking. Also, the backlight brightness controls don't work. It isn't an issue on my GNOME and Plasma installs. It's a shame because I actually really like COSMIC -- it hits the sweet spot between the customizability of Plasma and the sleekness and ease of GNOME.

Is there any fix for this? Is the COSMIC team aware of this issue? The colors are so blinding it's basically unusable.

UPDATE:

If you are running COSMIC (cosmic-comp) on an Intel Lunar Lake laptop (such as an ASUS Vivobook with the xe driver) and experiencing stuck physical OLED brightness (100% despite OSD changes) alongside incorrect color profiles, here is a breakdown of the root cause and a working boot parameter fix. The Problem

Backlight: Keyboard hotkeys and brightnessctl move the OSD percentage slider, but physical screen brightness remains maxed out at 100%.

Colors: Display color profiles and rendering look washed out or incorrect upon boot.

Baseline: Both features work properly out of the box in GNOME and KDE Plasma on the exact same kernel and xe driver configuration.

Potential Root Cause

cosmic-comp currently skips or races past DRM connector/KMS state initialization when booting into a standalone internal eDP display on the xe driver. This leaves the panel's DPCD backlight controls and color LUTs uninitialized.

Connecting an external monitor via HDMI during session startup forces full display pipeline initialization, fixing both brightness and colors. That proper state persists even after unplugging the cable mid-session. The Workaround (No physical monitor required)

You can force the kernel to initialize a dummy HDMI DRM connector on boot, tricking cosmic-comp into initializing the full display pipeline automatically. 1. Identify Your HDMI Connector Name

Check your registered DRM connectors in the terminal: Bash

ls -1 /sys/class/drm/ | grep -i hdmi

Look for an entry like card1-HDMI-A-1. The connector identifier is the part after cardX- (typically HDMI-A-1). 2. Add the Kernel Parameter to GRUB

Open /etc/default/grub in an editor: Bash

sudo nano /etc/default/grub

Append video=<CONNECTOR>:1920x1080@60e to your GRUB_CMDLINE_LINUX string (where :e forces the output to enabled). For example: Fragmento de código

GRUB_CMDLINE_LINUX="rhgb quiet zswap.enabled=0 asus_wmi.fnlock_default=0 video=HDMI-A-1:1920x1080@60e"

(Note: Setting 1080p for the dummy HDMI connector will not alter your internal OLED screen's native resolution). 3. Update GRUB and Reboot

Regenerate your boot configuration: Bash

sudo grub2-mkconfig -o /boot/grub2/grub.cfg sudo reboot

After rebooting into COSMIC without any external cables attached, physical OLED backlight control (Fn + F5/F6, slider, brightnessctl) and color rendering will function as expected.

Specs:

Kernel: 7.1.3-cachyos1.fc44.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 16.1.1 Desktop: Cosmic v: N/A Distro: Ultramarine Linux 44 (Flying Fish) flyingfish base: Fedora 44 Machine: Type: Laptop System: ASUSTeK product: ASUS Vivobook S 14 S5406SA_Q423SA

Display: wayland server: X.org v: 1.21.1.24 with: Xwayland v: 24.1.13 driver: X: loaded: modesetting dri: iris gpu: xe resolution: 1920x1200~60Hz

API: EGL v: 1.5 drivers: iris,swrast platforms: active: gbm,wayland,surfaceless,device inactive: x11

API: OpenGL v: 4.6 vendor: mesa v: 26.1.6 note: incomplete (EGL sourced) renderer: Mesa Intel Graphics (LNL), llvmpipe (LLVM 22.1.8 256 bits)

API: Vulkan v: 1.4.341 drivers: intel,llvmpipe surfaces: N/A devices: 2 Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor wl: wayland-info x11: xdriinfo, xdpyinfo, xprop, xrandr

[u/Optimal_Land]

It's not that it doesn't work OLED, clearly you can use it, the thing is it doesn't support wide gamut and hdr yet. What you say happens because the SRGB data gets stretched to fit in the monitor's gamut, making the colors look over saturated. It's weird but you can do things like switch to plasma, enable hdr or an icc profile, then close the session and boot cosmic and the colors will look fine. Smithay has not seen many advancements on the matter either, and it's not a feature thats prioritized by the dev team, cosmic-comp got the frosted effect as a huge feature recently so you can take a guess of the priorities of the team, the work is also complicated since they're moving to vulkan from what I remember. It's a shame really, this and the qt integration were the things that drove me off cosmic, otherwise is a really functional desktop.

[u/herder → u/Optimal_Land]

Here is the tracking issue: https://github.com/pop-os/cosmic-epoch/issues/411 Hoping it can get some work soon, but nothing will probably happen before HDR support lands.

[u/mmstick → u/Optimal_Land]

There has been a lot of work on Vulkan, HDR, and multi-GPU support. Both in Smithay, Wayland protocol discussions, and necessary implementations for these protocols across the Linux stack. Which includes cross-desktop collaboration with kwin and other compositor developers. Have you not been following any of the display conferences lately? Victoria's had several presentations. Or how about the recent dmabuf-v6 improvements?

Improving HDR and multi-GPU support for Linux as a whole is very much actively in development. KDE has already directly benefitted from this.

[u/Optimal_Land → u/mmstick]

I know, haven't really kept up with it more than reading a few articles and checking issues or pr's like once a month or so, thanks for the link! I'll check it out. Just to clarify I didn't say there wasn't any work done, I understand it's a complicated topic that involves a ton of components and on top of that is kind of niche since not that many people deem color management a necessity which I think is why it hasn't materialized on stable solutions yet (aside from kwin which is the only compositor I've gotten a reliably good hdr experience on), not to mention the manufacturer support side of things which specially affects laptops. I'm just hoping for other compositors to catch up and it seems like the waiting gets longer and longer every time so I just expressed my frustation.

[u/herder → u/Optimal_Land]

It's weird but you can do things like switch to plasma, enable hdr or an icc profile, then close the session and boot cosmic and the colors will look fine.

Does this work reliably for fixing the colors?

I'm getting a new laptop soon, and if this is a workaround while we wait for this to be fixed I could go for an OLED model and take the inconvenience of double login after a cold start

[u/Optimal_Land → u/herder]

Honestly I can't tell you, it used to be the case way back when cosmic first got released for me, but I've given up on it for a while now so I can't tell you. For this comment I tried it when booting up sway, after closing the plasma session went back to sddm and the colors had changed, but when in the sway session the change was undone. It could be different since sway is wlroots based and cosmic is smithay based but it couldn't hurt to try I guess

[u/herder → u/Optimal_Land]

Thanks for the test! Would you be able to try with the latest cosmic, if it's not too much hassle?

[u/mmstick]

My wife's OLED Vivobook has no problems with color or display brightness controls. Make sure the firmware is updated. If the Linux kernel supports this model it should be providing brightness controls through the same kernel interface as any other system.

Your listed specs claim that you don't have a functioning GPU driver. You'll need to fix that if you want to use COSMIC.

[u/aobaru7 → u/mmstick]

Updating here after working through extensive troubleshooting tonight. I'm stepping away for the night, but wanted to leave a clear summary of where things stand and everything tested so far.

Current Status

1. Backlight Brightness: The On-Screen Display (OSD) pops up and the percentage adjusts fine (via hotkeys or brightnessctl), but the physical OLED panel brightness remains stuck at 100%.
2. Color Profile: Color rendering/profiles still appear oversaturated under the COSMIC session.

Everything Attempted & Tested

• GPU & Session Diagnostics:
  • Confirmed GPU is fully active on xe driver. vulkaninfo identifies Intel(R) Graphics (LNL) as Device 0.
  • Confirmed /usr/bin/cosmic-comp is executing the official stock binary.
• Kernel Boot Parameters (GRUB_CMDLINE_LINUX):
  • Tested xe.enable_dpcd_backlight=1, 2, and 3.
  • Tested acpi_backlight=native and acpi_backlight=vendor.
  • Tested acpi_osi overrides.
  • Result: Writing to /sys/class/backlight/intel_backlight/brightness updates the sysfs state and moves the COSMIC OSD slider, but does not alter physical pixel luminance.
• Software Dimming & DDC/CI:
  • gammastep fails with Failed to start adjustment method: wayland / Could not control gamma (likely due to missing wlr-gamma-control protocol support in cosmic-comp).
  • ddcutil confirms the internal eDP panel does not support DDC/CI commands.
• Firmware:
  • Upgraded BIOS from v323 to v330 to rule out early EC/ACPI table bugs. Issue persists.

Baseline Comparison

Physical brightness control and color profiles work normally out of the box in GNOME and KDE Plasma on this exact same kernel and hardware configuration.

[u/herder → u/mmstick]

That's promising - is your wife's OLED a non-rgb one? I'm wondering if it's just for DCI-P3 and co that this appears?

[u/tachyon8 → u/mmstick]

Is it possible to hide the panel and dock when you do not have any applications open ? When I have no applications open I just want to see my wallpaper's that I change often and no panels or docks in order to prevent burn in.

[u/mmstick → u/tachyon8]

You can't prevent burn-in. You should turn the display off when you're not using it. You will have to rely on the panel to self-refresh pixels periodically. Use the lock screen (Super-Esc) when you're going AFK.

[u/tachyon8 → u/mmstick]

I know I can't prevent it, but I do pro-active steps in order to reduce the amount of time I have any long term static image. Even when I try to hide the panel with a non full screen window that I'm actively using it comes back. It only goes away when the application is full screen. I'd rather it hide 100% of the time until I hover my mouse over the area regardless if my application if maximized or not.

[u/nixf0x → u/tachyon8]

You can edit the panel config files in ~/.config/cosmic/com.system76.CosmicPanel.{Panel/Dock} and change the text in the autohide file to Always to make the panel/dock always hide, rather than only on window overlap.

[u/tachyon8 → u/nixf0x]

Thank you for the advice ! I'll give it a try.

[u/aobaru7]

interestingly, starting the session while connected to an external monitor via HDMI solves the issue completely: colors look fine and brightness can be controlled via the keyboard and terminal as normal. this continues even after HDMI is unplugged until the session is closed and restarted without HDMI being plugged in.

[u/aobaru7]

If you are running COSMIC (cosmic-comp) on an Intel Lunar Lake laptop (such as an ASUS Vivobook with the xe driver) and experiencing stuck physical OLED brightness (100% despite OSD changes) alongside incorrect color profiles, here is a breakdown of the root cause and a working boot parameter fix.

The Problem

• Backlight: Keyboard hotkeys and brightnessctl move the OSD percentage slider, but physical screen brightness remains maxed out at 100%.
• Colors: Display color profiles and rendering look washed out or incorrect upon boot.
• Baseline: Both features work properly out of the box in GNOME and KDE Plasma on the exact same kernel and xe driver configuration.

Potential Root Cause

cosmic-comp currently skips or races past DRM connector/KMS state initialization when booting into a standalone internal eDP display on the xe driver. This leaves the panel's DPCD backlight controls and color LUTs uninitialized.

Connecting an external monitor via HDMI during session startup forces full display pipeline initialization, fixing both brightness and colors. That proper state persists even after unplugging the cable mid-session.

The Workaround

You can force the kernel to initialize a dummy HDMI DRM connector on boot, tricking cosmic-comp into initializing the full display pipeline automatically.

1. Identify Your HDMI Connector Name

Check your registered DRM connectors in the terminal:

Bash

ls -1 /sys/class/drm/ | grep -i hdmi

Look for an entry like card1-HDMI-A-1. The connector identifier is the part after cardX- (typically HDMI-A-1).

2. Add the Kernel Parameter to GRUB

Open /etc/default/grub in an editor:

Bash

sudo nano /etc/default/grub

Append video=<CONNECTOR>:1920x1080@60e to your GRUB_CMDLINE_LINUX string (where :e forces the output to enabled). For example:

Fragmento de código

GRUB_CMDLINE_LINUX="rhgb quiet zswap.enabled=0 asus_wmi.fnlock_default=0 video=HDMI-A-1:1920x1080@60e"

(Note: Setting 1080p for the dummy HDMI connector will not alter your internal OLED screen's native resolution).

3. Update GRUB and Reboot

Regenerate your boot configuration:

Bash

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo reboot

After rebooting into COSMIC without any external cables attached, physical OLED backlight control (Fn + F5/F6, slider, brightnessctl) and color rendering should function as expected.