Page 8 of 9 FirstFirst ... 6789 LastLast
Results 71 to 80 of 90

Thread: KWin On Mir: A Solution To Non-Existent Problem

  1. #71
    Join Date
    Jan 2013
    Posts
    525

    Default

    Quote Originally Posted by TheBlackCat View Post
    Yes, I am sure the maintainer of open-source software's most sophisticated window manager has no clue at all about free software.

    Let me guess, you think free software means no one is allowed to criticize anyone else.
    I would think it as offering more choice for the user, not limiting it as the rejection of upstream Mir specific patches does.
    Unless the code introduces bugs or speed regressions, there really should be no reason to reject those patches unless you were deliberately trying to politicise software, which just leads to tedious and inane arguments that benefit no one at all.

  2. #72
    Join Date
    Nov 2012
    Posts
    49

    Default

    Quote Originally Posted by intellivision View Post
    KDE should accept and maintain Ubuntu code and have an entry in their bug tracker just for Ubuntu
    such a good idea

  3. #73
    Join Date
    Jan 2013
    Posts
    525

    Default

    Quote Originally Posted by cardboard View Post
    Yes, they should, just like they maintain Xorg code
    Couldn't have said it better myself.

  4. #74
    Join Date
    Nov 2012
    Posts
    49

    Default

    Quote Originally Posted by intellivision View Post
    Couldn't have said it better myself.
    All distros use Xorg, while Mir is Ubuntu-only. Ubuntu developers should maintain a KWin branch with Mir patches if they want to support it.

    Upstream is the wrong place for distro-specific hacks. This is not a new concept, and has nothing to do with Canonical or Shitterworth or Ubuntu haters or politics or whatever the heck else you think it does.

  5. #75
    Join Date
    Jan 2013
    Posts
    525

    Default

    Quote Originally Posted by cardboard View Post
    All distros use Xorg, while Mir is Ubuntu-only. Ubuntu developers should maintain a KWin branch with Mir patches if they want to support it.
    Well, for now, but I can see other distro's adopting or offering Mir as an option in the future. In fact, there is already an AUR port of Mir here:
    https://aur.archlinux.org/packages/mir-bzr/

    It seems that the KWin team's only goal was politicising and exacerbating a pointless debate of Wayland vs Mir which only drives to more fragmentation between Upstream KWin and 'Ubuntu' KWin.

  6. #76
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,508

    Default

    Quote Originally Posted by Togga View Post
    That could mean that the former Nokia strategy (before WP luncay) and hard work could bear fruit and be beneficial to all of us.
    It certainly will. It's called Sailfish.

    Quote Originally Posted by cardboard View Post
    All distros use Xorg, while Mir is Ubuntu-only. Ubuntu developers should maintain a KWin branch with Mir patches if they want to support it.

    Upstream is the wrong place for distro-specific hacks. This is not a new concept, and has nothing to do with Canonical or Shitterworth or Ubuntu haters or politics or whatever the heck else you think it does.
    Well, I don't really see much bad in accepting a patch for Mir, as long as those who wrote it can maintain it in the future. Have a section for Ubuntu support in the bug tracker, it shouldn't harm anyone as long as Martin is not the one to deal with those bugs. But I suppose it also depends on how invasive the changes would be.

    EDIT: Oh, and this thread is back on topic? What sorcery is this?! :O

  7. #77
    Join Date
    Feb 2011
    Posts
    1,058

    Default

    Quote Originally Posted by intellivision View Post
    I would think it as offering more choice for the user, not limiting it as the rejection of upstream Mir specific patches does.
    No, it doesn't imply that at all. It implies that people are free to look at your source code and do what they want with it. It does not mean that anyone else can force you to do what they want with your code, it doesn't mean you can't have policies about what is and is not allowed in your code, and it doesn't mean you can't have opinions about other peoples' code.

    Quote Originally Posted by intellivision View Post
    Well, for now, but I can see other distro's adopting or offering Mir as an option in the future.
    It would be nice if you actually read the original blog post before criticizing it. He flat-out said that if it became something commonly used amongst distros he would be happy to support it. But just peoples' opinions that it might be in the future is not enough, it actually has to happen in the real world.

    Quote Originally Posted by intellivision View Post
    It seems that the KWin team's only goal was politicising and exacerbating a pointless debate of Wayland vs Mir which only drives to more fragmentation between Upstream KWin and 'Ubuntu' KWin.
    First, this has nothing to do with the Kwin team, this is the comments of the Kwin maintainer. Again, it would be nice if you knew what we are actually discussing before you criticize it.

    Second, this is not some new policy invented specifically as an attack on Mir, this has been the policy for a long time now. Politicizing would be to ignore his own rules for the sake of one particular distribution.

    Quote Originally Posted by GreatEmerald View Post
    Well, I don't really see much bad in accepting a patch for Mir, as long as those who wrote it can maintain it in the future. Have a section for Ubuntu support in the bug tracker, it shouldn't harm anyone as long as Martin is not the one to deal with those bugs. But I suppose it also depends on how invasive the changes would be.
    Martin is never, ever going to do that. He has been burned far too many times by people promising to maintain the code they contribute to Kwin and then disappearing, leaving him to maintain and then eventually strip out the code he was never supposed to have to deal with. Because of this, he again has a strict policy of not accepting any code he is not prepared to maintain himself. He simply doesn't trust such promises anymore, with good reason.
    Last edited by TheBlackCat; 03-11-2013 at 03:16 AM.

  8. #78
    Join Date
    Mar 2013
    Posts
    17

    Default

    Apparently Canonical have never contributed anything in kwin.


  9. #79
    Join Date
    Jan 2013
    Posts
    1,435

    Default

    Quote Originally Posted by TestingTe View Post
    "What is Free Software?

    “Free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech”, not as in “free beer”.

    Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:

    The freedom to run the program, for any purpose (freedom 0).
    The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
    The freedom to redistribute copies so you can help your neighbor (freedom 2).
    The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this."

    --GNU.org
    So, where in this does it say that KWin maintainer (or any maintainer) has to accept whatever patches someone else wants, or has to implement support for someone else's pet project?

    If Canonical wants Kwin to support Mir, they're free to fork it and implement it themselves, as it's free software. But they don't have any right to make demands to the Kwin mainline.

  10. #80
    Join Date
    Jun 2009
    Posts
    1,081

    Default

    i want to clarify some points that everyone keep getting wrong again and again:
    1.) wayland is a library with a protocol is not a server(like libtcp not like X11 or mysql)
    2.) wayland as a protocol definition don't have to support any complex render operation like minimize, that is a client side problem
    3.) wayland PROTOCOL is only an intermediary to talk directly to the GPU using a common standard with a set of GPU Efficient Languages like GL ES, EGL, OpenGL, OpenVG, TGSI, G/ASM, etc.
    4.) weston is an entirely separated project aka IS NOT WAYLAND OR A PART OF WAYLAND, it means Weston is a client side compositor for reference[as Kwin is an X11 compositor not X11 itself]
    5.) wayland as protocol do support Minimize

    Proper explanation of 5:
    a.) is not a problem of support, remember wayland only work at surface/input side AKA is very very low level and in this level the problem of minimize is trivial
    b.) why weston don't support it, then? because there are many ways to solve the issues and most likely they are thinking to death which one is the more efficient[remember all GPU don't work the same]
    b1.) how many ways you can have to minimize LOL? <--- just from the top of my head the easy ones
    1.) treat every surface[aka processed texture in GPU framebuffer] as an FBO/PBO and once the set surface is set as minimized it should just be marked as not renderable, so the next refresh cycle the GPU don't process that specific surface but you keep the RAM used[fine for normal desktop bad for gaming]
    2.) once the surface received the minimize command the surface/s are destroyed entirely and flushed in the next refresh cycle and once the surface is marked as not minimized wayland inform the client to render the entire surface again so the surface it shown the next refresh cycle[awesome for gaming bad for responsiveness]
    3.) once the surface is marked as minimized the surface if hot copied to an alternate SHM/KMS in RAM[as CPU RAM] buffer and flushed from the GPU framebuffer in the next refresh cycle and once the surface is marked as not minimized the SHM/KMS RAM buffer will be hot copied back to the GPU framebuffer and rendered in the next refresh cycle[prolly 50/50 but can punish you I/O--RAM subsystem if you have too many surfaces and prolly would need some smart in memory constrained systems]
    4.) smarter solutions like allocating algorithm, surface compression, surface decompose, etc
    5.) this can be improved at Toolkit[aka client level] too using client side surface clone compositing techniques, for example every widget in qt[combobox buttons glyphetc] can be an unique surface and you can actually compose with this pieces the app final visual of the surface in a blank surface that references at X,Y(s) the needed memory position for rendering[aka ultra low GPU memory usage and uber fast rendering]

    so the actual problem is about choose the better method/s[can be a combination of many] to find the best solution not a wayland deficiency or lack of vision or protocol BooBoo[is possible though to standarize it at protocol level with an extension if the compositor dont wanna do it directly]

    as always if i miss a point or i wrongly understood a wayland capability you can correct me

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •