Bug 31654

Thank you for the report.

> install of Mageia 9 beta 1
The Classic ISO?

> does not detect intel graphics card, and propose vesa instead of intel driver
Did you have a choice of changing this during the installation?
Did the system fail to install; or re-boot successfully afterwards?
Have you been able to re-boot to a graphical desktop somehow?
Have you been able to change to the correct Intel driver?

Futher questions depend on whether the installed system is accessible or not.

CC: (none) => lewyssmith

The correct display driver for Intel IGPUs is usually modesetting, the upstream default, and not separately packaged:
# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation RocketLake-S GT1 [UHD Graphics 730] (rev 04)
# rpm -qa | grep intel
lib64drm_intel1-2.4.115-1.mga9
# rpm -qf /usr/lib64/xorg/modules/drivers/modesetting_drv.so
x11-server-common-21.1.7-1.mga9
# grep -iE 'loaded|intel|modes' /var/log/Xorg.0.log | grep -viE 'set\(0\)|HDA'
[   632.953] (II) "glx" will be loaded by default.
[   632.961] (==) Matched intel as autoconfigured driver 0
[   632.961] (==) Matched modesetting as autoconfigured driver 1
[   632.961] (II) LoadModule: "intel"
[   632.962] (WW) Warning, couldn't open module intel
[   632.962] (EE) Failed to load module "intel" (module does not exist, 0)
[   632.962] (II) LoadModule: "modesetting"
[   632.962] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
[   632.962] (II) Module modesetting: vendor="X.Org Foundation"
[   632.962] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[   633.563] (II) AIGLX: Loaded and initialized iris
#

CC: (none) => mrmazda

So you have a working system, without saying how.

Your opening comment implied that you had no graphics: "graphics card does not work because vesa driver was selected instead of intel".
At what point was it selected? Was it the *installer* that did not work, or the installed system afterwards on re-booting.

Please post the output of:
 $ inxi -Gxx

"The correct display driver for Intel IGPUs is usually modesetting".
My own system shows differently:
Graphics:
  Device-1: Intel GeminiLake [UHD Graphics 600] driver: i915 v: kernel
  Display: x11 server: X.org v: 1.21.1.7 with: Xwayland v: 22.1.8
    driver: X: loaded: intel,v4l dri: iris gpu: i915

You do need to explain the background more clearly: where the fault happened, the result of the fault, what you did next.

Status: NEW => NEEDINFO

I made it woking by launching XFdrake (drakx11) and choosing "intel" driver manually.

Indeed, after installation, sddm launched, but the image was flickering, and I was unable to interact and hence to log in (I was not able to click button or type text in login fields). I went in console mode (ctrl-alt-Fx) and loged in as root, then launched XFdrake, selected "Graphic card", then chose "intel" in the list (when "vesa" was the auto-selected one), knowing that my hardware was intel.

I have to point out the default choice proposed by XFdrake, even if I launch it again now, is "vesa". Ie. my card driver is still not guessed properly.

# inxi -Gxx
Graphics:
  Device-1: Intel Alder Lake-P Integrated Graphics vendor: Dell driver: i915
    v: kernel arch: Gen-12.2 ports: active: DP-1 off: eDP-1
    empty: DP-2,DP-3,DP-4 bus-ID: 0000:00:02.0 chip-ID: 8086:46a6
  Device-2: WaveRider USB 2.0 Camera type: USB
    driver: snd-usb-audio,uvcvideo bus-ID: 3-3.2:7 chip-ID: 0c46:636b
  Display: wayland server: X.org v: 1.21.1.7 with: Xwayland v: 22.1.8
    compositor: kwin_wayland driver: X: loaded: intel,v4l dri: i965 gpu: i915
    display-ID: 0
  Monitor-1: DP-1 model: LG (GoldStar) HDR 4K res: 3840x2160 dpi: 163
    diag: 690mm (27.2")
  Monitor-2: eDP-1 model: Sharp 0x1551 res: 3840x2400 dpi: 339
    diag: 340mm (13.4")
  API: OpenGL v: 4.6 Mesa 23.0.0 renderer: Mesa Intel Graphics (ADL GT2)
    direct-render: Yes

To summarize: XFdrake, during installation or when launching manually, does not know my intel graphics card, and then automatically choses / offers vesa instead of a more appropriate driver. As a result, a fresh install, with options let by default won’t result in a functionnal system.

I don’t know if I should choose intel or modesetting, but it works perfectly with intel.

Why with so new an iGPU is inxi reporting use of i965 DRI rather than iris DRI?
# pinxi -GSaz --vs --zl --hostname
pinxi 3.3.25-01 (2023-02-07)
System:
  Host: ab560 Kernel: 6.1.14-desktop-1.mga9 arch: x86_64 bits: 64
    compiler: gcc v: 12.2.1 parameters: BOOT_IMAGE=/boot/vmlinuz
    root=LABEL=<filter> noresume audit=0 ipv6.disable=1 net.ifnames=0
    consoleblank=0 video=1440x900@60
  Desktop: Trinity info: kicker wm: Twin vt: 7 dm: 1: TDM 2: XDM
    Distro: Mageia 9
Graphics:
  Device-1: Intel RocketLake-S GT1 [UHD Graphics 730] vendor: ASUSTeK
    driver: i915 v: kernel arch: Gen-12.1 process: Intel 10nm built: 2020-21
    ports: active: DP-1,HDMI-A-1,HDMI-A-2 empty: HDMI-A-3 bus-ID: 00:02.0
    chip-ID: 8086:4c8b class-ID: 0300
  Display: x11 server: X.org v: 1.21.1.7 driver: X: loaded: modesetting
    unloaded: vesa alternate: fbdev,intel dri: iris gpu: i915

Following your advice, I switched to modesetting.

Now I have:

# inxi -GSaz --vs --zl --hostname
inxi 3.3.25-00 (2023-02-07)
System:
  Host: localhost Kernel: 6.2.5-desktop-2.mga9 arch: x86_64 bits: 64
    compiler: gcc v: 12.2.1 parameters: BOOT_IMAGE=/boot/vmlinuz-desktop
    root=UUID=62bdc59c-ad67-44cc-bf44-be4f37fb6316 ro splash quiet noiswmd
    resume=UUID=24096731-5068-4d65-866b-76fdeb0944ac audit=0 vga=791
  Desktop: KDE Plasma v: 5.27.2 tk: Qt v: 5.15.7 wm: kwin_wayland vt: 2 dm:
    1: LightDM v: 1.32.0 note: stopped 2: SDDM Distro: Mageia 9
Graphics:
  Device-1: Intel Alder Lake-P Integrated Graphics vendor: Dell driver: i915
    v: kernel arch: Gen-12.2 process: Intel 10nm built: 2021-22+ ports:
    active: eDP-1 empty: DP-1, DP-2, DP-3, DP-4 bus-ID: 0000:00:02.0
    chip-ID: 8086:46a6 class-ID: 0300
  Display: wayland server: X.org v: 1.21.1.7 with: Xwayland v: 22.1.8
    compositor: kwin_wayland driver: X: loaded: modesetting,v4l dri: iris
    gpu: i915 display-ID: 0
  Monitor-1: eDP-1 model: Sharp 0x1551 built: 2021 res: 3840x2400 dpi: 339
    gamma: 1.2 size: 288x180mm (11.34x7.09") diag: 340mm (13.4") ratio: 16:10
    modes: 3840x2400
  API: OpenGL v: 4.6 Mesa 23.0.0 renderer: Mesa Intel Graphics (ADL GT2)
    direct-render: Yes

For the curious:
-a -G  - Adds, if present, possible alternate: kernel modules ca‐
              pable of driving each Device-x (not including the  current
              loaded:).  If  no non-driver modules found, shows nothing.
              NOTE: just because it lists a module does NOT mean  it  is
              available  in  the  system, it's just something the kernel
              knows could possibly be used instead.

              - Adds (AMD/Intel/Nvidia, if  available)  process:  [node]
              built: [years] to arch: item.
[more for nVidia]
------------------------------
Thank you Felix for comment 5.
And Thomas' comment 4 better explains his problem.

In the light of which, assigning to Mageiatools, CC'ing kernel/drivers.

CC: lewyssmith => kernel
Assignee: bugsquad => mageiatools
Summary: XFdrake does not detect intel graphics card, and propose vesa instead of intel driver => XFdrake does not detect Intel Alder Lake-P graphics card, and propose vesa instead of intel driver

I think neefinfo was answered, if not ask again.

This smells like errata would suit if not solved quickly

Is the workaround to manually select modesetting? (comment 2)

Keywords: (none) => FOR_ERRATA9
Status: NEEDINFO => NEW
CC: (none) => fri

As long as x11-driver-video-intel is installed, automagic in X will prefer to use the intel DDX display driver, unless overridden via config file specifying use of the modesetting DIX display driver, or some other (VESA, FBDEV), instead. The modesetting DIX is newer technology, supporting AMD, Intel, NVidia and selected other brand GPUs. Upstream for x11-driver-video-intel hasn't had an official release in about a decade because of the modesetting DIX, but has been kept supported primarily for Intel GPUs too old for support by the modesetting DIX. Both intel DDX and modesetting DIX may be tried by user to determine which provides the better user experience. AFAIK, there is no algorithm suited to making the ideal selection via automagic. All my installations supported by the modesetting DIX are using it, usually on account of not having x11-driver-video-intel installed. Device names enumerated in /sys/class/drm and those utilized within X differ whether intel DDX or modesetting DDX is used. Thus, any required custom configuration involving display devices may need to differ according to which is in use.

Wow :)

So this is hard to solve automatically

Is it possible to boil it down for something suitable for an errata entry;
§ When this problem may appear, and symptoms
§ Procedure a common user can follow to work around it

If Intel GPUs of Gen3 and older can be detected they can be provided installation of x11-driver-video-intel to override upstream default modesetting. Gen4 and up can be expected to be fully functional by not installing x11-driver-video-intel, thus using the upstream default modesetting. A relnote can suggest to try installing x11-driver-video-intel if video errancy is evident using modesetting.

AFAIK the device:

Vendor ID: ‎0x8086
Device ID: ‎0x46a6

is listed in current /usr/share/pci.ids

as

46a6  Alder Lake-P Integrated Graphics Controller

but there is no corresponding entry for the /usr/share/ldetect-lst/pcitable.gz

that classifies that device into group "Intel 810 and later" so that the driver automatically choosen would be the "intel" (DDX) driver. But you also said that with the intel driver the image was flickering (so maybe for that iGPU only can we say without doubt that the modesetting driver is better than the intel driver?)

Just to know, what happens in a configuration with xorg.conf less, i.e. without the /etc/X11/xorg.conf file? Would it start?

From what I could see there is no entry in /usr/share/ldetect-lst/Cards+ for a group of "modesetting" or "Intel Kernel Mode setting", so we can't have that Alder Lake-P iGPU that automatically choose "modesetting" as default,

At the moment, correct me if I'm wrong, we can do two things:

1) add the entry:

0x8086  0x46a6  "Card:Intel 810 and later"

into pcitable for next package upgrade, so that this iGPU is automatically recognized to use the intel (DDX) driver.

2) introduce a new group into Cards+, called "Intel Kernel Modesetting", by adding into "Cards+":

NAME Intel Kernel Mode setting
DRIVER modesetting

and then in pcitable we might add:

0x8086 0x46a6 "Card:Intel Kernel Mode setting"

when we are sure that the modesetting driver is working better than the intel DDX for this specific model. For my tests I've seen there is not a rule where a driver is better than the other, unless the DDX driver is totally broken. On a Intel Whiskey Lake model (UHD 620) for instance I saw the DDX driver is still sligtly faster, while on a Gemini Lake model for instance with "modesetting" rather than "intel" the image on the display is more crisp (means the timing are better) especially on high-contrast images, and also 25% faster on 3D rendering.

CC: (none) => ghibomgx

(In reply to Giuseppe Ghibò from comment #12)
> AFAIK the device:
> 
> Vendor ID: ‎0x8086
> Device ID: ‎0x46a6
> 
> is listed in current /usr/share/pci.ids
> 
> as
> 
> 46a6  Alder Lake-P Integrated Graphics Controller
> 
> but there is no corresponding entry for the
> /usr/share/ldetect-lst/pcitable.gz
> 
> that classifies that device into group "Intel 810 and later" so that the
> driver automatically choosen would be the "intel" (DDX) driver. But you also
> said that with the intel driver the image was flickering (so maybe for that
> iGPU only can we say without doubt that the modesetting driver is better
> than the intel driver?)
> 
> Just to know, what happens in a configuration with xorg.conf less, i.e.
> without the /etc/X11/xorg.conf file? Would it start?
> 
> From what I could see there is no entry in /usr/share/ldetect-lst/Cards+ for
> a group of "modesetting" or "Intel Kernel Mode setting", so we can't have
> that Alder Lake-P iGPU that automatically choose "modesetting" as default,
> 
> At the moment, correct me if I'm wrong, we can do two things:
> 
> 1) add the entry:
> 
> 0x8086  0x46a6  "Card:Intel 810 and later"
> 
> into pcitable for next package upgrade, so that this iGPU is automatically
> recognized to use the intel (DDX) driver.
> 
> 2) introduce a new group into Cards+, called "Intel Kernel Modesetting", by
> adding into "Cards+":
> 
> NAME Intel Kernel Mode setting
> DRIVER modesetting
> 
> and then in pcitable we might add:
> 
> 0x8086 0x46a6 "Card:Intel Kernel Mode setting"
> 
> when we are sure that the modesetting driver is working better than the
> intel DDX for this specific model. For my tests I've seen there is not a
> rule where a driver is better than the other, unless the DDX driver is
> totally broken. On a Intel Whiskey Lake model (UHD 620) for instance I saw
> the DDX driver is still sligtly faster, while on a Gemini Lake model for
> instance with "modesetting" rather than "intel" the image on the display is
> more crisp (means the timing are better) especially on high-contrast images,
> and also 25% faster on 3D rendering.

What I described can be resumed in this package:

https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-cauldron-x86_64/05896309-ldetect-lst/

installing the provided ldetect-lst-0.6.49-4.mga9 should allow drakx11 to suggests modesetting for the Alderlake-P iGPU.

I found the problem affects not only AlderLake-P also RaptorLake-P iGPUs with Xe Graphics (can't say anything for RaptorLake-P or AlderLake-P with UHD graphics).

Actually there are 2 problems to fix:

1) drakx11 doesn't recognize either RaptorLake-P and AlderLake-P to suggest the correct driver. I've a fix for this, for ldetect-lst (see above) so that modesetting is suggested.

2) When there is no xorg.conf driver, the "intel" DDX driver is choosen automatically by Xorg, but it doesn't work correctly with Iris DRI from MESA 23.3.0. As a result, the GL driver doesn't work properly (the image just freezes, though the application doesn't crash). I've a fix for this, that I'll try to include in the x11-server package, so that the modesetting driver is choosen instead of the "intel" driver for AlderLake-P and RaptorLake-P when there is no xorg.conf file provided (this scenario for instance happens on the Live ISO).

Created attachment 13856 [details]
patch for AlderLake-P and RaptorLake-P default to modesetting

Fix for x11-server package, to allow Xorg choosing modesetting driver for Alderlake-P and RaptorLake-P with Xe-graphics.

https://wiki.mageia.org/en/Mageia_9_Errata#Intel

Keywords: FOR_ERRATA9 => IN_ERRATA9
Summary: XFdrake does not detect Intel Alder Lake-P graphics card, and propose vesa instead of intel driver => XFdrake does not detect Intel Alder Lake-P & RaptorLake-P GPU, and propose vesa instead of intel/modesetting driver
Status comment: (none) => Update errata at progress

The first part for fixing with the attached patch is included in x11-server-21.1.8-2.mga9. Remain the 2nd part to work on ldetest-lst package (later).

Rest of the fix is in ldetect-lst-0.6.50-1.mga9 package. Please test too.

Launching drax11 with my AlderLake-P graphical card now defaults to «Intel > Kernel mode setting» as expected, thanks.

(In reply to Thomas Bigot from comment #19)

> Launching drax11 with my AlderLake-P graphical card now defaults to «Intel >
> Kernel mode setting» as expected, thanks.

Try also in a situation without xorg.conf. Just moving the working xorg.conf, e.g. with:

mv /etc/X11/xorg.conf /etc/X11/xorg.conf.working

and then restore it.

Probably MeteorLake with Xe graphics would need the same fixes.

My system now works fine without a xorg.conf file.

I remember having read of some other user deleting xorg.conf and it worked better.

We should write something in our wiki about how/when xorg.conf is used

IIRC, when using some full blown modern DE (or is it dependant on DM?) they take care of settings?  Something along that - this is not my cup of tea.

I cited xorg.conf less because that's the default configuration of the LIVE ISO (at least before configuring on the persistent partition). So if it works there, it would work also on the LIVE.

It's rare any more among other distros to find xorg.conf or xorg.conf.d used for display configuration - unless NVidia's proprietary drivers are installed. As I never install NVidia's drivers on any of my own hardware, I can only gather from various support forums that it's installation utilities always result in xorg.con* file(s). X automagic in conjunction with FOSS drivers usually do a very good job, as long as only one display, and only one GPU, is in use. The component Kscreen2 in Plasma, and similar in various other DE's, are capable of configuring multiple displays, as well as mode management and other display settings. Generally these employ xrandr to make and maintain changes. Arandr is a DE-agnostic tool to generate xrandr scripts that can be used for display management purposes. I have multiple setups utilizing two or three displays. In each I normally manage manually via xrandr scripts, in some cases generated by arandr, but usually manually. When using Plasma, I disable Kscreen2. TDE's display configurator seems content to sit idly by when I'm employing xrandr. My only uses for xorg.con* any more are quite limited, such as for managing DPMS, enabling Ctrl-Alt-BS, disabling compositing, or selecting a specific display driver when more than one competent option is available (e.g. modesetting instead of nouveau).

For testing without xorg.conf i think we can also suggest users to temprarily add boot option noxconf, like we suggest for Live but reverse:
https://wiki.mageia.org/en/Mageia_9_Errata#Non-working_graphics
(which is identical to 8_Errata)

We talk about noxorgconf and not noxconf in  https://wiki.mageia.org/en/Archive:_Mageia_7_Errata#Non-working_graphics
- What is the difference between noxconf noxorgconf?

Also mentioned i.e in
https://bugs.mageia.org/show_bug.cgi?id=26829#c11

(In reply to Morgan Leijström from comment #26)
> - What is the difference between noxconf noxorgconf?

Just seeing them I would expect the former to apply to Wayland and Xorg instead of the latter exclusively to Xorg.

The problem occurs also on RaptorLake-P with UHD graphics, not only with Xe graphics. Basically if you run RaptorLake in single-channel memory RAM instead of dual-channel memory (e.g. you remove a DIMM from the memory slot) it downgrades the Xe graphics to UHD graphics, and also the PCI-ids (from lspcidrake -v |grep VGA) would change.

Are there there are other people with RaptorLake and AlderLake with other IDs?

I have an Intel N100 processor and had some troubles with this GPU at first.  

Here are the steps I took to work around the problem:

Remove /etc/X11/xorg.conf

As root run "Xorg -configure" which generates a xorg.conf file in /root.

Copy the xorg.conf to /etc/X11

Edit the file making the following changes:

Under Section "Device"
 
Driver "modesetting" 
Option "SwapbuffersWait" "False"
Option "TripleBuffer"  "False"
Option "TearFree" "False"

The only one that was significant was Driver "modesetting". 

Everything also seems to work well, if not better, under Plasma Wayland.

CC: (none) => arichter

(In reply to Alan Richter from comment #29)

> I have an Intel N100 processor and had some troubles with this GPU at first.
> 
> 
> Here are the steps I took to work around the problem:
> 
> Remove /etc/X11/xorg.conf
> 
> As root run "Xorg -configure" which generates a xorg.conf file in /root.
> 
> Copy the xorg.conf to /etc/X11
> 
> Edit the file making the following changes:
> 
> Under Section "Device"
>  
> Driver "modesetting" 
> Option "SwapbuffersWait" "False"
> Option "TripleBuffer"  "False"
> Option "TearFree" "False"
> 
> The only one that was significant was Driver "modesetting". 
> 
> Everything also seems to work well, if not better, under Plasma Wayland.

That's AlderLake-N with UHD graphics. Can you post output of

lspcidrake -v | grep VGA

?

Here you go:

lspcidrake -v | grep VGA
i915            : Intel Corporation|Alder Lake-N [UHD Graphics] [DISPLAY_VGA] (vendor:8086 device:46d1 subv:8086 subd:7270)

(In reply to Alan Richter from comment #29)
> I have an Intel N100 processor and had some troubles with this GPU at first.
> 
> 
> Here are the steps I took to work around the problem:
> 
> Remove /etc/X11/xorg.conf
> 
> As root run "Xorg -configure" which generates a xorg.conf file in /root.
> 
> Copy the xorg.conf to /etc/X11
> 
> Edit the file making the following changes:
> 
> Under Section "Device"
>  
> Driver "modesetting" 
> Option "SwapbuffersWait" "False"
> Option "TripleBuffer"  "False"
> Option "TearFree" "False"
> 
> The only one that was significant was Driver "modesetting". 
> 
> Everything also seems to work well, if not better, under Plasma Wayland.

Ok, this should be autodetected as modesetting in update ldetect-lst-0.6.51-1.mga9 and x11-server-21.1.8-4.mga9.

I wonder if other chipset are missed (i.e. work bad in intel DDX). E.g. RocketLake-S Anyone  is running on RocketLake?

As noted in previous comments, I use modesetting DIX exclusively on iGPUs new enough for its support:

RocketLake-S GT1 [UHD Graphics 730] chip-ID: 8086:4c8b (CPU i5-11400)
Kaby Lake HD Graphics 630 chip ID: 8086:5912 (CPU i3-7100T)
Kaby Lake HD Graphics 630 chip-ID: 8086:5912 (CPU Pentium G4600)
Haswell HD Graphics 4400 (HSW GT2) chip-ID: 8086:041e (CPU i3-4150T)
Haswell Xeon E3-1200 v3/4th Gen chip-ID: 8086:0402 (CPU Pentium G3220)
Iron Lake Intel HD Graphics (ILK) chip-ID: 8086:0042 (CPU i5-660; Clarkdale)
Eagle Lake GMA 4500 chip-ID: 8086:2e12 (chipset Q45)
Eagle Lake GMA X4500 chip-ID: 8086:2e32 (chipset G41)
Broadwater GMA 3000 chip-ID: 8086:2992 (chipset Q965)
Lakeport GMA 950 chip-ID: 8086:2772 (chipset 945G)

I find no reason to even try the DDX on any of the above. It's unofficially deprecated, as official deprecation can't really happen, since it's required for older iGPUs it supports (which means neither i810e 8086:7125 nor i815 8086:1132).

i915G chip-ID: 8086:2582 is the newest I have not supported by the DIX.

XFdrake didn't detect my Alderlake-N GPU correctly but I'll keep checking when there's a new Xorg out.   Also I do a clean install on this system whenever a new MGA9 RC comes out and I'll update this thread.

(In reply to Felix Miata from comment #33)

> As noted in previous comments, I use modesetting DIX exclusively on iGPUs
> new enough for its support:
> 
> RocketLake-S GT1 [UHD Graphics 730] chip-ID: 8086:4c8b (CPU i5-11400)

Is this RocketLake-S working flawlessly with both intel DDX and modesetting DIX, or with DDX it actually shows the same problem we've seen with AlderLake and RaptorLake ?

> Kaby Lake HD Graphics 630 chip ID: 8086:5912 (CPU i3-7100T)
> Kaby Lake HD Graphics 630 chip-ID: 8086:5912 (CPU Pentium G4600)
> Haswell HD Graphics 4400 (HSW GT2) chip-ID: 8086:041e (CPU i3-4150T)
> Haswell Xeon E3-1200 v3/4th Gen chip-ID: 8086:0402 (CPU Pentium G3220)
> Iron Lake Intel HD Graphics (ILK) chip-ID: 8086:0042 (CPU i5-660; Clarkdale)
> Eagle Lake GMA 4500 chip-ID: 8086:2e12 (chipset Q45)
> Eagle Lake GMA X4500 chip-ID: 8086:2e32 (chipset G41)
> Broadwater GMA 3000 chip-ID: 8086:2992 (chipset Q965)
> Lakeport GMA 950 chip-ID: 8086:2772 (chipset 945G)
> 
> I find no reason to even try the DDX on any of the above. It's unofficially
> deprecated, as official deprecation can't really happen, since it's required
> for older iGPUs it supports (which means neither i810e 8086:7125 nor i815
> 8086:1132).
> 
> i915G chip-ID: 8086:2582 is the newest I have not supported by the DIX.
 
As for freeze, we can only add or move those chipset which are evident that are not working at all, not recognized or that have an evident glitch or artifact in the screen or 3D.

The chipset which are working well with both drivers are left as default setting where they currently are. In some chip the DDX as better performance than modesetting. E.g. Whiskey Lake GT2 (id 8086:3ea0) works fine with both, and with "intel" has an higher frame rate than modesetting in 3D. Consider for instance that some option is not available in the modesetting driver. E.g. e the xorg.conf's option "TearFree" which (apparently) should reduce the screen tearing in the intel driver, on modesetting is not yet recognized (indeed it's actually being merged in the next x11-server release and there is a working patchset [that works with current 21.1.8 sources] here: https://github.com/kerneltoast/xserver),

(In reply to Alan Richter from comment #34)

> XFdrake didn't detect my Alderlake-N GPU correctly but I'll keep checking
> when there's a new Xorg out.   Also I do a clean install on this system
> whenever a new MGA9 RC comes out and I'll update this thread.

Even in the latest ldetect-lst-0.6.51-1.mga ?

To resume, the quick tests are:

1) lspcidrake -v | grep VGA

should show either:

Card:Intel 810 and later: ...

or

Card:Intel Kernel Mode setting (Xorg modesetting): ...

2) removing manually the /etc/X11/xorg.conf file, should allow starting X11 anyway. This is for instance the situation on how the Live ISO starts.

3) running drakx11 (when there is no previous xorg.conf) should offer a card configuration (other than vesa or fbdev).

4) for 3D some simple tests:

- glxgears
- glxspheres64
- glmark2

(use vblank_mode=0 to avoid frame rate of the above being sincronized with LCD frame rate).

5) inxi -G or inxi -Gxx (or -Gxxx) should show a resume of the driver situation.

(In reply to Felix Miata from comment #33)
> As noted in previous comments, I use modesetting DIX exclusively on iGPUs
> new enough for its support:
 
> RocketLake-S GT1 [UHD Graphics 730] chip-ID: 8086:4c8b (CPU i5-11400)
> Kaby Lake HD Graphics 630 chip ID: 8086:5912 (CPU i3-7100T)
> Kaby Lake HD Graphics 630 chip-ID: 8086:5912 (CPU Pentium G4600)
> Haswell HD Graphics 4400 (HSW GT2) chip-ID: 8086:041e (CPU i3-4150T)
> Haswell Xeon E3-1200 v3/4th Gen chip-ID: 8086:0402 (CPU Pentium G3220)
> Iron Lake Intel HD Graphics (ILK) chip-ID: 8086:0042 (CPU i5-660; Clarkdale)
> Eagle Lake GMA 4500 chip-ID: 8086:2e12 (chipset Q45)
> Eagle Lake GMA X4500 chip-ID: 8086:2e32 (chipset G41)
> Broadwater GMA 3000 chip-ID: 8086:2992 (chipset Q965)
  
> Lakeport GMA 950 chip-ID: 8086:2772 (chipset 945G) is the newest I have not supported by the DIX.

Above is a correction of comment #33. The GMA 950 should not have been listed as supported by the DIX.


(In reply to Giuseppe Ghibò from comment #36)
...
> 5) inxi -G or inxi -Gxx (or -Gxxx) should show a resume of the driver
> situation.

If you wish all inxi -G has to report, use -Ga
# inxi -Gaz --vs --zl
inxi 3.3.27-00 (2023-05-07)
Graphics:
  Device-1: Intel RocketLake-S GT1 [UHD Graphics 730] vendor: ASUSTeK
    driver: i915 v: kernel arch: Gen-12.1 process: Intel 10nm built: 2020-21
    ports: active: DP-1,HDMI-A-1,HDMI-A-2 empty: HDMI-A-3 bus-ID: 00:02.0
    chip-ID: 8086:4c8b class-ID: 0300
  Display: x11 server: X.org v: 1.21.1.8 driver: X: loaded: modesetting
    unloaded: vesa alternate: fbdev,intel dri: iris gpu: i915 display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 3600x2640 s-dpi: 120 s-size: 762x558mm (30.00x21.97")
    s-diag: 944mm (37.18")
  Monitor-1: DP-1 pos: primary,bottom-l model: Acer K272HUL serial: <filter>
    built: 2018 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2
    size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9 modes:
    max: 2560x1440 min: 720x400
  Monitor-2: HDMI-A-1 mapped: HDMI-1 pos: top-left model: NEC EA243WM
    serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
    size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
    max: 1920x1200 min: 640x480
  Monitor-3: HDMI-A-2 mapped: HDMI-2 pos: top-right model: Dell P2213
    serial: <filter> built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  API: OpenGL v: 4.6 Mesa 23.1.1 renderer: Mesa Intel Graphics (RKL GT1)
    direct-render: Yes

I'm using my Alderlake-N for work right now with Wayland but lspcidrake -v returns:

lspcidrake -v | grep VGA
Card:Intel Kernel Mode setting (Xorg modesetting): Intel Corporation|Alder Lake-N [UHD Graphics] [DISPLAY_VGA] (vendor:8086 device:46d1 subv:8086 subd:7270)

also inxi -G returns:

inxi -G
Graphics:
  Device-1: Intel Alder Lake-N [UHD Graphics] driver: i915 v: kernel
  Display: server: X.Org v: 22.1.9 with: Xwayland v: 22.1.9 driver: X:
    loaded: modesetting dri: iris gpu: i915 resolution: 3840x2160~60Hz
  API: OpenGL v: 4.6 Mesa 23.1.1 renderer: Mesa Intel Graphics (ADL-N)

Lastly Vulkan and OpenGL both work well both under X11 as well as Wayland.

(In reply to Felix Miata from comment #37)
> (In reply to Felix Miata from comment #33)
> > As noted in previous comments, I use modesetting DIX exclusively on iGPUs
> > new enough for its support:
>  
> > RocketLake-S GT1 [UHD Graphics 730] chip-ID: 8086:4c8b (CPU i5-11400)
> > Kaby Lake HD Graphics 630 chip ID: 8086:5912 (CPU i3-7100T)
> > Kaby Lake HD Graphics 630 chip-ID: 8086:5912 (CPU Pentium G4600)
> > Haswell HD Graphics 4400 (HSW GT2) chip-ID: 8086:041e (CPU i3-4150T)
> > Haswell Xeon E3-1200 v3/4th Gen chip-ID: 8086:0402 (CPU Pentium G3220)
> > Iron Lake Intel HD Graphics (ILK) chip-ID: 8086:0042 (CPU i5-660; Clarkdale)
> > Eagle Lake GMA 4500 chip-ID: 8086:2e12 (chipset Q45)
> > Eagle Lake GMA X4500 chip-ID: 8086:2e32 (chipset G41)
> > Broadwater GMA 3000 chip-ID: 8086:2992 (chipset Q965)
>   
> > Lakeport GMA 950 chip-ID: 8086:2772 (chipset 945G) is the newest I have not supported by the DIX.
> 
> Above is a correction of comment #33. The GMA 950 should not have been
> listed as supported by the DIX.

Yes, but is RocketLake working OK also on DDX? (ok that it works with DIX), but I wonder if it's flawed as AlderLake.

> 
> 
> (In reply to Giuseppe Ghibò from comment #36)
> ...
> > 5) inxi -G or inxi -Gxx (or -Gxxx) should show a resume of the driver
> > situation.
> 
> If you wish all inxi -G has to report, use -Ga
> # inxi -Gaz --vs --zl

That's fine.

(In reply to Alan Richter from comment #38)
> I'm using my Alderlake-N for work right now with Wayland but lspcidrake -v
> returns:
> 
> lspcidrake -v | grep VGA
> Card:Intel Kernel Mode setting (Xorg modesetting): Intel Corporation|Alder
> Lake-N [UHD Graphics] [DISPLAY_VGA] (vendor:8086 device:46d1 subv:8086
> subd:7270)

That's expected, it's now recognized as modesetting.

> 
> also inxi -G returns:
> 
> inxi -G
> Graphics:
>   Device-1: Intel Alder Lake-N [UHD Graphics] driver: i915 v: kernel
>   Display: server: X.Org v: 22.1.9 with: Xwayland v: 22.1.9 driver: X:
>     loaded: modesetting dri: iris gpu: i915 resolution: 3840x2160~60Hz
>   API: OpenGL v: 4.6 Mesa 23.1.1 renderer: Mesa Intel Graphics (ADL-N)
> 
> Lastly Vulkan and OpenGL both work well both under X11 as well as Wayland.


I think it works fine then and recognized. drakx11 should also set in the right entry since the beginning.

(In reply to Felix Miata from comment #9)
> All my installations supported by the modesetting
> DIX are using it, usually on account of not having x11-driver-video-intel
> installed. Device names enumerated in /sys/class/drm and those utilized
> within X differ whether intel DDX or modesetting DDX is used. Thus, any
> required custom configuration involving display devices may need to differ
> according to which is in use.

This for me is no small consideration, as this is a test box with 12 (currently) installed distros, and multi-display setup via symlinks to xrandr scripts on a filesystem shared by all distros. Individual scripts per distro/installation are unduly cumbersome, and must differ according to DDX/DIX in use. E.g.
1: using modesetting DIX, regardless of GPU, and on nouveau DDX: 
DP-1
HDMI-1
HDMI-2
2- using intel DDX:
DP1
HDMI1
HDMI2
3- using amdgpu DDX or radeon DDX:
DisplayPort-0
HDMI-0
HDMI-1

(In reply to Giuseppe Ghibò from comment #39)
> but is RocketLake working OK also on DDX? (ok that it works with DIX),
> but I wonder if it's flawed as AlderLake.

Using intel DDX, the DM comes up with all 3 displays mirrored on the least common denominator resolution, which remains when IceWM launches in the absence of startup xrandr script to set resolutions and positions. Glxgears started via Xterm is doing 59.950 FPS, but the graphical gears do not move. Glmark2 I've never been exposed to before, so don't know what to expect. Score: 5162.
# glxspheres64
bash: glxspheres64: command not found
# urpmq  -y glxspheres64
No package named glxspheres64.
#
Returning to DIX, glxgears fully works as expected. 
glmark2 score: 2626 (50.87 % of DDX score, but 4.065 times as fast as my workaday Haswell i3-4150T, also using DIX)

DIX is always here employed unless brief test of DDX is necessary for a particular purpose. I keep x11-xserver-video-intel uninstalled except for any such brief periods, which until formulating this response had never happened on my RKL-S GT1. Due to non-use, I'm not familiar with whatever anomalies or breakage may be common for some of these newer GPUs using the DDX.

> > If you wish all inxi -G has to report, use -Ga
> > # inxi -Gaz --vs --zl
 
> That's fine.

Plain -G and -Gx don't report chip-ID.


Are all ADL with DDX users with complaints being saddled with deprecated i965 DRI?

(In reply to Felix Miata from comment #41)
> (In reply to Felix Miata from comment #9)
> > All my installations supported by the modesetting
> > DIX are using it, usually on account of not having x11-driver-video-intel
> > installed. Device names enumerated in /sys/class/drm and those utilized
> > within X differ whether intel DDX or modesetting DDX is used. Thus, any
> > required custom configuration involving display devices may need to differ
> > according to which is in use.
> 
> This for me is no small consideration, as this is a test box with 12
> (currently) installed distros, and multi-display setup via symlinks to
> xrandr scripts on a filesystem shared by all distros. Individual scripts per
> distro/installation are unduly cumbersome, and must differ according to
> DDX/DIX in use. E.g.
> 1: using modesetting DIX, regardless of GPU, and on nouveau DDX: 
> DP-1
> HDMI-1
> HDMI-2
> 2- using intel DDX:
> DP1
> HDMI1
> HDMI2
> 3- using amdgpu DDX or radeon DDX:
> DisplayPort-0
> HDMI-0
> HDMI-1

This is important to know that the interface names changes according to the driver, as sometimes one have to use those entries (DP1, HDM1, etc.) also in some manual config, so 'DP-1' wouldn't match 'DP1'. Strange it wasn't standardized with some NEW common "predictable" naming scheme, like for ethernet scheme. I also wonder where the xrandr informations are saved by the internal configurators by each desktop (on a per-user basis, and on a per-desktop basis), as this overrides the entries in xorg.conf (either xorg.conf it's used or not) and sometimes, in case of dual monitor wrong configuration, may lead to a user not being able to login anymore, because the windows goes to the wrong configured monitor (maybe disconnected at that point).

> 
> (In reply to Giuseppe Ghibò from comment #39)
> > but is RocketLake working OK also on DDX? (ok that it works with DIX),
> > but I wonder if it's flawed as AlderLake.
> 
> Using intel DDX, the DM comes up with all 3 displays mirrored on the least
> common denominator resolution, which remains when IceWM launches in the
> absence of startup xrandr script to set resolutions and positions. Glxgears
> started via Xterm is doing 59.950 FPS, but the graphical gears do not move.
> Glmark2 I've never been exposed to before, so don't know what to expect.
> Score: 5162.
> # glxspheres64
> bash: glxspheres64: command not found
> # urpmq  -y glxspheres64
> No package named glxspheres64.

glxspheres64 is contained in the package glxspheres-3.0.2-4.mga9

> #
> Returning to DIX, glxgears fully works as expected. 
> glmark2 score: 2626 (50.87 % of DDX score, but 4.065 times as fast as my
> workaday Haswell i3-4150T, also using DIX)
> 
> DIX is always here employed unless brief test of DDX is necessary for a
> particular purpose. I keep x11-xserver-video-intel uninstalled except for
> any such brief periods, which until formulating this response had never
> happened on my RKL-S GT1. Due to non-use, I'm not familiar with whatever
> anomalies or breakage may be common for some of these newer GPUs using the
> DDX.
> 

One of these is the one you get.

> > > If you wish all inxi -G has to report, use -Ga
> > > # inxi -Gaz --vs --zl
>  
> > That's fine.
> 
> Plain -G and -Gx don't report chip-ID.

That sound fine and it also doesn't report the serials which is good for privacy.

> 
> 
> Are all ADL with DDX users with complaints being saddled with deprecated
> i965 DRI?

Yes, considering that 3D is used on any GNOME or Plasma desktop setup, that would result in unpredicatble desktop side effects when it's has some flaw. A latest resource in case of 3D flawed (including in modesetting) might be also to disable the hardware 3D (in Option) and rely on the software CPU llvmpipe 3D renderer, it usually has enough power to play basic 3D stuff (and some old game) and in some virtualization.

(In reply to Felix Miata from comment #41)

> (In reply to Felix Miata from comment #9)
> > All my installations supported by the modesetting
> > DIX are using it, usually on account of not having x11-driver-video-intel
> > installed. Device names enumerated in /sys/class/drm and those utilized
> > within X differ whether intel DDX or modesetting DDX is used. Thus, any
> > required custom configuration involving display devices may need to differ
> > according to which is in use.
> 
> This for me is no small consideration, as this is a test box with 12

12 installations in a single grub2 setup or multiple EFI entries?

> (currently) installed distros, and multi-display setup via symlinks to
> xrandr scripts on a filesystem shared by all distros. Individual scripts per

> [...]
> 
> Using intel DDX, the DM comes up with all 3 displays mirrored on the least
> common denominator resolution, which remains when IceWM launches in the
> absence of startup xrandr script to set resolutions and positions. Glxgears
> started via Xterm is doing 59.950 FPS, but the graphical gears do not move.

gears might not move for two reasons, either 3D is broken or frame overlapping are somewhat synched.

59.950 is the frame rate synched to the display rate. Running "vblank_mode=0 glxgears" would show you the rate of the card on that tiny test.

Probably it's also affected JasperLake (e.g. N6000, N6100) which is of year 2021.

(In reply to Giuseppe Ghibò from comment #42)
> One of these is the one you get.

One of what is the what I get from what?
 
> > Plain -G and -Gx don't report chip-ID.
 
> That sound fine and it also doesn't report the serials which is good for
> privacy.

       -z, --filter
              Adds security filters for IP addresses, serial numbers, MAC, location (-w), and user home directory name.

If serials are wanted to be kept private, append z. Not getting chip ID on the first submission typically leads to asking a supportee to run inxi again using -Gxxz or -Gxxxz or -Gaz, or lspci -nnk | grep -A3 VGA.

> > Are all ADL with DDX users with complaints being saddled with deprecated
> > i965 DRI?
 
> Yes, considering that 3D is used on any GNOME or Plasma desktop setup, that
> would result in unpredicatble desktop side effects when it's has some flaw.
> A latest resource in case of 3D flawed (including in modesetting) might be
> also to disable the hardware 3D (in Option) and rely on the software CPU
> llvmpipe 3D renderer, it usually has enough power to play basic 3D stuff
> (and some old game) and in some virtualization.

Was this supposed to be some justification for continuing use of the deprecated i965 DRI?

(In reply to Giuseppe Ghibò from comment #43)
> > This for me is no small consideration, as this is a test box with 12
 
> 12 installations in a single grub2 setup or multiple EFI entries?

Neither, on that particular PC, same as on all my PCs UEFI booting. One grub2-efi with one EFI entry on ESP is the method, meaning the initial Grub menu always looks the same, unless I make a change in my custom.cfg. Actually, more than one grub2-efi is installed, usable as backup if necessary, but normally rendered impotent by not having the ESP mounted to /boot/efi/, if mounted at all. Every main Grub menu stanza boots from initrd & kernel symlinks, thus no maintenance needed for new or removed kernels. The legacy PCs each boot anywhere between 2 and 40+ installations from a single Grub legacy hosted by a small EXT2 primary (unless the primary bootloader is IBM Boot Manager, in which case Grub is on EXT2 hd0,4), also booting via symlinks, from a rather static menu.lst. Individual installations that still offer Grub legacy may have it installed, but not normally used, nor os-prober. Multiple active Grubs per multiboot PC is nuts, usurping control with each kernel change or new system installation, as anyone heavily experienced in support forums should be able to attest.

(In reply to Felix Miata from comment #45)
> (In reply to Giuseppe Ghibò from comment #42)
> > One of these is the one you get.
> 
> One of what is the what I get from what?

...One of these "broken behaviour".

> > Yes, considering that 3D is used on any GNOME or Plasma desktop setup, that
> > would result in unpredicatble desktop side effects when it's has some flaw.
> > A latest resource in case of 3D flawed (including in modesetting) might be
> > also to disable the hardware 3D (in Option) and rely on the software CPU
> > llvmpipe 3D renderer, it usually has enough power to play basic 3D stuff
> > (and some old game) and in some virtualization.
> 
> Was this supposed to be some justification for continuing use of the
> deprecated i965 DRI?

It's just a extra info for a configuration one can use or test in case of troubles (even in modesetting) e.g. for debugging purposes to detect the origin of the problems.

Anyone running on JasperLake (e.g. N6000, N6005, N5100), ElkhartLake (e.g. Atom 6200) or TigerLake?

X is running correctly, with modesetting, for ADL-N with the current x11-server-xorg. Video playback, openGL and Vulkan all good without a xorg.conf file.

(In reply to Giuseppe Ghibò from comment #47)
> Anyone running on JasperLake (e.g. N6000, N6005, N5100), ElkhartLake (e.g.
> Atom 6200) or TigerLake?

NAICT, Tiger and Rocket are the same thing, except Tiger is low power (laptop) and Rocket is high power (desktop).

(In reply to Felix Miata from comment #49)
> (In reply to Giuseppe Ghibò from comment #47)
> > Anyone running on JasperLake (e.g. N6000, N6005, N5100), ElkhartLake (e.g.
> > Atom 6200) or TigerLake?
> 
> NAICT, Tiger and Rocket are the same thing, except Tiger is low power
> (laptop) and Rocket is high power (desktop).

So, starting from there, they all have the same behaviour as Rocket, and need the same fix.

Changing to *FOR* errata as it need to be updated when dust have settled.

Keywords: IN_ERRATA9 => FOR_ERRATA9

Do we have a status we can condense into a smart text for errata?

Current errata text:

 " XFdrake does not detect Intel Alder Lake-P & RaptorLake-P, and propose vesa driver. Workaround: Manually choose modesetting. "


I note the bug is not marked as fixed and I see several GPU names mentioned that we more or less have same issue with, so would this below be a correct update?:

 " XFdrake does not detect Intel Alder Lake, Jasper Lake, Meteor Lake, Raptor Lake, Rocket Lake, Tiger Lake - and propose the low performance vesa driver. Workaround: Manually choose Xorg > modesetting. "


But I also in comments above also see notes of fixes being implemented, so what really is the current status?

Priority: Normal => High
Severity: normal => major

(In reply to Morgan Leijström from comment #53)

> Current errata text:
> 
>  " XFdrake does not detect Intel Alder Lake-P & RaptorLake-P, and propose
> vesa driver. Workaround: Manually choose modesetting. "
> 
> 
> I note the bug is not marked as fixed and I see several GPU names mentioned
> that we more or less have same issue with, so would this below be a correct
> update?:
> 
>  " XFdrake does not detect Intel Alder Lake, Jasper Lake, Meteor Lake,
> Raptor Lake, Rocket Lake, Tiger Lake - and propose the low performance vesa
> driver. Workaround: Manually choose Xorg > modesetting. "
> 
> 
> But I also in comments above also see notes of fixes being implemented, so
> what really is the current status?

Iin current XFdrake, now, it should choose modesetting for Xorg for those chipsets. Also modesetting is used if there isn't any /etc/X11/xorg.conf file. Better to recheck in current RC1 ISOs with those chipset, then I think we can close the bug.

(In reply to Morgan Leijström from comment #53)
>  " XFdrake does not detect Intel Alder Lake, Jasper Lake, Meteor Lake,
> Raptor Lake, Rocket Lake, Tiger Lake - and propose the low performance vesa
> driver. Workaround: Manually choose Xorg > modesetting. "

Drakx11 (drakx-kbd-mouse-x11-1.38-1) preselects
Vendor|Intel|Kernel Mode settin (Xorg modesetting)
on my Rocket Lake.

Good.  

Can we assume it choose correct driver for all chipsets, close bug, and remove from errata?

Or keep bug open and note something in errata about if graphics is not working ok then try Xorg > modesetting?

(In reply to Morgan Leijström from comment #56)
> Good.  
> 
> Can we assume it choose correct driver for all chipsets, close bug, and
> remove from errata?

Yes.

Removed from errata.

As backup if similar occur again, in:
 https://wiki.mageia.org/en/Setup_the_graphical_server#Intel
the suggestion:
 "If a driver have problems, try Xorg > modesetting."

Resolution: (none) => FIXED
Keywords: FOR_ERRATA9 => (none)
Status: NEW => RESOLVED