fix: select the built-in X11 panel in NVIDIA dGPU mode - #201
Merged
Merged
Conversation
utajum
requested changes
Sep 28, 2026
utajum
left a comment
utajum
left a comment
Owner
There was a problem hiding this comment.
Thanks for PR.
For lighting part please attach log from FA608UHI. Run app from terminal (stderr) or export diagnostics, then do suspend/resume. What we need:
- startup lines with
HidrawHelper: backlight OOBE disabled on /dev/hidrawN PID=0x19B6(current master, without this PR) - lighting state after resume on master: off, wrong mode, or wrong brightness
- same after resume with this PR, with
FA608UHI EC lighting initline ls -l /dev/hidraw*andcat /sys/class/hidraw/hidraw*/device/uevent(to see 0x19B6 is on I2C)journalctl -k -b | grep -i -E 'i2c_hid|hid-asus|PM: suspend'around resume
For panel part please attach xrandr --prop in NVIDIA dGPU mode, with and without external display.
dljr-github
changed the title
Author
|
Thanks for the review. I’ve removed the RGB changes locally and narrowed this to the X11 panel-selection fix. I couldn’t reproduce the original lighting issue on upstream master, including after shutdown and startup. It may have been isolated to my earlier system or controller state, but I haven’t established the cause. For the panel issue, I reproduced the following on FA608UHI in NVIDIA dGPU mode:
The internal display reports The diagnostic bundle includes full Diagnostics are included inline below. Backend queries used the live X server; gamma commands were captured without execution. The refresh switch was executed and restored. xrandr-dgpu-external.txtxrandr-dgpu-internal-only.txtmaster-result.txtpanel-result.txtpanel-live-switch.txtafter-switch.txt |
dljr-github
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In NVIDIA dGPU mode, the FA608UHI built-in screen is exposed as DP-0. With an external HDMI-0 monitor connected, the existing selection falls back to that external output, causing laptop display controls to report and target the wrong monitor.
Prefer connected outputs with
ConnectorType: Panel, then eDP/LVDS, including inactive panels. Read refresh information from the selected output using onexrandr --current --propsnapshot per operation. The diff contains only panel selection, refresh parsing, and related tests; RGB lighting changes have been removed.Verified against the live X server on FA608UHI: master selects HDMI-0 at 100 Hz; the changed backend selects DP-0 at 144 Hz. The changed backend successfully switched DP-0 from 144 to 60 Hz and restored 144 Hz, while HDMI-0 remained at 99.98 Hz. Gamma command targeting was checked without applying a gamma change. Full xrandr property captures with and without the external monitor are included in the review reply.
Validation:
git diff --checkpasses.Verification exercised the backend directly; it was not a separate GUI interaction test.