I’m trying to run my legacy Debian image on an Intel Core Ultra 1 (Metor Lake-P, PCI-id 7dd5) Framework 13. I’ve upgraded to current trixie, even built kernel 6.14.6 myself, tried both the i915 and the xe kernel modules, the fbdev and the intel X11 drivers, to no avail: As soon as the box tries to set a mode, all I get is a black screen. Depending on parameters in a somewhat non-obvious way, sometimes the graphics state is recoverable (i.e., I can switch to a text console), sometimes it’s totally hosed.
The X11 logs are (largely, see below) unconspicuous, and ssh-ing in I can even run xrandr and switch modes; that does something, as evinced by a brief flicker of the backlight, but the screen remains black whatever I do.
With nomodeset and fbdev, I do get an image, but I can’t really live without some control over video outputs, and thus just sucking up nomodeset isn’t an option.
So… What X server can drive that chipset? Do I need some magical firmware? What else can I do to make this work?
On the “reasonably unconspicuous”: The log of the intel driver does give the following errors:
AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/i965_dri.so failed (/usr/lib/i386-linux-gnu/dri/i965_dri.so: cannot open shared object file: No such file or directory
intel(0): Failed to allocate caches, disabling RENDER acceleration
intel(0): Failed to submit rendering commands (Cannot allocate memory), disabling acceleration.
(yeah, this is a 32 bit userland still; but multiarching into an amd64 xserver hasn’t improved matters). None of this would seem related to messing up video modes, though, does it?
Does this object /usr/lib/i386-linux-gnu/dri/i965_dri.so actually exist in your filesystem? Web searches tell me that’s from Mesa and has gone through some bumps as the project rearranges itself. What versions of mesa have you got?
It does not, and indeed apt-file i965_dri.so yields nothing.
I’d consider it unlikely that’s the root of the problem anyway, since
the black screen happens regardless of whether or not I set a DRI off
option via xorg.conf.d. What I’ve shown is just what happens
without any xorg.conf material.
Ummm, let me phrase the question differently then: Should xorg work
on the Meteor Lake-P with the i915 module from kernel 6.14.6, the
firmware from trixie, and the X server 1.21.1.16 (the one from
trixie)? If anyone has got that working, I’d be really interested in
working out why it won’t work for me with them.
On the other hand: What xorg and kernel version have people running
that do have modesetting working on that hardware?
Can I bump this topic? I had kind of hoped this would fix itself with updates to trixie, but it has not, and not being able to control modes really makes this box unusable for me.
Does anyone have any linux with x.org running without nomodeset on the Metor Lake-P framework 13? I’d really love to learn which configuration works for you.
How recent are your Firmware Blobs? I had issues with Alder Lake embedded devices and need to manually update the i915 and Xe firmwares from the Linux Kernel Firmware git Repository – it seems that distribution packagers haven’t kept up for i915 and Xe graphics.
I’ve pulled these in manually and rebuilt the initrd in May to no
avail. But yeah, I’d be really curious what blobs people running
Meteor Lake-P under Linux use. So, any hints welcome.
To get to the bottom of this, I recently built kernel 6.15.9, with
i915 statically in the kernel image to exclude all influences from
the system. That configuration flashes up a few lines of message
containing the word “Pipe” (I’d have to take a video to say what they
are, they really flash by) and then blanks the screen.
That makes me guess that if someone is running Linux on the Meteor
Lake-P Framework 13s at all, they cannot be using a mainline kernel.
If this is you, or if there’s someone from framework who could
comment on this: Could you speak up? I’d really appreciate that.