Arch Linux

mz

Member

Registered: 2024-02-10

Posts: 5

[SOLVED] Has firefox become too bloated for an Eee PC?

Greetings:

I have an Eee PC S101 with fully updated arch32. Firefox can launch and bring up a page, usually, but soon becomes unresponsive and freezes with CPU at 100%. It improved things a bit when I deleted my .mozilla directory but not for long.

Is anyone else running firefox successfully on an old Eee? I'm wondering if it is a lost cause.

Thanks,
-- mz

Last edited by mz (2024-02-19 00:12:29)

abaumann

Administrator

From: Zurich

Registered: 2019-11-14

Posts: 988

Website

Re: [SOLVED] Has firefox become too bloated for an Eee PC?

I was running seamonkey and palemoon in the past (so 3-4 years ago), then also those browser got simply to bloated. Same applies (I guess) for firefox.

A netsurf or a midori might do better on that sort of device.

Eirikr1848

Member

Registered: 2022-04-09

Posts: 23

Re: [SOLVED] Has firefox become too bloated for an Eee PC?

I was running seamonkey and palemoon in the past (so 3-4 years ago), then also those browser got simply to bloated. Same applies (I guess) for firefox.

A netsurf or a midori might do better on that sort of device.

I have a Sony netbook with the same N270 CPU, 2GB RAM and SSD with 8GB swap onto that SSD.

I had to build the latest Mesa again from AUR for the Gallium i915 driver to work properly. Once full hardware acceleration was realized, the GMA 950 was fully working. GMAbooster can be used to lock the clocks at 400MHz for better performance.

Then in Firefox, need to enable Software OpenGL rendering, all the hardware acceleration features under gfx, layers, webgl, dma, rasterization and so forth so that the iGPU handles as much as possible in the browser.

Greetings:

I have an Eee PC S101 with fully updated arch32. Firefox can launch and bring up a page, usually, but soon becomes unresponsive and freezes with CPU at 100%. It improved things a bit when I deleted my .mozilla directory but not for long.

Is anyone else running firefox successfully on an old Eee? I'm wondering if it is a lost cause.

Thanks,
-- mz

I left a few comments above for our like actually really cool developer and maintainer. That being said, here are some “rough draft steps” based on that:

[b]Optimizing ArchLinux32 for GMA 950 Graphics: A Step-by-Step Rough Draft Guide for mz by Eirikr1848[/b]

1. [b]Graphics Driver and Mesa Installation[/b]
- Ensure you're using the Gallium i915 driver for the GMA 950, part of the Intel Gen 3 architecture.
- Update or install the latest Mesa from AUR if necessary, for full hardware acceleration:
[code]yay -S mesa-git[/code]

2. [b]Environment Variable for Gallium i915 Driver[/b]
- Force the Gallium i915 driver usage by setting the environment variable:
[code]export MESA_LOADER_DRIVER_OVERRIDE=i915[/code]
- Add this line to ~/.bashrc or /etc/environment for permanency.

3. [b]Xorg Configuration for Intel Graphics[/b]
- Choose between modesetting and intel DDX drivers.
  - [b]For Modesetting Driver:[/b]
    - Create /etc/X11/xorg.conf.d/20-modesetting.conf with:
[code]
Section "Device"
    Identifier  "Intel Graphics"
    Driver      "modesetting"
    Option      "AccelMethod"    "glamor"
    Option      "DRI"            "3"
    Option      "TearFree"       "true"
EndSection
[/code]
  - [b]For Intel Driver:[/b]
    - Install xf86-video-intel:
[code]sudo pacman -S xf86-video-intel[/code]
    - Create /etc/X11/xorg.conf.d/20-intel.conf with:
[code]
Section "Device"
    Identifier  "Intel Graphics"
    Driver      "intel"
    Option      "AccelMethod"    "sna"
    Option      "FallbackDebug"  "false"
    Option      "TearFree"       "true"
    Option      "DRI"            "3"
EndSection
[/code]

4. [b]Testing and Tweaking[/b]
- Test Xorg configurations by restarting X or using startx. Check /var/log/Xorg.0.log for issues.

5. [b]Optimizing Firefox for Performance[/b]
- In Firefox, enable Software OpenGL rendering and other hardware acceleration features under about:config.

6. [b]Using GMABooster for Enhanced Performance[/b]
- Install GMABooster for controlling GPU clock speeds:
[code]yay -S gmabooster[/code]

7. [b]Creating a Systemd Service for GMABooster[/b]
- Automate GMABooster execution at boot by creating a systemd service file at /etc/systemd/system/gmabooster.service:
[code]
[Unit]
Description=GMAbooster service
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/gmabooster 400
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
[/code]
- Enable and start the service:
[code]
sudo systemctl enable gmabooster.service
sudo systemctl start gmabooster.service
[/code]

[b]References and Resources[/b]
- For detailed configuration options and troubleshooting, consult the [url=https://wiki.archlinux.org/title/Intel_graphics]Arch Wiki on Intel Graphics[/url].

Then here is a draft along the way of the PKGBUILD for i915 only… not sure if this is one of the working ones or not. You probably wanna disable teflon… that was for trying to get tensorflow lite working on these old PCs… including core duo MacBooks with GMA 950 graphics

pkgname=mesa-i915-only-git
pkgver=24.0.0
pkgrel=1
pkgdesc="Mesa with i915 driver only, optimized for Intel Gen 2/3 graphics"
arch=('pentium4')
url="https://mesa.freedesktop.org"
license=('MIT')
makedepends=('git' 'meson' 'ninja' 'python-mako' 'llvm' 'libdrm' 'wayland' 'libx11' 'expat' 'libva' 'libvdpau' 'vulkan-headers' 'glslang' 'zstd' 'libunwind')
provides=("mesa")
conflicts=("mesa")
source=("git+https://gitlab.freedesktop.org/mesa/mesa.git")
sha256sums=('SKIP')

pkgver() {
  cd mesa
  git describe --tags | sed 's/-/+/g'
}

prepare() {
  cd mesa
}

build() {
  cd mesa
  arch-meson build/ \
    -Dplatforms=x11,wayland,drm \
    -Degl-native-platform=x11,wayland,drm \
    -Dgallium-drivers=i915 \
    -Ddri3=true \
    -Dgallium-extra-hud=true \
    -Dgles1=true \
    -Dgles2=true \
    -Dopengl=true \
    -Dgbm=true \
    -Dglx=auto \
    -Degl=true \
    -Dglvnd=true \
    -Dllvm=true \
    -Dshared-llvm=true \
    -Ddraw-use-llvm=true \
    -Dbuild-tests=true \
    -Denable-glcpp-tests=true \
    -Dosmesa=true \
    -Dgallium-nine=true \
    -Dtools=['nir','drm-shim','glsl','intel','intel-ui','dlclose-skip'] \
    -Dzstd=true \
    -Dzlib=true \
    -Dsse2=true \
    -Dshader-cache-max-size=4GB \
    -Dperfetto=true \
    -Ddatasources=['intel'] \
    -Dteflon=true \
    -Dgpuvis=true \
    -Dxmlconfig=enabled \
    --buildtype=release
  ninja -C build
}

package() {
  cd mesa
  DESTDIR="${pkgdir}" ninja -C build install
}

BUT JUST IN CASE you feel like expanding upon this non-functional stub for machine learning on GMA 950?! Ha. Here you go…

 // File: mesa/src/gallium/frontends/tfl_device.c
#include "pipe/p_context.h"
#include "pipe/p_state.h"
#include "util/u_inlines.h"
#include "frontend/tfl_delegate.h"
#include "i915/i915_context.h"
#include "util/u_memory.h"
#include "util/u_debug.h"
#include "frontend/machine_learning_util.h"

// Custom Teflon initialization for TensorFlow Lite with i915 support
void InitializeTeflonWithI915Support() {
    // Initialize the i915 context
    struct pipe_screen *screen = i915_screen_create();
    if (!screen) {
        fprintf(stderr, "Failed to create i915 screen\n");
        return;
    }

    struct pipe_context *context = screen->context_create(screen, NULL, 0);
    if (!context) {
        fprintf(stderr, "Failed to create i915 context\n");
        return;
    }

    // Setup TensorFlow Lite delegate for OpenGL with custom modifications for i915
    TfLiteGpuDelegateOptionsV2 options = TfLiteGpuDelegateOptionsV2Default();
    options.experimental_flags |= TFLITE_GPU_EXPERIMENTAL_FLAGS_ENABLE_QUANT;

    // Incorporate dynamic optimization strategies
    DynamicOptimizationForI915(&options);

    // Custom delegate initialization for i915, leveraging Teflon
    TfLiteDelegate* tflite_delegate = TflDelegateCreate(&options);
    if (!tflite_delegate) {
        fprintf(stderr, "Failed to create TFLite GPU Delegate for i915\n");
        return;
    }

    // Advanced memory management for tensor allocation
    AdvancedMemoryManagementForTensors(context);

    // Use the delegate with TensorFlow Lite model
    // Assuming `interpreter` is a TfLiteInterpreter instance
    TfLiteInterpreterOptionsAddDelegate(interpreter_options, tflite_delegate);

    // Setup custom shaders specific to i915
    I915ConfigureCustomShaders(context);

    // Clean up
    TflDelegateDelete(tflite_delegate);
    context->destroy(context);
    screen->destroy(screen);
}

void DynamicOptimizationForI915(TfLiteGpuDelegateOptionsV2* options) {
    // This function dynamically adjusts options based on i915 capabilities
    // Placeholder for dynamic optimization logic
}

void AdvancedMemoryManagementForTensors(struct pipe_context *context) {
    // Placeholder for advanced memory management strategies
}

// Example function for custom shader configuration on i915
void I915ConfigureCustomShaders(struct pipe_context *context) {
    // Load custom shader library optimized for deep learning tasks
    LoadCustomShaderLibrary(context, "/path/to/custom/shaders");

    // Apply shader optimizations specific to convolution operations
    OptimizeShadersForConvolution(context);
}

void LoadCustomShaderLibrary(struct pipe_context *context, const char* path) {
    // Placeholder for loading custom shader library
}

void OptimizeShadersForConvolution(struct pipe_context *context) {
    // Placeholder for shader optimization for convolution
}

// Main function to execute TensorFlow Lite model with Teflon on i915
void ExecuteModelWithTeflonI915(TfLiteInterpreter* interpreter) {
    // Placeholder for executing TensorFlow Lite model
}

// Additional utility functions for machine learning tasks
void MachineLearningUtil_Init() {
    // Placeholder for initializing machine learning utilities
}

// Implement additional TensorFlow Lite operations support
void ExtendTFLiteOperationSupport() {
    // Placeholder for extending TensorFlow Lite operations support

//This snippet is draft from a brainstorming session only and is non-functional. As such, no license for use is granted. However if utilized in concept or in practicality you are to utilize this only for the Mesa project and all their projects’ licenses will apply at that time. 
}

Clearly this post got out of control. Do consider increasing your ulimit to unlimited while building mesa, (especially if you enable LTO)… but yeah when all is said and done… it works!

Even though it’s a billion steps and a machine learning side thought digression along the way… whoopsies for that!

Last edited by Eirikr1848 (2024-02-14 02:17:03)

abaumann

Administrator

From: Zurich

Registered: 2019-11-14

Posts: 988

Website

Re: [SOLVED] Has firefox become too bloated for an Eee PC?

Ah, thanks for that detailed explanation, really nice, you put quite some effort into that. :-)

Eirikr1848

Member

Registered: 2022-04-09

Posts: 23

Re: [SOLVED] Has firefox become too bloated for an Eee PC?

Ah, thanks for that detailed explanation, really nice, you put quite some effort into that. :-)

Thanks! This is my hobby, and it is fun, and fun hobbies deserve time and effort

I’m just hoping in the end they have a functional Firefox ?.

I do regret not keeping better logs of my steps along the way. I need to get better at documenting what I am doing and storing it on GitHub or even pastebin… or even here! I’m not sure which revision of the PKGBUILD that is… so will need to change any pieces that fail, and disable teflon of course. That aside it’s probably 80% of the way there?

[The digression: Getting machine learning on the i915 drivers for Gen2/Gen3 iGPUs + their paired CPUs is super tricky, but doable. Teflon seemed like it offers the start of a path (and seemed for a bit like it would be a good IR for an iGPU-enhanced SWRAST software Vulkan driver for i915, r300, non-NVK nouveau cards for example).

Explored those routes for awhile… everything I tinkered with ended in a dead end and I just stopped exploring a path forward due to lack of skill, knowledge, motivation, and/or health.

It would require fans of older hardware working together to optimize the Gallium i915 stack. r300 is in progress now (early 2024) and some other driver (SiS??) is getting updates: so with vintage hardware earning a comeback it’s possible for it to run modern Linux with hardware acceleration for browsers, emulators, media centers, these also could have machine learning working.

Odd? Quirky? Esoteric? Seemingly impractical? Certainly. But that’s what makes it fun.]

mz

Member

Registered: 2024-02-10

Posts: 5

Re: [SOLVED] Has firefox become too bloated for an Eee PC?

I'm still on step 1 and I have a problem with makepkg. After compiling for five hours, it reports:

ninja: Entering directory `_build'
ninja: fatal: chdir to '_build' - No such file or directory
==> ERROR: A failure occurred in package().
Aborting...

There is a src/mesa/_build directory. How to I get it to create the package at this point without starting again?

mz

Member

Registered: 2024-02-10

Posts: 5

Re: [SOLVED] Has firefox become too bloated for an Eee PC?

I decided it would be more fruitful to start again, making the bare minimum changes to PKGBUILD. This time it built and installed without incident.

Running X without a config file resulted in this change, and Firefox performs reasonably well in its default configuration.

Before:

[  3751.022] (II) Initializing extension GLX
[  3751.024] (EE) AIGLX error: dlopen of /usr/lib/dri/i915_dri.so failed (/usr/lib/dri/i915_dri.so: cannot open shared object file: No such file or directory)
[  3751.024] (EE) AIGLX error: unable to load driver i915
[  3751.025] (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (libLLVM-14.so: cannot open shared object file: No such file or directory)
[  3751.025] (EE) AIGLX error: unable to load driver swrast
[  3751.026] (EE) GLX: could not load software renderer
[  3751.026] (II) GLX: no usable GL providers found for screen 0

After:

[   315.042] (II) Initializing extension GLX
[   315.213] (II) AIGLX: Loaded and initialized i915
[   315.213] (II) GLX: Initialized DRI2 GL provider for screen 0

I'm going to call this one solved, and check out the other performance suggestions later.

Eirikr1848

Member

Registered: 2022-04-09

Posts: 23

Re: [SOLVED] Has firefox become too bloated for an Eee PC?

I decided it would be more fruitful to start again, making the bare minimum changes to PKGBUILD. This time it built and installed without incident.

Running X without a config file resulted in this change, and Firefox performs reasonably well in its default configuration.

Before:

[  3751.022] (II) Initializing extension GLX
[  3751.024] (EE) AIGLX error: dlopen of /usr/lib/dri/i915_dri.so failed (/usr/lib/dri/i915_dri.so: cannot open shared object file: No such file or directory)
[  3751.024] (EE) AIGLX error: unable to load driver i915
[  3751.025] (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (libLLVM-14.so: cannot open shared object file: No such file or directory)
[  3751.025] (EE) AIGLX error: unable to load driver swrast
[  3751.026] (EE) GLX: could not load software renderer
[  3751.026] (II) GLX: no usable GL providers found for screen 0

After:

[   315.042] (II) Initializing extension GLX
[   315.213] (II) AIGLX: Loaded and initialized i915
[   315.213] (II) GLX: Initialized DRI2 GL provider for screen 0

I'm going to call this one solved, and check out the other performance suggestions later.

YAY! Super glad to see it!!!

1) Do you mind sharing the PKGBUILD you used that ended up working? No pressure, but could help others.

2) In about: support in Firefox do you see Webrender, Webrender (Software), or Webrender (OpenGL)?

Even changing a couple settings to start getting software OpenGL working is huge. Then I think a good portion of the browser canvas is rendered with OpenGL to speed things up further:)

mz

Member

Registered: 2024-02-10

Posts: 5

Re: [SOLVED] Has firefox become too bloated for an Eee PC?

Here is my PKGBUILD:

# Maintainer: Reza Jahanbakhshi <reza.jahanbakhshi at gmail dot com
# Contributor: Lone_Wolf <lone_wolf@klaas-de-kat.nl>
# Contributor: Armin K. <krejzi at email dot com>
# Contributor: Kristian Klausen <klausenbusk@hotmail.com>
# Contributor: Egon Ashrafinia <e.ashrafinia@gmail.com>
# Contributor: Tavian Barnes <tavianator@gmail.com>
# Contributor: Jan de Groot <jgc@archlinux.org>
# Contributor: Andreas Radke <andyrtr@archlinux.org>
# Contributor: Thomas Dziedzic < gostrc at gmail >
# Contributor: Antti "Tera" Oja <antti.bofh@gmail.com>
# Contributor: Diego Jose <diegoxter1006@gmail.com>

pkgname=mesa-git
pkgdesc="an open-source implementation of the OpenGL specification, git version"
pkgver=24.1.0_devel.184875.893780b3625.d41d8cd
pkgrel=1
arch=('i686')
makedepends=('git' 'python-mako' 'xorgproto'
              'libxml2' 'libvdpau' 'libva' 'elfutils' 'libxrandr'
              'wayland-protocols' 'meson' 'ninja' 'glslang' 'directx-headers'
)
depends=('libdrm' 'libxxf86vm' 'libxdamage' 'libxshmfence' 'libelf'
         'libomxil-bellagio' 'libunwind' 'libglvnd' 'wayland' 'lm_sensors'
         'vulkan-icd-loader' 'zstd' 'expat' 'gcc-libs' 'libxfixes' 'libx11' 'systemd-libs' 'libxext' 'libxcb'
         'glibc' 'zlib'
)
optdepends=('opengl-man-pages: for the OpenGL API man pages')
provides=('mesa' 'vulkan-intel' 'vulkan-radeon' 'vulkan-mesa-layers' 'libva-mesa-driver' 'mesa-vdpau' 'vulkan-swrast' 'vulkan-driver' 'mesa-libgl' 'opengl-driver')
conflicts=('mesa' 'opencl-clover-mesa' 'opencl-rusticl-mesa' 'vulkan-intel' 'vulkan-radeon' 'vulkan-mesa-layers' 'libva-mesa-driver' 'mesa-vdpau' 'vulkan-swrast' 'mesa-libgl')
url="https://www.mesa3d.org"
license=('custom')
source=('mesa::git+https://gitlab.freedesktop.org/mesa/mesa.git#branch=main'
             'LICENSE'
)
md5sums=('SKIP'
         '5c65a0fe315dd347e09b1f2826a1df5a')
sha512sums=('SKIP'
            '25da77914dded10c1f432ebcbf29941124138824ceecaf1367b3deedafaecabc082d463abcfa3d15abff59f177491472b505bcb5ba0c4a51bb6b93b4721a23c2')

# NINJAFLAGS is an env var used to pass commandline options to ninja
# NOTE: It's your responbility to validate the value of $NINJAFLAGS. If unsure, don't set it.

# MESA_WHICH_LLVM is an environment variable that determines which llvm package tree is used to built mesa-git against.
# Adding a line to ~/.bashrc  that sets this value is the simplest way to ensure a specific choice.
#
# NOTE: Aur helpers don't handle this method well, check the sticky comments on mesa-git aur page .
#
# 1: llvm-minimal-git (aur) preferred value
# 2: AUR llvm-git
# 3: llvm-git from LordHeavy unofficial repo
# 4  llvm (stable from extra) Default value
#

if [[ ! $MESA_WHICH_LLVM ]] ; then
    MESA_WHICH_LLVM=4
fi

case $MESA_WHICH_LLVM in
    1)
        # aur llvm-minimal-git
        makedepends+=('llvm-minimal-git')
        depends+=('llvm-libs-minimal-git')
        ;;
    2)
        # aur llvm-git
        # depending on aur-llvm-* to avoid mixup with LH llvm-git
        makedepends+=('aur-llvm-git')
        depends+=('aur-llvm-libs-git')
        optdepends+=('aur-llvm-git: opencl')
        ;;
    3)
        # mesa-git/llvm-git (lordheavy unofficial repo)
        makedepends+=('llvm-git' 'clang-git')
        depends+=('llvm-libs-git')
        optdepends+=('clang-git: opencl' 'compiler-rt: opencl')
        ;;
    4)
        # extra/llvm
        makedepends+=(llvm clang)
        depends+=(llvm-libs)
        optdepends+=('clang: opencl' 'compiler-rt: opencl')
        ;;
    *)
esac

pkgver() {
    cd mesa
    local _ver
    _ver=$(<VERSION)

    local _patchver
    local _patchfile
    for _patchfile in "${source[@]}"; do
        _patchfile="${_patchfile%%::*}"
        _patchfile="${_patchfile##*/}"
        [[ $_patchfile = *.patch ]] || continue
        _patchver="${_patchver}$(md5sum ${srcdir}/${_patchfile} | cut -c1-32)"
    done
    _patchver="$(echo -n $_patchver | md5sum | cut -c1-7)"

    echo ${_ver/-/_}.$(git rev-list --count HEAD).$(git rev-parse --short HEAD).${_patchver}
}

prepare() {
    # although removing _build folder in build() function feels more natural,
    # that interferes with the spirit of makepkg --noextract
    if [  -d _build ]; then
        rm -rf _build
    fi

    local _patchfile
    for _patchfile in "${source[@]}"; do
        _patchfile="${_patchfile%%::*}"
        _patchfile="${_patchfile##*/}"
        [[ $_patchfile = *.patch ]] || continue
        echo "Applying patch $_patchfile..."
        patch --directory=mesa --forward --strip=1 --input="${srcdir}/${_patchfile}"
    done
}

build () {
    meson setup mesa _build \
       -D b_ndebug=true \
       -D b_lto=false \
       -D platforms=x11,wayland \
       -D gallium-drivers=r300,r600,radeonsi,nouveau,virgl,svga,swrast,i915,iris,crocus,zink,d3d12 \
       -D vulkan-drivers=amd,intel,swrast,virtio,intel_hasvk \
       -D vulkan-layers=device-select,overlay \
       -D dri3=enabled \
       -D egl=enabled \
       -D gallium-extra-hud=true \
       -D gallium-nine=true \
       -D gallium-omx=bellagio \
       -D gallium-opencl=disabled \
       -D gallium-va=enabled \
       -D gallium-vdpau=enabled \
       -D gallium-xa=enabled \
       -D gbm=enabled \
       -D gles1=disabled \
       -D gles2=enabled \
       -D glvnd=true \
       -D glx=dri \
       -D libunwind=enabled \
       -D llvm=enabled \
       -D lmsensors=enabled \
       -D osmesa=true \
       -D shared-glapi=enabled \
       -D microsoft-clc=disabled \
       -D valgrind=disabled \
       -D tools=[] \
       -D zstd=enabled \
       -D video-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc,av1dec,av1enc,vp9dec \
       -D buildtype=plain \
       --wrap-mode=nofallback \
       -D prefix=/usr \
       -D sysconfdir=/etc

    meson configure --no-pager _build

    ninja $NINJAFLAGS -C _build
}

package() {
    DESTDIR="${pkgdir}" ninja $NINJAFLAGS -C _build install

    # remove script file from /usr/bin
    # https://gitlab.freedesktop.org/mesa/mesa/issues/2230
    rm "${pkgdir}/usr/bin/mesa-overlay-control.py"
    rmdir "${pkgdir}/usr/bin"

    # indirect rendering
    ln -s /usr/lib/libGLX_mesa.so.0 "${pkgdir}/usr/lib/libGLX_indirect.so.0"

    install -m644 -Dt "${pkgdir}/usr/share/licenses/${pkgname}" "${srcdir}/LICENSE"
}

Firefox is acting badly again this morning and won't even bring up the about:support page. I'm going to see what I can do with an xorg.conf.

mz

Member

Registered: 2024-02-10

Posts: 5

Re: [SOLVED] Has firefox become too bloated for an Eee PC?

I see Webrender (Software) with both types of xorg.conf.

I am also getting crashes with both types of xorg.conf when I try to open multiple tabs.

[Edit]

The crashes always occurred after I opened a new tab and started typing a URL, so I disabled autofill and now it never crashes.

Trying the modesetting driver:

[  8875.394] (WW) glamor requires at least 128 instructions (64 reported)
[  8875.394] (EE) modeset(0): Failed to initialize glamor at ScreenInit() time.
[  8875.395] (EE)
Fatal server error:
[  8875.395] (EE) AddScreen/ScreenInit failed for driver 0

Deleting the glamor line changed nothing. Using the 20-intel.conf file works fine.

Last edited by mz (2024-03-02 21:17:43)