Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Comment


    • #22
      Originally posted by AJSB View Post

      I DON'T want just change resolution to something that the Monitor officially already supports, i want to CREATE a CUSTOM Resolution, for what you are saying, THAT will NOT do it.

      Ergo my previous comment about need to create a*.bin file (a customized forced EDID, actually, ) and edit a bunch of files ,etc. to make it work.

      In all these Years NO ONE (even Wayland devs that knowing the ins and outs of Wayland could have provided such a tool even if its not itself part of Wayland,) managed to make a program like XRANDR that would do this is in a easy like in Wayland no matter so many users need this...

      Anyway, AFAIK, as long as such thing doesn't exist, Wayland is not an option for me, EOD.


      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.

      Comment


      • #23
        Originally posted by AJSB View Post

        I DON'T want just change resolution to something that the Monitor officially already supports, i want to CREATE a CUSTOM Resolution, for what you are saying, THAT will NOT do it.

        Ergo my previous comment about need to create a*.bin file (a customized forced EDID, actually, ) and edit a bunch of files ,etc. to make it work.

        In all these Years NO ONE (even Wayland devs that knowing the ins and outs of Wayland could have provided such a tool even if its not itself part of Wayland,) managed to make a program like XRANDR that would do this is in a easy like in Wayland no matter so many users need this...

        Anyway, AFAIK, as long as such thing doesn't exist, Wayland is not an option for me, EOD.


        Please see below:


        Pekka Paalanen 2018-03-29 09:56:40 UTC

        Hi,
        adding custom video modes is a feature of your particular Wayland display server. All configuration is up to each Wayland display server individually. They could agree on a mutual configuration standard, but that would be out of scope for Wayland as understood by the bugzilla product/component in this bug.
        Loading an EDID file through the kernel seems like a good solution to me, so it might be worth figuring out why it stopped working. If you want to make a configuration with your display server, please consult your specific display server documentation.
        FWIW, for years people have come up once in a while suggesting that Wayland should replicate X11 RandR, but it has never gained enough traction with the major desktop projects to become a serious proposal.
        Sorry. I think two major counter-arguments are: a) access control, we do not want arbitrary applications changing video modes at will, and b) once the Wayland display server accepts connections so that an app could program a video mode, the server has already initialized the display hardware so it's too late and will lead to glitchy user experience. Drafting such an interface would also be a considerable amount of work for a feature that most big desktop environments already implement by some other means.

        Comment


        • #24
          I'm not an expert in the wayland subject, so forgive me if I saying something wrong

          I think what could be a really improvement for wayland in genenal is if the main developers behind the project did a approach similar to what Khronos did with Vulkan, like keeping wayland as just a protocol (I personally don't think they're wrong with it), but also being responsible to create / manage some kind of "base compositor implementation" (DE agnostic if possible) and offering an option to track the different implementations of the existing compositors, so new developers could easily have a way to help.

          Would be a lot of work at the beginning, but in the future would help a lot to maintain and find better ways to solve the problems.

          Comment


          • #25
            Originally posted by Klassic Six View Post
            So no one else have any problem with current state of drag and drop on Wayland??
            I do! it mostly works fine but I can't DnD from Archive manager to extract some files!? what the hell is the deal there?

            Comment


            • #26
              First update in a year? By god it must be abandonware!!

              Comment


              • #27
                Originally posted by rastersoft View Post

                AFAIK, that isn't part of Wayland itself, because that is something that the applications doesn't need to understand. Each desktop has their own way.
                This is exactly what makes Wayland crippled beyond salvation at this point. There is no standard way for configuring anything -- hell, there might not even be any way for configuring things on a specific desktop environment. If we're lucky there's some command line interface akin to gsettings for configuring a couple of things while for others there are none.

                Mir is the only way to bring some sense to this mess, and all DEs should be ported to running on top of Mir -- ASAP!

                Comment


                • #28
                  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...

                  Comment


                  • #29
                    Originally posted by AnAccount View Post

                    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.
                    Not exactly whining...it was the comment about Wayland be "complete" that kinda triggered me...Yeah, i'm perfectly OK with X as is but there's always the possibility that my favourite Distro(s) sooner or later migrate to Wayland and then, i will have a problem if by then these issues are still not solved.

                    PS:
                    Not only Custom Resolutions but also Refresh Rates....many times we can OC, even in the supported Resolutions, the Refresh Rate.
                    Last edited by AJSB; 17 December 2020, 11:22 AM.

                    Comment


                    • #30
                      Originally posted by AJSB View Post

                      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):
                      Code:
                      *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.
                      Last edited by clouddrop; 17 December 2020, 12:07 PM.

                      Comment

                      Working...
                      X