This is a list of drivers potentially usable by the server.
32.352] (II) glamor: OpenGL accelerated X.org driver based.
Glamor acceleration apparently should be supported by your gfxchip.
But grepping through that logfile reveals that the intel, fbdev, fbdevhw & vesa drivers are unloaded. The intel driver apparently doesn’t exist
It exists only if xf86-video-intel is installed.
the fbdev & vesa drivers seem to have problems
These are fallback drivers. They do not support any widescreen modes or acceleration. They’re OK for servers to run undemanding (slow) GUI maintenance and troubleshooting utilities, but little else. They can be useful when nomodeset has been included on the kernel cmdline, while gfxchip-specific and modesetting X drivers cannot even be loaded.
the vboxvideo & vmware drivers don’t appear in the logfile at all.
Are you a VM user? Is VM software even installed?
That left the modesetting driver:
32.187] (==) Matched modesetting as autoconfigured driver 2
32.247] (II) LoadModule: “modesetting”
32.247] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
32.254] (II) Module modesetting: vendor=“X.Org Foundation”
32.265] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
Modesetting is the xserver’s incorporated generic driver (not gfxchip-specific), the driver that gets the most FOSS developer attention, including devs paid by Intel to do driver work.
So I changed 50-device.conf as follows and the system rebooted cleanly:Section "Device"
[INDENT=2]Identifier “Default Device”
Driver “modesetting”
Option “AccelMethod” “uxa”[/INDENT]
EndSection
UXA is older technology than SNA (for Sandy Bridge, the 2nd Intel iteration that followed your Eagle Lake)
https://en.wikipedia.org/wiki/SNA_(computer_graphics)
grep -A 3 -B 3 “uxa” /var/log/Xorg.0.log now reveals:
31.834] (II) modeset(0): Creating default Display subsection in Screen section
“Default Screen Section” for depth/fbbpp 24/32
31.834] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
31.834] () modeset(0): Option “AccelMethod” “uxa”
31.834] (==) modeset(0): RGB weight 888
31.834] (==) modeset(0): Default visual is TrueColor
31.834] () modeset(0): glamor disabled
I think I can more or less see what’s going on here. Apparently acceleration is now working, but is there any way to confirm this?
Why it says glamor is disabled I don’t have any idea. I suppose you could run glxgears with and without 50-device.conf. Maybe glamor is incompatible with uxa?
The National Map https://nationalmap.gov.au/ still reports:Unusually Slow Performance Detected
It appears that your system is capable of running NationalMap in 3D mode, but is having significant performance issues. We are automatically switching to 2D mode to help resolve this issue. If you want to switch back to 3D mode you can select that option from the Maps button at the top of the screen.
Using an Eagle Lake PC probably much like yours, the modesetting driver, and FF ESR 60.1.0 I get “NationalMap works best with a web browser that supports WebGL, including the latest versions of Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Internet Explorer. Your web browser dows not appear to support WebGL, so you will see a limited, 2D-only experience.”
$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
299 frames in 5.0 seconds = 59.792 FPS
299 frames in 5.0 seconds = 59.792 FPS
299 frames in 5.0 seconds = 59.791 FPS
299 frames in 5.0 seconds = 59.795 FPS
$ inxi -Gxx
Graphics: Card-1: Intel 4 Series Integrated Graphics driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:2e32
Display: server: X.Org 1.18.3 driver: modesetting unloaded: fbdev,vesa alternate: intel
resolution: 1920x1200~60Hz
OpenGL: renderer: Mesa DRI Intel G41 v: 2.1 Mesa 17.0.5 direct render: Yes
$ grep 'model name' /proc/cpuinfo
model name : Intel(R) Core(TM)2 Duo CPU E7600 @ 3.06GHz
model name : Intel(R) Core(TM)2 Duo CPU E7600 @ 3.06GHz
# zypper in xf86-video-intel
$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
302 frames in 5.0 seconds = 60.297 FPS
299 frames in 5.0 seconds = 59.796 FPS
299 frames in 5.0 seconds = 59.796 FPS
299 frames in 5.0 seconds = 59.794 FPS
299 frames in 5.0 seconds = 59.791 FPS
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 4667 requests (4667 known processed) with 0 events remaining.
$ inxi -Gxx
Graphics: Card-1: Intel 4 Series Integrated Graphics driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:2e32
Display: server: X.Org 1.18.3 driver: intel unloaded: fbdev,modesetting,vesa
resolution: 1920x1200~60Hz
OpenGL: renderer: Mesa DRI Intel G41 v: 2.1 Mesa 17.0.5 direct render: Yes
After installing the Intel driver, I get no message, but the URL’s AU map paints very very slowly.
but I assume this is just the slow processor.
How slow is slow? Is this a 2.0GHz Core2Duo or Pentium Dual? There are lots of faster LGA775 CPUs available cheap that you could speed it up some with. Eagle Lake (4th gen) is when Intel was just getting the hang of how to start approaching performance of dedicated GPUs. SNA (Sandy Bridge) is 6th gen.
Using 42.3, a 7th gen (Haswell) and FF ESR 52.9, the graphic painting at that URL doesn’t seem all that much faster.
$ inxi -Gxx
Graphics: Card-1: Intel 4 Series Integrated Graphics driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:2e32
Display: server: X.Org 1.18.3 driver: intel unloaded: fbdev,modesetting,vesa
resolution: 1920x1200~60Hz
OpenGL: renderer: Mesa DRI Intel G41 v: 2.1 Mesa 17.0.5 direct render: Yes
$ grep 'model name' /proc/cpuinfo
model name : Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz
model name : Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz
model name : Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz
model name : Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz
I don’t try for 3D on any of my hardware. A PC screen only has two dimensions, height and width, so I don’t burden myself or hardware trying to fake it. 
I use the modesetting driver in all cases where it works, except for testing, or when forgetting to remove it after a test. 