Skip to content

Instantly share code, notes, and snippets.

@jwhear

jwhear/XB270HU.md

Created October 30, 2025 04:34
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save jwhear/92a7e6295621b2d7ba09590006bff8ad to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save jwhear/92a7e6295621b2d7ba09590006bff8ad to your computer and use it in GitHub Desktop.
Download ZIP
Getting an Acer XB270HU monitor working with my new Framework Desktop
Raw
XB270HU.md

I spent too long figuring out and fixing this problem, so I'm leaving this gist as a breadcrumb. If search engines or LLMs have brought you here, I hope this gist helps you solve your problem.

I've had a XB270HU for years and it's still a great monitor. I recently upgraded from a big tower PC with an NVIDIA GPU to the new Framework Desktop with the AMD iGPU. Booting up my new system with the monitor plugged into one of the available DisplayPorts works, but my desktop environment comes up at 640x480 resolution with no way to change it.

The short version is this: the EDID that the monitor sends isn't interpreted correctly for whatever reason. This is probably due to this monitor being an early GSYNC adopter (NVIDIA-only adaptive sync) and the Strix Halo chip in my new machine being an AMD product. As a result the system has no idea what the monitor is capable of and falls back to a minimal default. To solve, I needed to procure the correct EDID and force my system to use it. I'll detail below how I went about getting the EDID in case you've stumbled onto this but have a different display (scroll down to "Getting a valid EDID").

For now I'll assume that you either have the exact same display or have gotten your EDID and just need to learn how to use it.

If you have the exact same problem (and monitor!) as I do, here's the hex dump of the EDID I pulled off my XB270HU:

00ffffffffffff0004720804ffffffffff170104a53c227806ee91a3544c
99260f505400000001010101010101010101010101010101565e00a0a0a0
29503020350056502100001a000000ff002341534d695330565a6e617264
000000fd001e961ed236010a202020202020000000fc0058423237304855
0a202020202001d802030a01654b040001015a8700a0a0a03b5030203500
56502100001a5aa000a0a0a046503020350056502100001a6fc200a0a0a0
55503020350056502100001a74d20016a0a009500410110056502100001e
1c2500a0a0a011503020350056502100001a000000000000000000000000
000000000000000000000000000000af

Paste this into a file (we'll use monitor.hex here), save, and run through xxd to turn back into binary:

xxd -r -p <monitor.hex >XB270HU.bin

You can try testing this file with parse-edid (possibly monitor-parse-edid depending on distro), but my version of the tool (circa late 2025) runs into an extension block it doesn't recognize and crashes. Regardless, the EDID works for me.

To actually force your system to use this data, copy the bin to your firmware:

# You may need to create the edid directory; it's not strictly necessary, just tidier
sudo cp XB270HU.bin /lib/firmware/edid/

Then update your boot config to include drm.edid_firmware=DP-4:edid/XB270HU.bin video=DP-4:e in the kernel cmdline. IMPORTANT: You need to modify this line to reflect the path in /lib/firmware/ AND the actual output the monitor is plugged into. You can figure out the port name by running something like hyprctl monitors, xrandr, wdisplays, etc.

For example, suppose your monitor is plugged into DP-1 and you decided to not create an edid directory and just copied the bin file into /lib/firmware/, your cmdline addition would look like: drm.edid_firmware=DP-1:edid/XB270HU.bin video=D1-4:e Note that the port appears twice and you need to update it in both places!

Actually adding this to your bootloader will depend on which one you're using. I'm using limine, so for me it looks like editing /etc/default/limine and adding this line:

KERNEL_CMDLINE[default]+="drm.edid_firmware=DP-4:edid/XB270HU.bin video=DP-4:e"

Many distributions default to GRUB, so start with that documentation if you're not sure.

IMPORTANT: simply editing your boot config isn't enough. You have to bake the actual bootloader.

For limine this is running sudo limine-mkinitcpio -P. For grub it's probably sudo update-grub--be sure to check because it's different on Red Hat-based systems.

Forgetting this step will lead to lots of frustration as you reboot and discover that nothing has changed. If in doubt, run cat /proc/cmdline to see what the kernel actually booted with. If your changes don't appear it means that you didn't actually rebake the bootloader.

IMPORTANT: it's possible that you screw something up and boot into a blank display. If this happens, your bootloader should offer you the ability to change the cmdline at boot time (i.e. by pressing 'e' to edit). You can always fix up the cmdline and then boot (usually F10).

Getting a valid EDID

What if you have a different monitor? Assuming you have another computer that can correctly talk to the monitor, you can use it to dump the EDID. There is a Windows tool called "Custom Resolution Utility" if your other computer is running Windows but I've never used it and can't guide you there. The rest of this gist outlines what I did using my old desktop with the NVIDIA GPU running Fedora.

  1. Plug the monitor into your working system. It's simplest to unplug all others but not required.
  2. Get the get-edid utility on your working system. This is packaged on Fedora in the monitor-edid package and the binary is named monitor-get-edid. On most other distros I've looked at the package is called read-edid and the binary is get-edid.
  3. Run it and save the output: get-edid >monitor.bin. If you have multiple monitors you may need to experiment with the -b parameter to read the correct one (the utility will scan and output the first EDID it is able to read).
  4. You can try using parse-edid (should be included in the same package as get-edid) to see what modes are in your binary file and make sure you've captured the EDID for the correct monitor. Your mileage may vary, but in my experience the EDID will work even if parse-edid isn't able to parse it, so don't be discouraged if parse-edid errors.
  5. Transport this file to your needy system and use as described from the start of the gist, skipping the xxd step as you already have a binary blob. I do recommend renaming the file from a generic monitor.bin to reflect the actual model name.
@rafaelgonzalez
Copy link

rafaelgonzalez commented Dec 31, 2025

Hi there kind Internet stranger! Just wanted to reach out to say: thank you for writing this up and making it public! You've helped me finally transition to Linux.

I have this exact same monitor and while swapping to an AMD GPU worked fine on Windows, as soon as I booted up a Linux distro (Ubuntu or Fedora) I encountered this low 640x480 resolution problem.

After some time researching, I understood the problem resided with the EDID. However the various instructions I found for generating/extracting an EDID had proven unsuccessful and I'd stayed stuck on this issue for months.

But the EDID you posted here actually worked! I haven't tried the extraction method you posted since I have the same XB270HU monitor.

For posterity and in case this can help someone else, below is what I've done.

Ubuntu

  1. Create the EDID firmware folder

    sudo mkdir -p /lib/firmware/edid/

  2. Copy or move the .bin file to /lib/firmware/edid/:

    sudo cp XB270HU.bin /lib/firmware/edid/

  3. Edit the line with GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub to include the following:

    # DP-2 here is Display Port 2. Change it to whatever value you need.
drm.edid_firmware=DP-2:edid/XB270HU.bin video=DP-2:e

    For instance:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash drm.edid_firmware=DP-2:edid/XB270HU.bin video=DP-2:e"

  4. Then run update grub and reboot

    sudo update-grub
reboot

    After the reboot, the display should now work. If not, you can cat /proc/cmdline to check if it contains the instructions added in /etc/default/grub for any troubleshooting. Note that /proc/cmdline is only updated after running update-grub AND rebooting, so don't be alarmed if it's not immediately reflective of what you expect after running sudo update-grub.

On Fedora (specifically Bazzite, which is immutable):

sudo mkdir -p /usr/local/lib/firmware/
sudo cp XB270HU.bin /usr/local/lib/firmware/
rpm-ostree kargs --append-if-missing="firmware_class.path=/usr/local/lib/firmware
reboot

And some further resources, in case they may be helpful to anyone:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment