Announcement

Collapse
No announcement yet.

NVIDIA 555.42.02 Linux Beta Brings Wayland Explicit Sync, GSP Firmware Used By Default

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

  • Wayland has wl_output as part of the core protocol that provides info on all outputs and their geometries and transforms:

    Code:
    > wayland-info -i wl_output
    interface: 'wl_output',                                  version:  4, name:  6
        name: eDP-1
        x: 0, y: 626, scale: 1,
        physical_width: 300 mm, physical_height: 190 mm,
        make: 'SDC', model: '04152',
        subpixel_orientation: unknown, output_transform: normal,
        mode:
            width: 2880 px, height: 1800 px, refresh: 90.001 Hz,
            flags: current preferred
    interface: 'wl_output',                                  version:  4, name: 35
        name: DP-3
        x: 2880, y: 0, scale: 1,
        physical_width: 700 mm, physical_height: 400 mm,
        make: 'GSM', model: 'LG HDR 4K',
        subpixel_orientation: unknown, output_transform: normal,
        mode:
            width: 3840 px, height: 2160 px, refresh: 59.996 Hz,
            flags: current preferred
    interface: 'wl_output',                                  version:  4, name: 36
        name: DP-1
        x: 6720, y: 0, scale: 1,
        physical_width: 700 mm, physical_height: 400 mm,
        make: 'GSM', model: 'LG HDR 4K',
        subpixel_orientation: unknown, output_transform: normal,
        mode:
            width: 3840 px, height: 2160 px, refresh: 59.996 Hz,
            flags: current preferred

    Comment


    • Originally posted by oiaohm View Post
      ​No read my post again. Application popup window. You did not choose to place the window where it end up. It could be an application bug doing this.

      Read the post again. What the point of doing this if it popup window does not have move support. So yes under X11/Windows you can find the window then not be able to-do anything straight way to fix the problem.
      I don't know what world you live in, but you can position popups on Windows and X11.

      Originally posted by oiaohm View Post
      ​The words here are wrong. Wayland protocol itself the core does not forbid the information you have describe being provided. Wayland protocol does not have an extension to provide that information. All wayland extensions have to be designed without detectable design defects to get merged(this is the problem).

      Also you make a mistake "don't even know the monitors" this is not a mistake but a requirement to prevent particular design defect. If an application knows the monitors an application can refuse to run on user because they currently have a monitor unplugged this is a design defect of allowing applications to know what monitors exist in raw form.
      Dude, if the application refuses to run without your monitors, then leave it be. It's the app's choice.

      You do not know better than what the app needs. This choice is up to the app, and if you don't likeit, submit a bug report on the app. Wayland or the compositor has no business to tell the app how it should work.

      Holy shit. I'm tired of this hand-holding approach from Wayland who think they know what's best for other devs.

      Comment


      • Originally posted by Weasel View Post
        I don't know what world you live in, but you can position popups on Windows and X11.
        I believe they're referring to how things like menus and tooltips on X11 are built using "unmanaged" windows where, if the application queried the desktop rectangle once on startup and then you pull the external monitor from your laptop, there's nothing you can do about the popup appearing outside the visible rectangle because the window is unmanaged.

        More specifically, I believe they're saying that you can't "position" unmanaged windows using Alt+Drag if the application puts them in the wrong place and the WM does nothing about it because they're unmanaged. I built some PyGTK applications using them back around the tail end of the GTK+ 2.x era so I'm quite familiar with what that means.


        Originally posted by Weasel View Post
        I don't know what world you live in, but you can position popups on Windows and X11.
        Dude, if the application refuses to run without your monitors, then leave it be. It's the app's choice.

        You do not know better than what the app needs. This choice is up to the app, and if you don't likeit, submit a bug report on the app. Wayland or the compositor has no business to tell the app how it should work.

        Holy shit. I'm tired of this hand-holding approach from Wayland who think they know what's best for other devs.
        [raises gun] Get your stinkin' gubmint hands offa mah KWin Window Rules.

        (Translation: No, it's the user's choice, because it's the user's machine, and the point of designing Wayland that way is so that things like KWin Window Rules and Focus-Stealing Prevention and such don't unavoidably have to be a pile of buggy hacks as the WM tries to second-guess when to allow the application what it wants and when to ignore its requests. For example, I have applications where I just have to "Force" the geometry (i.e. even I can't move it without editing the window rule) because "Set Initial" doesn't work because the application shows the window and then positions it instead of setting the desired geometry before showing it.)

        It's similar to how Wayland's standard/unprivileged APIs don't allow applications to request resolution changes that persist beyond the application's death because that's a sure-fire way for game crashes to leave you at 640x480 and, if you're on 9x-series Windows before it became part of the OS-managed Compatiblity tab, 256 colors.
        Last edited by ssokolow; 27 May 2024, 03:49 PM.

        Comment


        • Originally posted by Weasel View Post
          I don't know what world you live in, but you can position popups on Windows and X11.

          Dude, if the application refuses to run without your monitors, then leave it be. It's the app's choice.

          You do not know better than what the app needs. This choice is up to the app, and if you don't likeit, submit a bug report on the app. Wayland or the compositor has no business to tell the app how it should work.

          Holy shit. I'm tired of this hand-holding approach from Wayland who think they know what's best for other devs.
          dude you sound like a clown wayland tries to be everyone's nanny telling apps what to do seriously think apps don't know where to put their windows it's hilarious you complain about monitor setups but won't even recognize the simple fact x11/windows let apps do their thing popping up wherever they damn please wayland's the one screwing it up thinking it's got the right to boss apps around wayland fanboys need reality check complaining won't fix anything wayland's handholding is suffocating give apps freedom they know better without wayland's crappy interference

          Comment


          • Originally posted by Weasel View Post
            I don't know what world you live in, but you can position popups on Windows and X11.
            No you need to live in the real world. As ssokolow​ points out there are Windows you cannot reposition under Windows and X11. Yes the unmanaged class of Windows.

            Originally posted by Weasel View Post
            Dude, if the application refuses to run without your monitors, then leave it be. It's the app's choice.
            Normally it an application bug. Where the application recorded it prior window positions. Yes this creates cases where application worked fine on the setup it is now but after you have had a extra monitor plugged for a while it does not work again. This is a common problem with people doing presentations.

            Originally posted by Weasel View Post
            You do not know better than what the app needs. This choice is up to the app, and if you don't likeit, submit a bug report on the app. Wayland or the compositor has no business to tell the app how it should work.
            Weasel you need to take back this line straight way. Because if the Wayland protocol or Wayland compositor has no right to tell applications how to work you have no right to write macros to tell applications how they should work. KDE window rules are a form of Macros Weasel.

            Originally posted by bhptitotoss View Post
            dude you sound like a clown wayland tries to be everyone's nanny telling apps what to do seriously think apps don't know where to put their windows it's hilarious you complain about monitor setups but won't even recognize the simple fact x11/windows let apps do their thing popping up wherever they damn please wayland's the one screwing it up thinking it's got the right to boss apps around wayland fanboys need reality check complaining won't fix anything wayland's handholding is suffocating give apps freedom they know better without wayland's crappy interference
            Something to remember 90%+ of applications do not have a issue with Wayland restrictions. Yes wine project has found this as well with windows applications.

            Yes current wayland protocol has taken away too much freedom. Item like 264 merge request is to give back enough freedom for applications to work without giving back enough freedom for application to jam up on user.

            Restricting window placement does prevent a set of application bugs from being code-able. You can think of this like compilers adding buffer overflow detection and other things to prevent application code from containing common defects. Yes just like the early generations of this detection stuff in compilers for buffer overflows was heavy handed the Wayland restricted window placement is too heavy handed at the moment.

            Hello everyone! This is a new attempt to resolve the issues clients designed for stacking window managers are facing when they want to set their own...

            Yes something like 264 merges application developers get more freedom but the application developers don't get enough freedom to screw end user over.

            The reality is that you need to be truthful with the existing design defects. X11 and MS Windows systems are not perfect.

            Comment


            • Originally posted by ssokolow View Post
              [raises gun] Get your stinkin' gubmint hands offa mah KWin Window Rules.
              And off mah KWin scripts.

              Seriously, I wonder if some people are simply using incomplete or insufficient means to achieve their window management needs.

              Comment


              • Originally posted by ssokolow View Post
                I believe they're referring to how things like menus and tooltips on X11 are built using "unmanaged" windows where, if the application queried the desktop rectangle once on startup and then you pull the external monitor from your laptop, there's nothing you can do about the popup appearing outside the visible rectangle because the window is unmanaged.

                More specifically, I believe they're saying that you can't "position" unmanaged windows using Alt+Drag if the application puts them in the wrong place and the WM does nothing about it because they're unmanaged. I built some PyGTK applications using them back around the tail end of the GTK+ 2.x era so I'm quite familiar with what that means.
                You can use managed popups with no decorations, just give the appropriate hints?

                (and "functions", which is like drag, move, resize, blabla, are different from "decorations" and separate when supplying it the hints)

                Originally posted by ssokolow View Post
                ​[raises gun] Get your stinkin' gubmint hands offa mah KWin Window Rules.

                (Translation: No, it's the user's choice, because it's the user's machine, and the point of designing Wayland that way is so that things like KWin Window Rules and Focus-Stealing Prevention and such don't unavoidably have to be a pile of buggy hacks as the WM tries to second-guess when to allow the application what it wants and when to ignore its requests. For example, I have applications where I just have to "Force" the geometry (i.e. even I can't move it without editing the window rule) because "Set Initial" doesn't work because the application shows the window and then positions it instead of setting the desired geometry before showing it.)

                It's similar to how Wayland's standard/unprivileged APIs don't allow applications to request resolution changes that persist beyond the application's death because that's a sure-fire way for game crashes to leave you at 640x480 and, if you're on 9x-series Windows before it became part of the OS-managed Compatiblity tab, 256 colors.
                It's the user's choice to use the app or not. If you don't like the app, then don't use it.

                So yes, you have a choice, but not to override app's behavior behind its back. That's just dumb.

                Comment


                • Originally posted by oiaohm View Post
                  No you need to live in the real world. As ssokolow​ points out there are Windows you cannot reposition under Windows and X11. Yes the unmanaged class of Windows.
                  If you can't reposition the window, then the app did that on purpose. It's the app's choice.

                  If you don't like it then don't use the app. It's not rocket science.

                  Originally posted by oiaohm View Post
                  Normally it an application bug. Where the application recorded it prior window positions. Yes this creates cases where application worked fine on the setup it is now but after you have had a extra monitor plugged for a while it does not work again. This is a common problem with people doing presentations.
                  Cool, so report it and have it fixed on the app. It's not the compositor's job to workaround app bugs.

                  Originally posted by oiaohm View Post
                  Weasel you need to take back this line straight way. Because if the Wayland protocol or Wayland compositor has no right to tell applications how to work you have no right to write macros to tell applications how they should work. KDE window rules are a form of Macros Weasel.
                  I have the right because it's my computer and I could do it manually?

                  If I couldn't do it manually, you'd have point. In that case yeah, the app definitely doesn't want its stuff tampered with.

                  Originally posted by oiaohm View Post
                  Something to remember 90%+ of applications do not have a issue with Wayland restrictions.
                  Ok but who asked?

                  98.1964% of statistics are made up on the spot btw.

                  Originally posted by oiaohm View Post
                  Restricting window placement does prevent a set of application bugs from being code-able. You can think of this like compilers adding buffer overflow detection and other things to prevent application code from containing common defects. Yes just like the early generations of this detection stuff in compilers for buffer overflows was heavy handed the Wayland restricted window placement is too heavy handed at the moment.

                  Hello everyone! This is a new attempt to resolve the issues clients designed for stacking window managers are facing when they want to set their own...

                  Yes something like 264 merges application developers get more freedom but the application developers don't get enough freedom to screw end user over.

                  The reality is that you need to be truthful with the existing design defects. X11 and MS Windows systems are not perfect.​
                  They're not perfect, but they're functional. Like I said it's not the job of the compositor or display server to workaround or prevent app design bugs.

                  Wayland devs need to understand that they are not other programmers' or apps' nannies.

                  Comment


                  • Originally posted by Weasel View Post

                    They're not perfect, but they're functional. Like I said it's not the job of the compositor or display server to workaround or prevent app design bugs.

                    Wayland devs need to understand that they are not other programmers' or apps' nannies.
                    Even if we ignore the debate about whether Wayland should provide absolute window positioning as-is like other existing platforms, the proposal 264 is about to introduce a "zone"-local window layer system. A software program will be able to provide always-on-tops or pop-ups that are local to that software program, without stealing focus or stepping into others' foot with other software program.

                    You may still find it too restrictive for some fringe cases, but we are not going to get anything less for those idealists to accept...

                    Comment


                    • Originally posted by Weasel View Post
                      If you can't reposition the window, then the app did that on purpose. It's the app's choice.

                      If you don't like it then don't use the app. It's not rocket science.
                      So you just told a person to loss there job. People don't always have software choice.

                      Originally posted by Weasel View Post
                      I have the right because it's my computer and I could do it manually?
                      This does not hold.

                      Originally posted by Weasel View Post
                      If I couldn't do it manually, you'd have point. In that case yeah, the app definitely doesn't want its stuff tampered with.
                      So wayland compositors not allowing you to move applications is correct and valid by your arguement that applications are allowed to stomp over users.

                      Weasel you current argument kills all your arguments you have against Wayland If app is king remember Wayland compositor is an APP and you have said that allowed to have unlimited power to restrict user actions. Weasel so you current argument you have no right to be asking for macro support thank you for being an idiot.



                      Comment

                      Working...
                      X