Custom EDID for boosting VRR rates
I'm semi-newbie to linux stuff (and bad in english), wondered how i can boost VRR rates for my Rog Ally like in CRU for Windows.
Checked via
monitor-edid
for VertRefresh range, but no luck to find it out in X configs. Figured out that i need custom EDID binary to load in kernel.
Imported edited binary from CRU in stock Win, placed in /usr/lib/firmware, rebuild Grub, but no luck.
I realized that I need to also rebuid initramfs, but dracut refuse to do anything with dracut -f
or dracut --force
or dracut --regenerate-all
dracut: Can't write to /boot/efi/541e22dcc49e4aa2acf18fc7d9b6c9fb/6.6.14-202.fsync.x86_64: Directory /boot/efi/541e22dcc49e4aa2acf18fc7d9b6c9fb/6.6.14-202.fsync.x86_64 does not exist or is not accessible.
Any tips? Will be very grateful!73 Replies
oh, and its just fresh install of
bazzite-ally-gnome
You verified the wider range works on windows?
Prep a edid bin file using Cru in windows that you know works
Then somebody else can help you set it up to override the default one
Because I don't know how to do it on bazzite
But I do know in Linux in general
yes i have the custom EDID binary, that works in Win.
trying rebuild with
touch /etc/bazzite/initramfs/rebuild
but seems that will deleting my binary from /usr/lib/firmware
with no changes
vertrefresh stays the same 48-120hzYou can use the edid-decode utility
To see if it's applied
Also you need a kernel command for it to apply
using monitor-edid tool seems legit too
yep, i trying add to grub conf
drm.edid_firmware
and push binary in initramfs by dracut.conf
think im going the wrong way......hmm, looks like im doing everything right
I do not expect the steam refresh rate slider to respond to the edid change
Vrr is not very well fleshed out
Make sure the settings are applied to your current edid
And then test frame timings to see if they are different
what's really the matter with everything: in gamescope it doesn't seem like LFC is working, the frame rate drops to 48 and VRR magic - whoosh - diappears...
On WIN changing vrate in CRU fixes such thing, but there, as i see, thats not working that easy
/usr/
is not writable (and can only be made temporarily writable where it will reset everything on reboot)
you can however to my knowledge do anything required in dracut and initiate a initramfs rebuild like you did and you can use any rpm-ostree initramfs
args inside files in /etc/bazzite/initramfs/args.d/
not really sure about anything else i can help with as i have never needed to add firmware files to my system (other than the defaults that comes with distros) and i also dont have VRR displays so this is way over my head 😅woah, will try this, thx!
https://universal-blue.discourse.group/docs?topic=399
thats the documentation for it
Universal Blue
How to correctly modify initramfs args and dracut in bazzite
In Bazzite we rely on adding things to initramfs for the user, this is done by bazzite-hardware-setup and because the rpm-ostree initramfs command overwrites any previous arguments with the new ones and it is also picky with formatting (you can get the current initramfs arguments from rpm-ostree status | grep -A 4 "●" as opposed to rpm-ostree in...
according to output of
lsinitrd
now my custom EDID now in right place, placed bin into /etc/bazzite/initramfs/args.d/
(such a mess, i know))
also change grub config:
GRUB_CMDLINE_LINUX="drm.edid_firmware=/etc/bazzite/initramfs/args.d/custom-edid.bin"
but no luck, vrate stays the same, hmm...i wouldnt recommend having it in the args.d folder, put the bin in a folder in
initramfs
as there is a script that reads all the files in args.d
and it might cause issues with that
args.d
is supposed to only have text filesoops, my bad
moved bin to ./initramfs/ folder
text files*
anyway no luck, EDID stays the same
did you do edid-decode?
did it say the info of the modified edid?
if not its wrong
drm.edid_firmware=eDP-1:edid/go_hdr.bin
here here is the proper param
check edp-1 matches your display
and actually i dont think you can path it like that, maybe you can
in my case i placed the edid here before updating the initramfs /lib/firmware/edid/
is /lib writeable?no
only
/etc
, /var
and /usr/local
for funzies can it temporarely become writeable?
tried mount rw, but binary deletes after restart
actually no you cant recompile initramfs
will be removed when you reboot
when you do mkinitcpio it bundles the edid file into the ramfs
but I guess thats premade
nah, just stock vertrefresh
@antheas @HikariKnight guys, anyone knows is CONFIG_DRM_LOAD_EDID_FIRMWARE in kernel config enabled?
it's present, we use it for the GPD to fix a display issue
You need to package your initramfs
Dmesg will say whether you loaded the override
this is handled by rpm-ostree
which should be done here
so just check dmesg
Can you do custom initramfs
we already do OOTB
for nvidia drivers & our boot logo
Yeah but he wants a custom custom one
yeah
100% supported/done ootb
So not affected by read only
HikariKnight had the right info ^
follow that and check dmesg
if you do see the edid being loaded in dmesg, it could be gamescope
it does it's own edid patching
there's ways to override that
but verify it loaded your file first in dmesg
just tried
cat mycustomedid.bin > /sys/kernel/debug/dri/5/eDP-1/edid_override
for temporary test, with same result (nope happens)
thx, ill check
@Kyle Gospo sorry for stupid question :^)
but how to search any edid-related info?
dmesg | grep -i 'edid'
show nothingdmesg | grep edid
should show any line containing edid if present
toss me rpm-ostree status
and
rpm-ostree kargs
as i see, grub issue?
believe that should be /etc/bazzite
not etc/bazzite
tried both
and pushed by
grub2-mkconfig -o /boot/grub2/grub.cfg
don't do that
and etc is wrong, so for sure fix that before you continue with any other testing
fixed that
already several times :emoji_18:
but what to use?
happens automatically, nothing
hmm, nothing happens, again
kargs
still misses my edidrpm-ostree kargs --append-if-missing="yourarg=here" --append-if-missing="yourarg2=here"
thx, now appears... but
failed with error -2
What's the intent of this EDID?
wider VRate range
can you show me an example? Might this be something we'd want to just ship by default?
or is this a bit of a hack?
Probably does nothing useful because ally has low framerate compensation and stuff
But it's worth experimenting
more like a hack. thats extends VRR range, bc for me seems LFC not working. FPS drops below 48 and cause weird stutters even in stock Win11
binary was exported from CRU for Win, just changed VRate
FYI for me custom VRate (in
monitor-edid
VertRefresh) does some magic and stuff
even in 1-120hz instead of stock 48-120hz
meh, no way to load this
guys, any workaround?I don't know how to do it on bazzite
But I told you the steps I did and worked
anyway dracut cant let me rebuild initramfs due to:
dracut: Can't write to /boot/efi/541e22dcc49e4aa2acf18fc7d9b6c9fb/6.6.14-202.fsync.x86_64: Directory /boot/efi/541e22dcc49e4aa2acf18fc7d9b6c9fb/6.6.14-202.fsync.x86_64 does not exist or is not accessible.
And seems amd
wants my EDID exactly from /usr/lib/firmware
Otherwise I can’t explain why it doesn’t workyou can't use dracut
rpm-ostree initramfs does this
along with rpm-ostree kargs
@Kyle Gospo long story short (for my educational purposes), i need to:
- put my binary to
/etc/bazzite/initramfs/
- make conf in dracut.conf.d
with install_items+=" path/to/edid "
- add drm.edid_firmware=<..>
arg in rpm-ostree kargs
- run rpm-ostree initramfs --enable
- reboot
right?all but that last part, that's already done for you
last part meaning initramfs --enable
that's done on first boot in bazzite
eh, no way to load binary from /etc or any other dir, same error -2 in dmesg
have a feeling that binary must be in /usr/lib/firmware
instead of the last part you should
sudo touch /etc/bazzite/initramfs/rebuild
since bazzite-hardware-setup handles initramfs on bazzite (takes care of device specific stuff which sometimes get updated in which case your rpm-ostree initramfs --enable
will get overriden and removed (thanks rpm-ostree for working this way 🙃 )
hence why we have you make that rebuild file to tell bazzite-hardware-setup
"hey i need something added to initramfs, please recheck the configs and parse /etc/bazzite/initramfs/args.d/
for additional initramfs parameters and rebuild it with dracut based on its current configs
and yeah binary probably has to be in /usr/lib/firmware
unless /usr/local/lib/firmware
is a thing that would work (dont know if this is a thing)yup, i tried that too)
seems to be
but how, as common user, to put that...
/etc
, /usr/local
and /var
are writable
/usr
is not
hence the suggestion, no idea if it would work though
as this is not something i have ever needed or bothered to do, so all i could offer as help is to at least navigate you through the workaround we have for adding user stuff to initramfs since rpm-ostree does not like "appending" things to initramfs, it only replaces. hence the whole /etc/bazzite/initramfs
folder and its tooling to get around the issue of a bazzite update removing and overwriting any initramfs stuff you have done, just need to tell the tooling that it needs to exist and what to add along with bazzite specific stuff.would be very grateful!
i gave you the documentation for that tooling and how to add initramfs arguments for rpm-ostree into it
essentially in all atomic fedora guides you just replace
rpm-ostree initramfs --enable
with sudo touch /etc/bazzite/initramfs/rebuild
and any other arguments for rpm-ostree initramfs
you add to a file you put in /etc/bazzite/initramfs/args.d
, these args have to be valid rpm-ostree initramfs
args so you cant add all of them into 1 arg with quotes sadly, many of them has to be separated into multiple args (there is an example file there)
if you need to add a dracut config file you can add those as normal to dracut and just sudo touch /etc/bazzite/initramfs/rebuild
to rebuild and it will work as normal.
i think the biggest problem here is that you need to add specific custom firmware files and if these need to be in /usr/lib/firmware
and will not work anywhere else, then that would require you to make a custom image with that firmware file added. (in which case you just add the arguments to /etc/bazzite/initramfs/args.d
, and the firmware file to /usr/lib/firmware
and make build the image and everything else will be automatic in that image (since a new install will always trigger bazzite-hardware-setup
, if you rebase, you might have to touch the rebuild file)>it only replaces
oh wait, i see in /usr/lib/firmware/edid some aokzoe bin.
May i just replace this with my binary, just to avoid extra work?
you cant replace it because
/usr
is not writable
only way to add anything to /usr
is with a custom image
what i meant with rpm-ostree initramfs
only replaces is that if lets say bazzite hardware setup does rpm-ostree initramfs --enable --arg="something=foo"
and you later do rpm-ostree initramfs --enable --arg="thing=bar"
you would expect the end result to be rpm-ostree initramfs --enable --arg="something=foo" --arg="thing=bar"
but no, it will be rpm-ostree initramfs --enable --arg="thing=bar"
as that was the last initramfs arguments that were supplied
this is because rpm-ostree
will throw out any previous initramfs arguments unless you re-specify them, and there is no good clean way to get these arguments as rpm-ostree initramfs
will give you the current initramfs arguments without quotes
rpm-ostree status
will give you the initramfs lines with quotes, but if the user has added anything themselves with rpm-ostree initramfs
then our hardware required args would be gone anyway@Kyle Gospo is it possible, if there will be free time, to force my EDID binary to
:testing
build for -ally
?
I know, that seems like a useless magic, but in my experience that small edit in one hex value makes huge difference in ≤48fps gaming.
Just to make it sure, i pushed Vrate on Win even to 1-120hz, works flawlessly, and seems build-in display capable for wider range with no issueFinally overcame my laziness and trying to build custom for myself
...but, something goes wrong
https://github.com/manyamarco/bazzite/actions/runs/7860532345/job/21447798942
GitHub
Update build.yml · manyamarco/bazzite@68f98dd
Bazzite is an OCI image that serves as an alternative operating system for the Steam Deck, and a ready-to-game SteamOS-like for desktop computers, living room home theater PCs, and numerous other h...
Can't load key from file '/etc/pki/kernel/private/private_key.priv'
i dont know much about the kernel signer but i think you did not provide your own signing key for it.
would be much easier for you to just make a downstream image using something like bluebuild if you are not familiar with configuring all of this
https://blue-build.org/how-to/setup/
that way you can go like "use this bazzite image as base, but add these changes ontop of it"as i see, this kernel signing is only for SecureBoot working properly?
yes, you can remove the step if you do not need secure boot (from my understanding)
thx, complete container building (somehow), will try rebase later
finally made it, but, unfortunately, stuck in boot
seems like thats is not an option, at least on current Mesa version
aaand maybe i figured, why wont loading
extra arg
video=eDP-1:e
needed