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

[clouddrop]

Thanks for your reply with relevant info, yeah, seems only way is/was to create those .bin files...i said "was" because that text provided by you seem to confirm that somehow, now not even that works any more...

sway/wlroots can set custom resolutions in it's config file (since this pr):

*output* <name> mode|resolution|res [--custom] <WIDTHxHEIGHT>[@<RATE>Hz]
Configures the specified output to use the given mode. Modes are a
combination of width and height (in pixels) and a refresh rate that your
display can be configured to use. For a list of available modes for each
output, use *swaymsg -t get_outputs*.

To set a custom mode not listed in the list of available modes, use
*--custom*. You should probably only use this if you know what you're
doing.

Sidenote: Unfortunately in my case it was not sufficient, as my monitor not only has a faulty EDID but also amdgpu (and nvidia as well I think) limits dual DVI to a pixel clock of 330MHz. Had to recompile the kernel and set the pixel clock limit to 250Mhz per link to get my monitor to 96Hz. But that would have been the case with X as well.

[cb88]

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

That's extremely stupid, there should be a reference implementation of every possible feature.... DEs can do what they want, but you shouldn't be required to depend on one (none of which implement all features fully anyway).

[AJSB]

So no one else have any problem with current state of drag and drop on Wayland??

I'm sure that someone will blame the DEs and will say that is nothing to witch Wayland have to deal with...in fact, NOTHING is Wayland's fault :")

[AJSB]

sway/wlroots can set custom resolutions in it's config file (since this pr):

*output* <name> mode|resolution|res [--custom] <WIDTHxHEIGHT>[@<RATE>Hz]
Configures the specified output to use the given mode. Modes are a
combination of width and height (in pixels) and a refresh rate that your
display can be configured to use. For a list of available modes for each
output, use *swaymsg -t get_outputs*.

To set a custom mode not listed in the list of available modes, use
*--custom*. You should probably only use this if you know what you're
doing.

Sidenote: Unfortunately in my case it was not sufficient, as my monitor not only has a faulty EDID but also amdgpu (and nvidia as well I think) limits dual DVI to a pixel clock of 330MHz. Had to recompile the kernel and set the pixel clock limit to 250Mhz per link to get my monitor to 96Hz. But that would have been the case with X as well.

Thanks, can it be possible to that file be used to have several Custom Resolutions / Refresh Rates or is it limited to a single custom mode ?

[Vistaus]

Since open source nvidia driver developers have no documentation It's a shame on nvidia.

Not sure that has anything to do with it as Wayland is still not exactly running nicely on my Intel-only hardware either. So either Intel purged their documentation or the devs aren't reading it.

[Vistaus]

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

Sure, that works for regular resolutions. But what if you want a custom resolution? Not that I think that feature should be implemented with high priority, I'm just saying that that isn't possible with the tools you mentioned.

[Vlad42]

Thanks, can it be possible to that file be used to have several Custom Resolutions / Refresh Rates or is it limited to a single custom mode ?

I have fiddled around with sway and from my recollection, each monitor has its own entry. So, if you have two monitors, then your config file would look something like:

output HDMI1 mode|resolution|res [--custom] <WIDTHxHEIGHT>[@<RATE>Hz]
output eDPI1 mode|resolution|res [--custom] <WIDTHxHEIGHT>[@<RATE>Hz]

To get the list of outputs you run

swaymsg -t get_outputs

in a terminal.

There are a lot of other options that to further configure monitors found in the sway-output(5) manpage and on the official wiki https://github.com/swaywm/sway/wiki.

[Jabberwocky]

Hmmm... during my 20+ years in Linux I have not ever had the need for a custom resolution, it seems that the monitors tend to have the resolutions that I need. And for some reason, I do not think this is a very huge use case. But if that use case is crucial for you, then X is still there. So I do not see why you are whining here.

Custom resolutions was manditory when I started out less than 20 years ago. Okay perhaps not requiring cvt and xrandr newmode/addmode/output functionality but at the very least a custom X11 config. Growing up I had to salvage parts and I came across many screens with wack EDID readings. Today I don't have that problem because I'm buying overpriced 144Hz HDR 1MS IPS gaming screens, but I still remember doing a manual sync balancing once. It wasn't fun, but it was worth the effort in the end. It's like writing your own floating-point library... something you'll never forget.

I agree with cb88 about a reference implementation of every feature. It will cost a fraction of the time that is spent to write and debug everything over and over, such a waste of time.

Edit: fixed some of the typos

[pal666]

So, what is exactly the replacement for XRANDR in Wayland to easily make CUSTOM Resolutions ?

lol, who needs random game to change GLOBAL SCREEN RESOLUTION?

Guess i will stick with X for "some" more time then...

keep us posted

[pal666]

For X we have an UNIVERSAL Tool

you are confusing tool with VULNERABILITY