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

[oiaohm]

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.

The reality here is that xrandr does not work everywhere for custom modes any more with X11. There are quite a few gpus used in arm soc chips that if you attempt to add a mode by xrandr that is not in the EDID that it will completely fail. Of course there is no need to add a mode that is in the EDID if you have not deleted it with those chips either. Yes if you have overridden the EDID everything good. Sway ability to set values not the EDID also fall over dead on these platforms as well. GPU under linux is not required to accept a mode change so this is not a break to user space having a GPU refusing a mode change either.

https://www.kernel.org/doc/html/late...uide/edid.html This has how to load a custom EDID. Custom EDID is the recommend way to fix these problems.
1) it there while in early boot so that a kernel issue can be displayed.
2) it works around monitors that go stupid when EDID is probed.
3) It works with almost all GPUs that Linux supports. Nvidia DRM driver interface for their closed source driver is promised at some point to support this EDID replacement method as well.

Basically one day hopefully in near future the universal solution to fix a EDID issue with Linux would be replace the EDID of the monitor using exactly the same instructions no matter the GPU. Nvidia closed source binary driver is the only one not at this point but you can still use EDID files with it.

Xrandr for adding custom modes is already GPU dependant if you can. Verude I can understand you not notice Xrandr ability to create custom modes going away because you would not be playing with embedded boards with their GPUs. Going forwards fixing bad EDID has a single 100 percent all the time functional path under Linux and FreeBSD.

[rabcor]

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.

Right you are. Again though, the end result is the same, and the fact is that a significant chunk of PC usrs have Nvidia GPUs, in fact among dGPUs even if AMD has finally mostly caught up to Nvidia, most gamers do still have nvidia gpus.

Now back when I bought my laptop about 2 years ago, I would have bought a full on AMD cpu/gpu laptop; but it just wasn't on the table, I had one store, that one store only had intel/nvidia laptops with my performance requirements; in other words it was pretty much out of my hands, I needed a laptop immediately, and getting an AMD one was not a given option, no matter how much I would have preferred it.

Similar cases no doubt happen all the time among linux users... Now it's true that Nvidia dropped the ball on this, but how many years has the open source community had to do what it does best? (Work it's way around stupid problems like this...)

And the closest we've come is the swvkc project, with 2 developers that sadly haven't made much progress over the past year or so (truly interesting project tho). And even if they had; it still relies on GBM right now.

[oiaohm]

Right you are. Again though, the end result is the same, and the fact is that a significant chunk of PC usrs have Nvidia GPUs, in fact among dGPUs even if AMD has finally mostly caught up to Nvidia, most gamers do still have nvidia gpus.

Now back when I bought my laptop about 2 years ago, I would have bought a full on AMD cpu/gpu laptop; but it just wasn't on the table, I had one store, that one store only had intel/nvidia laptops with my performance requirements; in other words it was pretty much out of my hands, I needed a laptop immediately, and getting an AMD one was not a given option, no matter how much I would have preferred it.

Similar cases no doubt happen all the time among linux users... Now it's true that Nvidia dropped the ball on this, but how many years has the open source community had to do what it does best? (Work it's way around stupid problems like this...)

And the closest we've come is the swvkc project, with 2 developers that sadly haven't made much progress over the past year or so (truly interesting project tho). And even if they had; it still relies on GBM right now.

swvkc limitation is something else.

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/chap44.html#VkExternalMemoryHandleTypeFlagBits

This is a good read. There is FD and there DMA BUF where the format eglstreams pass between applications thing that right its not there at all.

There is no eglstreams equal to VK_EXT_image_drm_format_modifier for vulkan either. Basically direct usage of Vulkan is supported by the open source drivers for Linux but in reality not supported by Nvidia binary blob.

The levels of Nvidia broken are just insane. This also kind of explains as well why open source developers were saying to Nvidia just support GBM we have that in the khronos standard for opengl/EGL/Vulkan..... The reality is Nvidia did the submit of eglstreams to khronos then non of the submits to the other parts at khronos to link it in properly.

Open source developers have been attempting to make a fall back with a open source driver for Nvidia cards of course Nvidia has not been playing ball with firmware so that stuff can work well.

rabcor its one thing to point at the open source community but these problems that Nvidia has made the open source developers have tried to work around. There is only so much you can do with a totally not cooperative party. I guess you were not thinking that this problem starts in khronos standard where Nvidia has not done the right things. Then is made worse by Nvidia threatening to DCMA firmware blobs to make open source drivers work. Then Nvidia added signed firmware to their cards so only firmware Nvidia has sign will their cards accept.

Its really simple to say this is just a stupid problem. The problem is this is a problem caused by a jackass company who has basically done everything to make sure its not going to work.

Really like it or not this Nvidia created mess in a lot of ways is out of the open source developers hands.

Rabcor nvidia was told this change was coming a decade ago and in a decade all Nvidia has managed to-do is make a non functional item. Nvidia has totally been ignoring advice and what the khronos group have written into standards as well.

At some point sorry for people like you who bought Nvidia rabcor but there is just no choice to move forwards with the horrible move of just having to declare Nvidia cards defective due to Vendor being a jackass and not providing suitable firmware or drivers. Heck you can techically claim Nvidia drivers are not conforming to Khronos group approved standards and be 100 percent correct.

[Grinness]

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.

I replied on the specifics a few posts above:

Since the introduction of KMS -- Kernel Mode Settings -- creating modes that are not in the EDID is done differently. See:
https://www.kernel.org/doc/html/late...uide/edid.html

It seems to me that all boils down to the use of the nvidia blob.
If this is the case, complain with your vendor -- not with the community driven efforts of improving the overall stack.

If the above is not the case, in the link provided you find info on how to create your EDID and get the kernel to load it

[tildearrow]

Moving to meson-only is also a no-brainer.

At this point any open-source project should no longer be using autotools for compilation, due to its extreme complexity and slow setup.

People say "just do configure, make, make install", but things aren't like this for the developer.

Autotools:
- Write a configure.ac file, which is at the end pretty much like a make script and nothing helps. Often you end up with a 1000 line script here.
- Write a Makefile.am. This ends up being big as well.
- Write an aclocal.m4. I don't even know what is this for but my head is blowing up at this point.
- Learn about 100 more tools, and integrate your project with them.
- Optionally, but usually, write an autogen.sh script. This contains the autoreconf program, because some people will be confused if they don't see the configure file.
- Run autogen.sh. This only creates 100 more files for the build to start.
- Run configure.
- Watch as the thing checks for least important stuff, like if a header nobody uses exists, or if it can add 1+1. It takes like 20 seconds.
- Again, you end up with even more files.
- Type make. Finally, it's building.

CMake or Meson:
- Write a CMakeLists.txt/meson.build file. Often people end up with a long file, but not so long.
- Make a build directory and go to it.
- Do cmake .. or meson ..
- A few files are created. Then do make or ninja. Zero complications.

[microcode]

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

Just because you don't care, doesn't mean people don't use nonstandard modes. For example, my monitor won't tell you it is perfectly capable of running at 24Hz, but if you set the mode it works fine.

I think you are operating under an incorrect assumption that monitors expose all of their valid modes.

[oiaohm]

Just because you don't care, doesn't mean people don't use nonstandard modes. For example, my monitor won't tell you it is perfectly capable of running at 24Hz, but if you set the mode it works fine.

I think you are operating under an incorrect assumption that monitors expose all of their valid modes.

The thing you are missing is every custom mode you can create in a Xrandr you can create in a custom EDID file for a monitor that the OS loads instead of the one the monitor provides be this Windows/Linux/Freebsd or OS X. In fact you can create custom modes in EDID that Xrandr cannot create.

Remember this is not that people cannot use non standard modes just the method is different.

https://sourceforge.net/projects/wxedid/ We are starting to see people provide editors for EDID files.

I am not operating under the idea that monitors expore all of their valid modes. Just try doing a Variable refresh rate mode in Xrandr you will find out you cannot add a variable refresh rate mode by Xrandr but you can add one with a custom EDID and the list just goes on and on and on. Yes you can alter the range of variable refresh rate in custom EDID. Top that off you have GPUs on arm that if you try to set a mode in Xrandr that is not in the EDID it will be rejected.

Also remember the custom EDID does not just fix missing video modes it also is used to fix a monitor with a audio out that is missing or wrongly done in the EDID. Yes I have had to do a EDID for a monitor not because of modes but because the audio out was highly crackly this turned out to be bad EDID as well. Problem monitors will require you to make a custom EDID for audio and screen modes.

microcode the catch here the world has changed Xrandr solution is from a time gone by with a lot simpler monitors without all the features of modern day monitors. EDID standard is updated every time new features comes to monitors while support every feature that a monitor could possible have from day one.

This is really a case should wayland compositors in this department be reinventing the wheel of EDID or should users just tool up and get use to the EDID solution instead. Duplicating format to store the monitor modes is not exactly the wise move.

Changing modes there is a reason to request Wayland compositors do this. Custom modes with custom EDID loadable by kernel it makes sense that wayland compositors don't do this. Now a feature request to Linux kernel to be able to change the EDID on a active monitor might be a good thing.

Remember a EDID fix works for X11 automatic mode acquire and wayland compositor with open source drivers. So you do this change in 1 place and you do everything at once.

This is the big question why do we need two places for creating custom screen modes going forwards. Heck if wayland compositors have their own its why do we need to be able to create custom screen modes with like 30 different places in 30 different ways.

Reality asking for wayland to support custom modes is really asking to reinvent the wheel. The universal wheel for custom modes is custom EDID. Fun part here is when you have made a custom EDID file for a monitor you can go and reuse that in Windows, Mac OS... EDID is truly a universal wheel to this problem and being the universal wheel is more feature complete than the other options.

[microcode]

The thing you are missing is every custom mode you can create in a Xrandr you can create in a custom EDID file for a monitor that the OS loads instead of the one the monitor provides be this Windows/Linux/Freebsd or OS X. In fact you can create custom modes in EDID that Xrandr cannot create.

Remember this is not that people cannot use non standard modes just the method is different.

https://sourceforge.net/projects/wxedid/ We are starting to see people provide editors for EDID files.

I am not operating under the idea that monitors expore all of their valid modes. Just try doing a Variable refresh rate mode in Xrandr you will find out you cannot add a variable refresh rate mode by Xrandr but you can add one with a custom EDID and the list just goes on and on and on. Yes you can alter the range of variable refresh rate in custom EDID. Top that off you have GPUs on arm that if you try to set a mode in Xrandr that is not in the EDID it will be rejected.

Also remember the custom EDID does not just fix missing video modes it also is used to fix a monitor with a audio out that is missing or wrongly done in the EDID. Yes I have had to do a EDID for a monitor not because of modes but because the audio out was highly crackly this turned out to be bad EDID as well. Problem monitors will require you to make a custom EDID for audio and screen modes.

microcode the catch here the world has changed Xrandr solution is from a time gone by with a lot simpler monitors without all the features of modern day monitors. EDID standard is updated every time new features comes to monitors while support every feature that a monitor could possible have from day one.

This is really a case should wayland compositors in this department be reinventing the wheel of EDID or should users just tool up and get use to the EDID solution instead. Duplicating format to store the monitor modes is not exactly the wise move.

Changing modes there is a reason to request Wayland compositors do this. Custom modes with custom EDID loadable by kernel it makes sense that wayland compositors don't do this. Now a feature request to Linux kernel to be able to change the EDID on a active monitor might be a good thing.

Remember a EDID fix works for X11 automatic mode acquire and wayland compositor with open source drivers. So you do this change in 1 place and you do everything at once.

This is the big question why do we need two places for creating custom screen modes going forwards. Heck if wayland compositors have their own its why do we need to be able to create custom screen modes with like 30 different places in 30 different ways.

Reality asking for wayland to support custom modes is really asking to reinvent the wheel. The universal wheel for custom modes is custom EDID. Fun part here is when you have made a custom EDID file for a monitor you can go and reuse that in Windows, Mac OS... EDID is truly a universal wheel to this problem and being the universal wheel is more feature complete than the other options.

But what if instead of authoring a custom quirks file and figuring out how to load that, you just wanted to set a mode you know works, with the timing parameters that are used there anyway.

[oiaohm]

But what if instead of authoring a custom quirks file and figuring out how to load that, you just wanted to set a mode you know works, with the timing parameters that are used there anyway.

This is why tooling is required. Going forwards the only way to-do those changes is modify EDID. How hard that has to be really comes down to the tooling.

Lets be real here you did not care that Xrandr was having to add it into a table structure.

The reality is a EDID based solution can be done 100 percent neutral to X11 or Wayland. There is nothing to say that a EDID editer cannot be a dbus service replicating Xrandr interface. Only problem I see here is currently there is no way to change EDID on a monitor without rebooting is this a wayland problem the answer is no its a kernel limitation.

The reality is the configuring available modes problem is not a Wayland problem. Since most graphical drivers with X11 have moved to KMS(kernel mode setting) configuring modes should not be a X11 problem either going forwards. Configuring graphical modes is now a kernel problem.

You cannot fix something yelling at the wrong party.
The parts you need:
1) ability to change EDID on the fly.
2) ability to fake a monitor disconnect/reconnect (this is way to trigger X11 and Wayland to reget the EDID information.
3) tooling on this to make EDID generation and replacement walk in park.

1 and 2 is kernel work not required if you accept rebooting as a requirement to add/remove modes from monitors. This is no alter wayland protocol work.
3 is not X11 or Wayland work but platform neutral work.

Fun on Xrandr currently cannot set all the timing parameters for a mode EDID can. So yes you can know all the timing setting for a mode and not be able to set it with existing Xrandr.

Like it or not Xrandr is basically end of functional life. We need to move and make Xrandr replacement not just for wayland but for X11 as well.

There are quite a few case where people say Wayland is missing X feature when you look closer its not Wayland protocol responsibility at all.

Changing available modes on a monitor with kernel mode graphics drivers is the kernel responsibility. Tooling to control items that are kernel responsibility the way its done with development of wayland is a dbus service that is neutral to if you are using wayland, X11 or some other solution so not a Wayland protocol problem also not a problem Wayland compositors have to bother about.

[microcode]

Changing available modes on a monitor with kernel mode graphics drivers is the kernel responsibility. Tooling to control items that are kernel responsibility the way its done with development of wayland is a dbus service that is neutral to if you are using wayland, X11 or some other solution so not a Wayland protocol problem also not a problem Wayland compositors have to bother about.

Huh, no. Modes are requested by userspace in most cases, not sure why you are so keen on your position on this, and capable of writing so much fluff boiling down to you not understanding either the subject matter or the use case others see. It's great if you've never dealt with a monitor not exposing your preferred mode, but you are better left out of this conversation.