Dear all,

I am trying to install Debian on a mini laptop with 8" screen - the laptop is a "noname" product from China.

The laptop is equiped with an Intel Alder Lake N100 processor:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
Model name: Intel(R) N100
CPU family: 6
Model: 190

with built-in Intel graphics (i915)

I have installed Debian 12.11 using non-free-firmware,
During the installation, both the internal screen and an external HDMI monitor worked, although the internal monitor was rotated by 90�.
However, when booting the installed system, I see the following:
Grub menu on both screens, but internal screen rotated by 90�
After "Loading initial RAM disk", the internal monitor goes blank (backlight still on). The HDMI monitor works flawlessly.

When I add "nomodeset" to the linux cmd line, then both monitors continue to work after the boot. However, the internal one stays rotated by 90� and the resolution is limited to 800x600 (the internal monitor should have 1280x800 pixel)

So it seems to me that the problem is with the KMS.
I have tried various live-USB linux (KDE Neon, Ubuntu, Lubuntu, Kali). All of them work with "safe graphics setting" (nomodeset), but not otherwise.
I have tried upgrading to newer kernel from backports (6.12.22), and also updated to current Trixie. But still have the same problem.

Anybody has an idea how to get the internal monitor to work properly?



Thanks!

DM


Here is some additional information from the kernel log: -------------------------------------------------------------------------------------------------------------
root@capys:~# dmesg |grep i915
[ 2.405964] i915 0000:00:02.0: [drm] VT-d active for gfx access
[ 2.406382] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 2.406546] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[ 2.407685] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 2.407841] i915 0000:00:02.0: firmware: direct-loading firmware i915/ adlp_dmc_ver2_16.bin
[ 2.411245] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/ adlp_dmc_ver2_16.bin (v2.16)
[ 2.413885] i915 0000:00:02.0: [drm] [ENCODER:203:DSI A] is disabled/in DSI mode with an ungated DDI clock, gate it
[ 2.414268] i915 0000:00:02.0: firmware: direct-loading firmware i915/ tgl_guc_70.bin
[ 2.414593] i915 0000:00:02.0: firmware: direct-loading firmware i915/ tgl_huc.bin
[ 2.550483] i915 0000:00:02.0: [drm] GuC firmware i915/tgl_guc_70.bin version 70.5.1
[ 2.550494] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3
[ 2.558930] i915 0000:00:02.0: [drm] HuC authenticated
[ 2.559461] i915 0000:00:02.0: [drm] GuC submission enabled
[ 2.559465] i915 0000:00:02.0: [drm] GuC SLPC enabled
[ 2.559814] i915 0000:00:02.0: [drm] GuC RC: enabled
[ 3.189858] i915 0000:00:02.0: [drm] *ERROR* hback porch < 16 pixels
[ 3.317509] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor

0
[ 3.336624] fbcon: i915drmfb (fb0) is primary device
[ 3.958606] i915 0000:00:02.0: [drm] *ERROR* hback porch < 16 pixels
[ 4.101596] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[ 19.616387] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 19.709908] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[ 89.886760] i915 0000:00:02.0: [drm] *ERROR* hback porch < 16 pixels
[ 384.898665] i915 0000:00:02.0: [drm] *ERROR* hback porch < 16 pixels -------------------------------------------------------------------------------------------------------------



And here the output of xrandr: -------------------------------------------------------------------------------------------------------------
dm@capys:~$ xrandr
Screen 0: minimum 320 x 200, current 2720 x 1280, maximum 16384 x 16384
DSI-1 connected 800x1280+1920+0 (normal left inverted right x axis y axis) 0mm x 0mm
800x1280 60.57*+
1280x800 59.99 59.97 59.81 59.91
1280x720 60.00 59.99 59.86 59.74
1024x768 60.04 60.00
960x720 60.00
928x696 60.05
896x672 60.01
1024x576 59.95 59.96 59.90 59.82
960x600 59.93 60.00
960x540 59.96 59.99 59.63 59.82
800x600 60.00 60.32 56.25
840x525 60.01 59.88
864x486 59.92 59.57
700x525 59.98
800x450 59.95 59.82
640x512 60.02
700x450 59.96 59.88
640x480 60.00 59.94
720x405 59.51 58.99
684x384 59.88 59.85
640x400 59.88 59.98
640x360 59.86 59.83 59.84 59.32
512x384 60.00
512x288 60.00 59.92
480x270 59.63 59.82
400x300 60.32 56.34
432x243 59.92 59.57
320x240 60.05
360x202 59.51 59.13
320x180 59.84 59.32
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 300mm x 190mm
1920x1080 60.00*+ 60.00 59.94
1600x900 60.00
1280x800 59.91
1280x720 60.00 59.94
1024x768 60.00
800x600 60.32
720x480 60.00 59.94
640x480 60.00 59.94 -------------------------------------------------------------------------------------------------------------



And here the output of "lsmod |grep i915": -------------------------------------------------------------------------------------------------------------
i915 4325376 42
drm_buddy 20480 2 xe,i915
i2c_algo_bit 12288 2 xe,i915
drm_display_helper 270336 2 xe,i915
cec 69632 3 drm_display_helper,xe,i915
ttm 102400 3 drm_ttm_helper,xe,i915
drm_kms_helper 249856 4 drm_display_helper,drm_ttm_helper,xe,i915
drm 765952 29 gpu_sched,drm_kms_helper,drm_exec,drm_gpuvm,drm_suballoc_helper,drm_display_helper,drm_buddy,drm_ttm_helper,xe,i915,ttm
video 81920 2 xe,i915 -------------------------------------------------------------------------------------------------------------

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07.06.2025 10:40 Uhr Dietrich Meyer wrote:

I have installed Debian 12.11 using non-free-firmware,
During the installation, both the internal screen and an external
HDMI monitor worked, although the internal monitor was rotated by 90°.

IIRC those displays are portrait type and you need to rotate them in
the OS. The new OS doesn't know that the portrait display isn't mounted
this way. A German blogger also had this issue.

https://www.danisch.de/blog/2025/04/25/gedrehte-displays/

However, when booting the installed system, I see the following:
Grub menu on both screens, but internal screen rotated by 90°
After "Loading initial RAM disk", the internal monitor goes blank
(backlight still on). The HDMI monitor works flawlessly.

What happens of you boot it up disconnected?

Here is some additional information from the kernel log: -------------------------------------------------------------------------------------------------------------
root@capys:~# dmesg |grep i915
[ 2.405964] i915 0000:00:02.0: [drm] VT-d active for gfx access
[ 2.406382] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 2.406546] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[ 2.407685] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 2.407841] i915 0000:00:02.0: firmware: direct-loading firmware
i915/ adlp_dmc_ver2_16.bin
[ 2.411245] i915 0000:00:02.0: [drm] Finished loading DMC firmware
i915/ adlp_dmc_ver2_16.bin (v2.16)
[ 2.413885] i915 0000:00:02.0: [drm] [ENCODER:203:DSI A] is
disabled/in DSI mode with an ungated DDI clock, gate it
[ 2.414268] i915 0000:00:02.0: firmware: direct-loading firmware
i915/ tgl_guc_70.bin
[ 2.414593] i915 0000:00:02.0: firmware: direct-loading firmware
i915/ tgl_huc.bin
[ 2.550483] i915 0000:00:02.0: [drm] GuC firmware
i915/tgl_guc_70.bin version 70.5.1
[ 2.550494] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin
version 7.9.3
[ 2.558930] i915 0000:00:02.0: [drm] HuC authenticated
[ 2.559461] i915 0000:00:02.0: [drm] GuC submission enabled
[ 2.559465] i915 0000:00:02.0: [drm] GuC SLPC enabled
[ 2.559814] i915 0000:00:02.0: [drm] GuC RC: enabled
[ 3.189858] i915 0000:00:02.0: [drm] *ERROR* hback porch < 16
pixels [ 3.317509] [drm] Initialized i915 1.6.0 20201103 for
0000:00:02.0 on minor

0
[ 3.336624] fbcon: i915drmfb (fb0) is primary device
[ 3.958606] i915 0000:00:02.0: [drm] *ERROR* hback porch < 16
pixels [ 4.101596] i915 0000:00:02.0: [drm] fb0: i915drmfb frame
buffer device [ 19.616387] snd_hda_intel 0000:00:1f.3: bound
0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 19.709908] mei_hdcp
0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0
(ops i915_hdcp_component_ops [i915]) [ 89.886760] i915
0000:00:02.0: [drm] *ERROR* hback porch < 16 pixels [ 384.898665]
i915 0000:00:02.0: [drm] *ERROR* hback porch < 16 pixels

I think this is the part you should discuss on the mailing list for the
i915 driver.

-------------------------------------------------------------------------------------------------------------
dm@capys:~$ xrandr
Screen 0: minimum 320 x 200, current 2720 x 1280, maximum 16384 x
16384 DSI-1 connected 800x1280+1920+0 (normal left inverted right x
axis y axis) 0mm x 0mm

Does it work to change rotation of DSI-1 with xrandr?


--
kind regards
Marco

Send spam to [email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 07 Jun 2025 10:04:43 +0200
Dietrich Meyer <[email protected]> wrote:

However, when booting the installed system, I see the following:
Grub menu on both screens, but internal screen rotated by 90°
After "Loading initial RAM disk", the internal monitor goes blank
(backlight still on). The HDMI monitor works flawlessly.

How does the internal display work if you boot from a cold start
without the external display?

XFCE may handle this directly: settings-> Display, and set the rotation.

Or you might install arandr. Use it to get things set up as you like.
Then have it export a script. Hook that script into your startup. I
usually have XFCE run it from its autostart stuff.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Samstag, 7. Juni 2025, 14:25:14 CEST schrieb Charles Curley:

However, when booting the installed system, I see the following:
Grub menu on both screens, but internal screen rotated by 90�
After "Loading initial RAM disk", the internal monitor goes blank (backlight still on). The HDMI monitor works flawlessly.

How does the internal display work if you boot from a cold start
without the external display?

I forgot to mention this in my original post: The internal monitor behaves the same, whether or not the external one is connected. I.e. if I boot with "nomodeset", then I get a picture, rotated by 90�, and without the "nomodeset", the screen goes blank during the boot process.

XFCE may handle this directly: settings-> Display, and set the rotation.

Or you might install arandr. Use it to get things set up as you like.
Then have it export a script. Hook that script into your startup. I
usually have XFCE run it from its autostart stuff.

The problem is, when I boot with "nomodeset", i.e to have any picture at all on the internal display, I can't rotate the screen using xrandr (or KDE systemsettings or XFCE display settings).
From my (very limited) knowledge of linux graphics, I would assume that with "nomodeset", no proper driver for the graphics card is loaded and it operates in some standard VGA compatibility mode where I can't change any settings.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Samstag, 7. Juni 2025, 12:15:48 CEST schrieb Marco Moock:

I have installed Debian 12.11 using non-free-firmware,
During the installation, both the internal screen and an external
HDMI monitor worked, although the internal monitor was rotated by 90�.

IIRC those displays are portrait type and you need to rotate them in
the OS. The new OS doesn't know that the portrait display isn't mounted
this way. A German blogger also had this issue.

https://www.danisch.de/blog/2025/04/25/gedrehte-displays/

Great link, seems to be very similar issue and gives some hints on what I could try to experiment with. Thanks!

However, when booting the installed system, I see the following:
Grub menu on both screens, but internal screen rotated by 90�
After "Loading initial RAM disk", the internal monitor goes blank (backlight still on). The HDMI monitor works flawlessly.

What happens of you boot it up disconnected?

Same as with external display connected....

Here is some additional information from the kernel log: -------------------------------------------------------------------------- 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0
(ops i915_hdcp_component_ops [i915]) [ 89.886760] i915
0000:00:02.0: [drm] *ERROR* hback porch < 16 pixels [ 384.898665]
i915 0000:00:02.0: [drm] *ERROR* hback porch < 16 pixels

I think this is the part you should discuss on the mailing list for the
i915 driver.

-------------------------------------------------------------------------- ----------------------------------- dm@capys:~$ xrandr
Screen 0: minimum 320 x 200, current 2720 x 1280, maximum 16384 x
16384 DSI-1 connected 800x1280+1920+0 (normal left inverted right x
axis y axis) 0mm x 0mm

Does it work to change rotation of DSI-1 with xrandr?

No, I didn't manage to do that when I booted with "nomodeset"

Anway, I will try to continue with the ideas from your link above.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dietrich Meyer composed on 2025-06-07 04:04 (UTC+0200):

Please provide output from inxi -GSaz booted without nomodeset and with external
display connected. It provides a friendly combination of much of the information
you already provided, and may provide additional value.

I am trying to install Debian on a mini laptop with 8" screen - the laptop is a "noname" product from China.

The laptop is equiped with an Intel Alder Lake N100 processor:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
Model name: Intel(R) N100

The N100 CPU was RTM in early 2023, well after launch of Debian 12 in August 2021:
<https://www.intel.com/content/www/us/en/products/sku/231803/intel-processor-n100-6m-cache-up-to-3-40-ghz/specifications.html>
Required support for it is unlikely to be present in 12.11. Newer kernel and/or X
packages from backports are unlikely adequate for needed support.

Whether or not you have already tried the guc/huc command line options there I suggest you visit <https://wiki.archlinux.org/title/Intel_graphics> and give all
the help there a try.

Debian 13 Trixie is well along in development with full version freeze in effect
as of last month. A fresh Trixie installation instead of upgrade from Bookworm may
be the path you need to take. If this does not work, I suggest you file a bug report.

You may consider testing a live media or an installation of a distro that stays more current than Trixie will be when released. All the Alder Lake bugs /should/
be gone by now in the latest of everything, /including Trixie/. Fedora 42 was released in April. openSUSE Tumbleweed gets released as often as 7 days per week.
I use both in addition to Trixie and Bookworm. If in such testing the problem remains, surely an upstream bug is involved.

Nomodeset is a troubleshooting workaround that never supports two displays.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Samstag, 7. Juni 2025, 15:46:44 CEST schrieb Felix Miata:

Dietrich Meyer composed on 2025-06-07 04:04 (UTC+0200):

Please provide output from inxi -GSaz booted without nomodeset and with external display connected. It provides a friendly combination of much of
the information you already provided, and may provide additional value.

I am trying to install Debian on a mini laptop with 8" screen - the laptop is a "noname" product from China.

The laptop is equiped with an Intel Alder Lake N100 processor: Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
Model name: Intel(R) N100

The N100 CPU was RTM in early 2023, well after launch of Debian 12 in August 2021: <https://www.intel.com/content/www/us/en/products/sku/231803/intel-processo r-n100-6m-cache-up-to-3-40-ghz/specifications.html> Required support for it is unlikely to be present in 12.11. Newer kernel and/or X packages from backports are unlikely adequate for needed support.

Whether or not you have already tried the guc/huc command line options there I suggest you visit <https://wiki.archlinux.org/title/Intel_graphics> and give all the help there a try.

Debian 13 Trixie is well along in development with full version freeze in effect as of last month. A fresh Trixie installation instead of upgrade
from Bookworm may be the path you need to take. If this does not work, I suggest you file a bug report.

I have now tried many different setups:

- Debian Bookworm with kernel 6.1 and 6.12 (from backports, and also with kernel 6.14 from "zabbly" (https://github.com/zabbly/linux)

- Also tried the xe driver instead of the i915 driver with the 6.12 and 6.14 kernels.

- also did fresh install of Trixie/testing (using the Trixie RC1 installation medium)


With all of these configurations, I have the same situation:
1) with "nomodeset", I get picture both on internal and external screen. However, resolution is limited to 800x600 and internal screen is rotated by 90�. And I cannot change screen rotation.
2) without the "nomodeset", I get full resolution on external monitor, but only blank screen on internal screen.

Here are some example outputs of "inxi -GSaz", all of them when I did not use "nomodeset":

------------------------------------------------------------------------------------------------------
Bookworm with Kernel 6.14.10 and xe driver:

dm@capys:~$ inxi -GSaz
System:
Kernel: 6.14.10-zabbly+ arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
parameters: BOOT_IMAGE=/vmlinuz-6.14.10-zabbly+
root=/dev/mapper/capys--vg-root ro quiet i915.force_probe=!46d1
xe.force_probe=46d1
Desktop: KDE Plasma v: 5.27.5 tk: Qt v: 5.15.8 wm: kwin_x11 vt: 7 dm: SDDM
Distro: Debian GNU/Linux 12 (bookworm)
Graphics:
Device-1: Intel Alder Lake-N [UHD Graphics] driver: xe v: kernel
alternate: i915 arch: Gen-12.2 process: Intel 10nm built: 2021-22+ ports:
active: DP-1,DSI-1 empty: HDMI-A-1 bus-ID: 00:02.0 chip-ID: 8086:46d1
class-ID: 0300
Device-2: icSpring camera type: USB driver: uvcvideo bus-ID: 3-3:3
chip-ID: 32e6:9005 class-ID: 0e02
Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9
compositor: kwin_x11 driver: X: loaded: modesetting dri: iris gpu: xe
display-ID: :0 screens: 1
Screen-1: 0 s-res: 3200x1080 s-dpi: 96 s-size: 845x285mm (33.27x11.22")
s-diag: 892mm (35.11")
Monitor-1: DP-1 pos: primary,left model: Verbatim MT14 serial: <filter>
built: 2023 res: 1920x1080 hz: 60 dpi: 163 gamma: 1.2
size: 300x190mm (11.81x7.48") diag: 355mm (14") ratio: 16:10 modes:
max: 1920x1080 min: 640x480
Monitor-2: DSI-1 pos: right res: 1280x800 hz: 61 size: N/A modes: 800x1280
API: OpenGL v: 4.6 Mesa 25.0.4-1~bpo12+1 renderer: Mesa Intel Graphics
(ADL-N) direct-render: Yes

----------------------------------------------------------------------
Bookworm with Kernel 6.12 and i915 driver:

dm@capys:~$ inxi -GSaz
System:
Kernel: 6.12.22+bpo-amd64 arch: x86_64 bits: 64 compiler: N/A
parameters: BOOT_IMAGE=/vmlinuz-6.12.22+bpo-amd64
root=/dev/mapper/capys--vg-root ro quiet
Desktop: KDE Plasma v: 5.27.5 tk: Qt v: 5.15.8 wm: kwin_x11 vt: 7 dm: SDDM
Distro: Debian GNU/Linux 12 (bookworm)
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: DP-1,DSI-1 empty: HDMI-A-1 bus-ID: 00:02.0 chip-ID: 8086:46d1
class-ID: 0300
Device-2: icSpring camera type: USB driver: uvcvideo bus-ID: 3-3:3
chip-ID: 32e6:9005 class-ID: 0e02
Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9
compositor: kwin_x11 driver: X: loaded: modesetting dri: iris gpu: i915
display-ID: :0 screens: 1
Screen-1: 0 s-res: 3200x1080 s-dpi: 96 s-size: 845x285mm (33.27x11.22")
s-diag: 892mm (35.11")
Monitor-1: DP-1 pos: primary,left model: Verbatim MT14 serial: <filter>
built: 2023 res: 1920x1080 hz: 60 dpi: 163 gamma: 1.2
size: 300x190mm (11.81x7.48") diag: 355mm (14") ratio: 16:10 modes:
max: 1920x1080 min: 640x480
Monitor-2: DSI-1 pos: right res: 1280x800 hz: 61 size: N/A modes: 800x1280
API: OpenGL v: 4.6 Mesa 25.0.4-1~bpo12+1 renderer: Mesa Intel Graphics
(ADL-N) direct-render: Yes

------------------------------------------------------------------------------------------------------
Trixie with kernel 6.14:
System:
Kernel: 6.14.10-zabbly+ arch: x86_64 bits: 64 compiler: gcc v: 14.2.0
clocksource: tsc avail: acpi_pm
parameters: BOOT_IMAGE=/vmlinuz-6.14.10-zabbly+
root=/dev/mapper/capys--vg-root ro quiet i915=!46d1 xe=46d1
Desktop: KDE Plasma v: 6.3.4 tk: Qt v: N/A info: frameworks v: 6.13.0
wm: kwin_wayland with: krunner vt: 1 dm: SDDM Distro: Debian GNU/Linux 13
(trixie)
Graphics:
Device-1: Intel Alder Lake-N [UHD Graphics] driver: i915 v: kernel
alternate: xe arch: Xe process: Intel 10nm built: 2020-21 ports:
active: DP-1,DSI-1 empty: HDMI-A-1 bus-ID: 00:02.0 chip-ID: 8086:46d1
class-ID: 0300
Device-2: icSpring camera driver: uvcvideo type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 3-3:3 chip-ID: 32e6:9005
class-ID: 0e02
Display: wayland server: X.org v: 1.21.1.16 with: Xwayland v: 24.1.6
compositor: kwin_wayland driver: X: loaded: modesetting unloaded: fbdev,vesa
dri: iris gpu: i915 d-rect: 2720x2360 display-ID: 0
Monitor-1: DP-1 pos: top-right model: Verbatim MT14 serial: <filter>
built: 2023 res: mode: 1920x1080 hz: 60 scale: 135% (1.35) to: 1422x800
dpi: 163 gamma: 1.2 size: 300x190mm (11.81x7.48") diag: 355mm (14")
ratio: 16:10 modes: max: 1920x1080 min: 640x480
Monitor-2: DSI-1 pos: bottom-l res: mode: 800x1280 hz: 61
scale: 78% (0.78) to: 1024x640 dpi: 188 size: 108x172mm (4.25x6.77")
diag: 203mm (8") modes: 800x1280
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: 25.0.5-1 glx-v: 1.4
direct-render: yes renderer: Mesa Intel Graphics (ADL-N)
device-ID: 8086:46d1 memory: 5.58 GiB unified: yes display-ID: :1.0
API: Vulkan v: 1.4.309 layers: 3 device: 0 type: integrated-gpu
name: Intel Graphics (ADL-N) driver: mesa intel v: 25.0.5-1
device-ID: 8086:46d1 surfaces: xcb,xlib,wayland device: 1 type: cpu
name: llvmpipe (LLVM 19.1.7 256 bits) driver: mesa llvmpipe
v: 25.0.5-1 (LLVM 19.1.7) device-ID: 10005:0000 surfaces: xcb,xlib,wayland
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
de: kscreen-console,kscreen-doctor wl: wayland-info x11: xdriinfo,
xdpyinfo, xprop, xrandr

------------------------------------------------------------------------------------------------------

You may consider testing a live media or an installation of a distro that stays more current than Trixie will be when released. All the Alder Lake
bugs /should/ be gone by now in the latest of everything, /including
Trixie/. Fedora 42 was released in April. openSUSE Tumbleweed gets released as often as 7 days per week. I use both in addition to Trixie and Bookworm. If in such testing the problem remains, surely an upstream bug is involved.

I have also installed Fedora 42:
With Fedora 42 I get something workable:
Using "safe graphics" at boot/install time, it also boots into graphical UI (I chose Fedora KDE) at low resolution (but I forgot to look at /proc/cmdline before I deleted fedora by installing trixie)
However, unlike Debian 12 or 13, it still uses wayland in this low-res mode.
(I couldn't get Debian Trixie to start wayland session when setting "nomodeset", only X11 session)
And in this situation: i.e. Fedora, Kernel 6.14, Wayland, I could rotate the internal screen.
So when I have more time again, I will again install Fedora and probably use that for now. Only 800x600 instead of the full 1280x800 display resolution, but on 8�, that's good enough for now.


Many thanks to all for all helpful hints!
If anybody has still some ideas what I could try, please let me know.

Nomodeset is a troubleshooting workaround that never supports two displays.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

DM composed on 2025-06-09 15:03 (UTC+0200):

Trixie with kernel 6.14:
System:
Kernel: 6.14.10-zabbly+ arch: x86_64 bits: 64 compiler: gcc v: 14.2.0
clocksource: tsc avail: acpi_pm
parameters: BOOT_IMAGE=/vmlinuz-6.14.10-zabbly+
root=/dev/mapper/capys--vg-root ro quiet i915=!46d1 xe=46d1

Did you try the fresh Trixie without forcing Xe?

Have you tried an IceWM (very lightweight) or any other non-Plasma session instead
of of Plasma to confirm whether the internal is black there too? If not black yours would more likely be a Plasma problem, not X or Wayland. Arandr is an available GUI tool you could use instead of xrandr while running IceWM to try rotating the internal, or getting it to light up.

I have also installed Fedora 42:
With Fedora 42 I get something workable:
Using "safe graphics" at boot/install time, it also boots into graphical UI (I
chose Fedora KDE) at low resolution (but I forgot to look at /proc/cmdline

"Safe" usually equates to nomodeset being employed.

before I deleted fedora by installing trixie)
However, unlike Debian 12 or 13, it still uses wayland in this low-res mode.

In Fedora 42, X11 is available for Plasma, but not "supported" by its KDE team members.

(I couldn't get Debian Trixie to start wayland session when setting "nomodeset", only X11 session)
And in this situation: i.e. Fedora, Kernel 6.14, Wayland, I could rotate the internal screen.
So when I have more time again, I will again install Fedora and probably use that for now. Only 800x600 instead of the full 1280x800 display resolution, but on 8°, that's good enough for now.

In fallback modes, such as when using nomodeset, modes are normally limited to standard VESA modes, all of which are 4:3 modes, with possible exception of 1920x1080 with some hardware, and none of which (IIRC) are portrait. 1280x800 is
16:10, not among traditional VESA's standard repertoire.

Nomodeset is a troubleshooting workaround that never supports two displays.

Somewhere in your thread I thought I saw mention use of nomodeset in conjunction
with seeing both displays lit at once running Linux. I've never been able to make
that happen with any distro or kernel on upwards of at least 50 computers.

Now should be better than later to try submitting a Debian bug report about this.
It ought to be fixable if you don't have faulty mini firmware.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Montag, 9. Juni 2025, 15:57:24 CEST schrieb Felix Miata:

DM composed on 2025-06-09 15:03 (UTC+0200):

Trixie with kernel 6.14:

System:
Kernel: 6.14.10-zabbly+ arch: x86_64 bits: 64 compiler: gcc v: 14.2.0

clocksource: tsc avail: acpi_pm
parameters: BOOT_IMAGE=/vmlinuz-6.14.10-zabbly+
root=/dev/mapper/capys--vg-root ro quiet i915=!46d1 xe=46d1

Did you try the fresh Trixie without forcing Xe?

Yes, tried both i915 and xe driver on Trixie. And tried both xe and i915 on Bookworm with backports kernel..

Have you tried an IceWM (very lightweight) or any other non-Plasma session instead of of Plasma to confirm whether the internal is black there too? If not black yours would more likely be a Plasma problem, not X or Wayland. Arandr is an available GUI tool you could use instead of xrandr while
running IceWM to try rotating the internal, or getting it to light up.

Yes, didn't use IceWM, but tried xfce without success. But since the problem (blank internal display) starts already right after loading initial Ram disk, I would assume that it is independent of the WM.

(I couldn't get Debian Trixie to start wayland session when setting "nomodeset", only X11 session)
And in this situation: i.e. Fedora, Kernel 6.14, Wayland, I could rotate the internal screen.
So when I have more time again, I will again install Fedora and probably use that for now. Only 800x600 instead of the full 1280x800 display resolution, but on 8�, that's good enough for now.

In fallback modes, such as when using nomodeset, modes are normally limited to standard VESA modes, all of which are 4:3 modes, with possible exception of 1920x1080 with some hardware, and none of which (IIRC) are portrait. 1280x800 is 16:10, not among traditional VESA's standard repertoire.

Unfortunately, my day job keeps me away from the laptop (both in space and time) for the next couple of weeks. But I will try to experiment with specifying different VESA modes at boot. Am I correct in thinking that I would need something like "VGA=1024x768" or similar in my linux cmd line?

Nomodeset is a troubleshooting workaround that never supports two
displays.

Somewhere in your thread I thought I saw mention use of nomodeset in conjunction with seeing both displays lit at once running Linux. I've never been able to make that happen with any distro or kernel on upwards of at least 50 computers.

I did have both screens available - but not as independent displays, only as mirror of each other.
It definitely worked in Fedora 42 in safe graphics mode, and also in some Debian varieties when using "nomodeset", but I am not sure any more, which ones (i.e. which kernel).

Now should be better than later to try submitting a Debian bug report about this. It ought to be fixable if you don't have faulty mini firmware.

I will experiment a bit more in a couple of weeks when I have more time. And if I still don't have a solution then, I'll do that.
Not having done that before, I assume the best way would be to use the "reportbug" tool, right? I am not sure, which package I should specify, so that the report will be read by the relevant people. I would go with "linux- image". But any hints about where I should report this to are very welcome.

Many thanks again for your help!

DM

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 12 Jun 2025 10:58:13 +0200
DM <[email protected]> wrote:

I will experiment a bit more in a couple of weeks when I have more
time. And if I still don't have a solution then, I'll do that.
Not having done that before, I assume the best way would be to use
the "reportbug" tool, right? I am not sure, which package I should
specify, so that the report will be read by the relevant people. I
would go with "linux- image". But any hints about where I should
report this to are very welcome.

Reportbug is correct, and if you don't get the package right, then
whoever reads it will forward it to the (probably) correct one, they
will know more about how the display works. Probably worth trying xorg
to start with. You need to run reportbug on the affected machine i.e.
on HDMI, as it collects various system information as well as your
report.

Something you might try is to download the latest Knoppix CD, and try
that from USB. It's a few years old now, so it may not help, but if it
does you can investigate the modules in use and anything else you can
find in the X log to see what it's doing that's different.

https://www.knopper.net/knoppix-mirrors/index-en.html

This is version 9.1, there is a 9.2 but it was only distributed with a magazine, and is probably only slightly different. It is a hardware
test and troubleshooting distribution based mainly on Debian unstable,
so there is a better chance of getting some useful error messages than
with standard Debian.

--
Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

DM composed on 2025-06-12 10:58 (UTC+0200):

schrieb Felix Miata:

DM composed on 2025-06-09 15:03 (UTC+0200):

(I couldn't get Debian Trixie to start wayland session when setting
"nomodeset", only X11 session)
And in this situation: i.e. Fedora, Kernel 6.14, Wayland, I could rotate >>> the internal screen.
So when I have more time again, I will again install Fedora and probably >>> use that for now. Only 800x600 instead of the full 1280x800 display
resolution, but on 8°, that's good enough for now.

In fallback modes, such as when using nomodeset, modes are normally limited >> to standard VESA modes, all of which are 4:3 modes, with possible exception >> of 1920x1080 with some hardware, and none of which (IIRC) are portrait.
1280x800 is 16:10, not among traditional VESA's standard repertoire.

Unfortunately, my day job keeps me away from the laptop (both in space and time) for the next couple of weeks. But I will try to experiment with specifying different VESA modes at boot. Am I correct in thinking that I would
need something like "VGA=1024x768" or similar in my linux cmd line?

In conjunction with disabling KMS, vga= traditionally will determine mode used in
vtty 1-6 consoles. VESA modes can be found in lookup tables such as at: <https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers> e.g. for 16bit 1024x768 use either vga=791 or vga=0x314, and 24bit either vga=792
or vga=0x318.

When KMS is not disabled, vga can work only for the period between loaded initrd
and KMS engagement. Subsequently, video= is all that can be engaged. With two different displays, an example would be simply video=1440x900 to have both displays running it, or video=eDP-1:1280x800@60e video=HDMI-A-1:1920x1080@60e to
have a laptop run 1280x800 on its internal display, and 1920x1080 on an HDMI connected TV. In this latter case, on the vttys, the TV would run in 1920x1080 mode, but output would be expected to be limited to the upper left corner's 1024x768 framebuffer. With limited function X in effect, these mode specifications
may or may not remain effective. When they do, then full use of each screen can normally be expected. See: <https://www.kernel.org/doc/Documentation/fb/modedb.txt>

Nomodeset is a troubleshooting workaround that never supports two displays.

Somewhere in your thread I thought I saw mention use of nomodeset in
conjunction with seeing both displays lit at once running Linux. I've never >> been able to make that happen with any distro or kernel on upwards of at
least 50 computers.

I did have both screens available - but not as independent displays, only as mirror of each other.
It definitely worked in Fedora 42 in safe graphics mode, and also in some Debian varieties when using "nomodeset", but I am not sure any more, which ones (i.e. which kernel).

Some BIOS/UEFI firmware when allowed to retain some effect will support lighting
both displays, but only in mirrored mode.
...
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)