Wayland 1.19 Is Set To Come Soon As First Update In Nearly One Year

[duby229]

I used to generate video modes when I was using XFree86 -- on CRT monitors to be precise.
Back in the days some vendors provided video modes files for windows (XP and pre era) as an update to set "non-standard" resolutions/refresh

I understand the issue and I feel the pain of ppl still in that situation.
I would assume though that with modern LCD flat-pannels the issue is long gone (at least for the large majority).
Note that messing with modelines/video modes was and is a dangerous thing -- a lot of CRT went into the waste ...

Also a lot of work has gone into Xorg to automatically set the monitor preferred/standard refresh and resolution
Even Xfree86 version 4 was already providing some automatic detection of modes:
https://en.wikipedia.org/wiki/XFree86_Modeline

It's not long gone. A lot of displays have really bugged EDIDs... It's -very- common. And it's well known...

[Grinness]

It's not long gone. A lot of displays have really bugged EDIDs... It's -very- common. And it's well known...

TBH I believe that you are fighting a seriously uphill battle here -- maybe time to choose the hardware more wisely or to get rid of the old fridge ...
Nowadays the hardware is handled by the kernel, not by display server/protocol/implementation:

In the good old days when graphics parameters were configured explicitly in a file called xorg.conf, even broken hardware could be managed.

Today, with the advent of Kernel Mode Setting, a graphics board is either correctly working because all components follow the standards - or the computer is unusable, because the screen remains dark after booting or it displays the wrong area.
[...]

https://www.kernel.org/doc/html/latest/admin-guide/edid.html

[rabcor]

Wayland is a Protocol, while it is quite old now, stable display servers supporting it only showed up in the last 3 years. That mainly has to do with nearly no one creating one from scratch but adding Wayland display server functionality to their existing Xorg compositors aka Mutter & Kwin.

And now today, there is not really any reason left to not use a modern Desktop with a nice stable fast wayland display server.

There exists a reason, I'm a gamer, and like many gamers, I have an Nvidia GPU, and because I have an Nvidia GPU, I pretty much just cannot run any wayland compositors, because none of them have opted to support Nvidia GPUs (at least not on it's proprietary drivers)

I know Nvidia's to blame for this, of course I know that, but that does not change the facts of the situation. I can't use wayland, it's not a legitimate option for me.

[oiaohm]

I would also like to mention that -MANY- displays, especially TVs, have really bugged EDIDs.... The ability to set custom display modes is -critical- for a lot of people.

It's not like this is news, it's -WELL- known...

Yes then you repeat.

It's not long gone. A lot of displays have really bugged EDIDs... It's -very- common. And it's well known...

So common and well known that all the mainline Linux kernel graphics drivers have decided on a universal way to replace EDID with a file from the /dev/firmware directory.

Buggy EDID should really be fixed by replacing the EDID information not userspace hacking around.

There is something you have missed as well.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_edid_load.c

"Do not probe monitor, use specified EDID blob " "from built-in data or /lib/firmware instead. "

There is very important reason why this is written the way it is particularly the "Do not probe monitor". Badly bugged EDIDs on monitors is worse than you think. Some are that bad that you probe the monitor to acquire the EDID you have now locked the device into black screen of death mode requiring a power cycle to fix. Yes those have the requirement you must never ever prob the monitor for the EDID information because as soon as you do its screwed.

EDID problems need to be handled as early as possible waiting until Wayland compositor/X11 server has started can be past the point of failure already. Correct fix to a EDID problem is fixed at kernel start and possible even earlier.

Yes it one of the weaknesses of EFI firmware as well no means to override monitor EDID to over come the worst monitors. Yes EFI fast start mode completely skipping graphical is EFI solution to badly bugged monitors. Ok leaves you screwed if you want to reconfigure firmware with the buggy monitor connected as the only monitor.

duby229 this is the problem xrandr is no help with the worst monitor EDID issues. The correct fix is override the EDID every single time. Nvidia binary driver does have the weakness that you cannot provide EDID early so it always probes the monitor so it always bricks the monitors with the worse EDID issues.

There is a absolute requirement to deal with this problem very early. Nvidia binary drivers are broken in this department. Yes you can do EDID override inside the x.org configure file with Nvidia binary drivers for monitors that did not brick because Nvidia binary driver stupidly probed them.

This is happening over and over again where the open source mainline drivers have fixed particular problems fully and the Nvidia binary driver only has a part fix.

[oiaohm]

I pretty much just cannot run any wayland compositors, because none of them have opted to support Nvidia GPUs (at least not on it's proprietary drivers)

This is not true that none of them have opted to support Nvidia GPUs with proprietary drivers. KDE with plasma has one of Nvidia own developer working on Wayland support with their binary drivers. One problem Nvidia own developer who has complete internal Nvidia access cannot get it to work properly. So what chance does anyone else implementing a Wayland compositor stand when Nvidia own developers cannot do it and they are saying they are going to need to get the Nvidia binary blobs modified so it can work.

This is basically the nightmare is even wayland compositors who opt to support the Nvidia binary drivers run into major nightmares that the features you need to a wayland compositor to work right don't exist in eglstreams. This is only compounded by the fact Nvidia does not support Xwayland either.

The reality those with Nvidia cards are basically screwed and its not that all the of the wayland compositors opting not to support Nvidia GPUs with proprietary drivers its the fact that even if they opt to support Nvidia GPUs with binary drivers at this stage it cannot be made work because the Nvidia drivers is missing the need functionality.

[duby229]

TBH I believe that you are fighting a seriously uphill battle here -- maybe time to choose the hardware more wisely or to get rid of the old fridge ...
Nowadays the hardware is handled by the kernel, not by display server/protocol/implementation:

https://www.kernel.org/doc/html/latest/admin-guide/edid.html

Uphill battle for certain... Now we're stuck in scenario where nothing can be done about it... It's so uphill it's vertical...

[oiaohm]

Uphill battle for certain... Now we're stuck in scenario where nothing can be done about it... It's so uphill it's vertical...

That is not true that nothing can be done about it. You have Nvidia cards using nvidia binary blob that is where you are stuck in particular cases of bad EDID data.

Xrandr custom modes are coming really limited function.

There is a need for a tool to simply make new EDID files with Linux.

The way around monitors with EDID issues under Windows is also override the EDID the monitor provides with a file.

https://docs.microsoft.com/en-us/windows-hardware/drivers/display/overriding-monitor-edids

Yes this also results in do not probe monitor for EDID. Mac OS also has the same. Freebsd has the same because its imported the Linux graphics stack with the EDID override stuff.

duby229 this is the catch every major OS vendor has basically agreed on the same solution to broken EDID on monitors with the same functional pattern that include do not probe the monitor with broken EDID for a EDID and provide a replacement EDID on disc somewhere.

Xrandr custom monitor modes is the old method and will not deal with all the different monitors with EDID issues. Particular the worst issues where you probe monitor for EDID and the screen goes black and stays that way.

Xrandr custom modes need to be put in the bin of history going forwards it not a functional solution.

[verude]

Changing resolution is accomplished by using the settings panel of the DE/DM (supporting wayland)
In Gnome 3 go to Settings -> Displays.
There you can change:
Orientation
Resolution
Refresh rate
Scale
...


all according to the capabilities of your monitor.
Similar in KDE.

If your DE/DM does not support wayland, use XRANDR (Xorg/X11 specific extension) as you will be using X11 anyway

plenty of buggy hardware exists which doesn't expose resolutions and refresh rates it can handle in the edid, xrandr can be used to add those values, and most DEs don't have this option neither on wayland nor xorg (but will recognize options added by xrandr if running on xorg). At this point I think the only wayland environment that allows to add custom resolution is sway. So no, gnome doesn't accomplish what that user wanted.

[duby229]

Yes then you repeat.



So common and well known that all the mainline Linux kernel graphics drivers have decided on a universal way to replace EDID with a file from the /dev/firmware directory.

Buggy EDID should really be fixed by replacing the EDID information not userspace hacking around.

There is something you have missed as well.

https://git.kernel.org/pub/scm/linux...rm_edid_load.c

"Do not probe monitor, use specified EDID blob " "from built-in data or /lib/firmware instead. "

There is very important reason why this is written the way it is particularly the "Do not probe monitor". Badly bugged EDIDs on monitors is worse than you think. Some are that bad that you probe the monitor to acquire the EDID you have now locked the device into black screen of death mode requiring a power cycle to fix. Yes those have the requirement you must never ever prob the monitor for the EDID information because as soon as you do its screwed.

EDID problems need to be handled as early as possible waiting until Wayland compositor/X11 server has started can be past the point of failure already. Correct fix to a EDID problem is fixed at kernel start and possible even earlier.

Yes it one of the weaknesses of EFI firmware as well no means to override monitor EDID to over come the worst monitors. Yes EFI fast start mode completely skipping graphical is EFI solution to badly bugged monitors. Ok leaves you screwed if you want to reconfigure firmware with the buggy monitor connected as the only monitor.

duby229 this is the problem xrandr is no help with the worst monitor EDID issues. The correct fix is override the EDID every single time. Nvidia binary driver does have the weakness that you cannot provide EDID early so it always probes the monitor so it always bricks the monitors with the worse EDID issues.

There is a absolute requirement to deal with this problem very early. Nvidia binary drivers are broken in this department. Yes you can do EDID override inside the x.org configure file with Nvidia binary drivers for monitors that did not brick because Nvidia binary driver stupidly probed them.

This is happening over and over again where the open source mainline drivers have fixed particular problems fully and the Nvidia binary driver only has a part fix.

I have no intention of ever responding to your walls of total nonsense ever again, but...

Here you are blaming -everyone and everything- else besides the -ONE- thing that blame actually belongs on.... Geez...

EDIT: Classic blame shifting... When you won't assign blame to where it belongs so literally everything else and anything else is blamed...

[oiaohm]

I have no intention of ever responding to your walls of total nonsense ever again, but...

Here you are blaming -everyone and everything- else besides the -ONE- thing that blame actually belongs on.... Geez...

EDIT: Classic blame shifting... When you won't assign blame to where it belongs so literally everything else and anything else is blamed...

This is not classic blame shifting there is mechanic side to this problem. Really you did not read it did you.