Page 1 of 6 123 ... LastLast
Results 1 to 10 of 60

Thread: Two Features Wayland Will Have That X Doesn't

  1. #1
    Join Date
    Jan 2007
    Posts
    15,133

    Default Two Features Wayland Will Have That X Doesn't

    Phoronix: Two Features Wayland Will Have That X Doesn't

    While the discussion surrounding the Wayland Display Server and Canonical's plans to deploy Ubuntu atop Wayland continue to be ongoing within our forums (here, here, and here) and elsewhere, some new technical capabilities and plans for Wayland have been discussed. Here's two features that Wayland is set to have that is not currently supported by the X.Org Server...

    http://www.phoronix.com/vr.php?view=ODc3MA

  2. #2
    Join Date
    Mar 2009
    Posts
    86

    Default

    So let me get this straight: a toy display server has a half-baked plan for hypothetical support for three features (device switching, explicit full-screen mode, and relative mouse input) when one is already solved in X (XInput2), one is easily solvable (add a full-screen mode extension), and one would be equally hard to solve in either environment? This doesn't seem like news.

  3. #3
    Join Date
    Nov 2007
    Location
    Sweden
    Posts
    19

    Default

    Quote Originally Posted by md1032 View Post
    So let me get this straight: a toy display server has a half-baked plan for hypothetical support for three features (device switching, explicit full-screen mode, and relative mouse input) when one is already solved in X (XInput2), one is easily solvable (add a full-screen mode extension), and one would be equally hard to solve in either environment? This doesn't seem like news.
    There are two kinds of people in the world, pessimist's and optimist's

  4. #4
    Join Date
    Oct 2009
    Posts
    343

    Default

    i know the pain in the ass, cant play any penumbra, openarena etc.. mouse is crazy... sometimes clicking doesnt work good..

    fast implement the wayland!

  5. #5
    Join Date
    Jul 2009
    Posts
    416

    Default

    I don't know what it's called, but the second feature sounds really cool. I hate launching games in Linux and then they default to Fullscreen and mess up the resolution when I exit back to X.org. But after the first run I usually get it set to run in a window, but for some games I'd like to do full screen but I can't.

    I've also had problems with the fact that I use two screens, and sometimes games try to span both screens. I think I solved that with some xorg.conf magic though.

  6. #6
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,052

    Default

    Quote Originally Posted by pvtcupcakes View Post
    I hate launching games in Linux and then they default to Fullscreen and mess up the resolution when I exit back to X.org. But after the first run I usually get it set to run in a window, but for some games I'd like to do full screen but I can't.
    I don't get why one needs to run a game "full screen". Just draw a window with the size of the desktop and use the fullscreen function of your windowmanager.
    No need for implementing fullscreen-window-managing-functions into the application.

  7. #7
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,187

    Default

    Finally a tangible set of features. It's what Wayland has been lacking so far, good marketing.

  8. #8
    Join Date
    Oct 2010
    Posts
    461

    Default

    Even worse is when an application requests full-screen in a resolution that your monitor doesn't support, and doesn't offer an easy way to select another resolution. Then you're stuck in the full-screen app (sometimes with no easy way to exit the app without getting the X server stuck in an unsupported resolution), possibly with other things open that you don't want to lose.

    I know, it's a configuration problem with Xorg. But it's a problem I had often with the nv driver (even/especially when auto-configured), and one that I still sometimes have with nouveau. Wayland could provide a good solution.

    If any of this could be done with Xorg, why hasn't it (a serious question)? Why did they go with quick hacks, or no solution at all? (the answer to that question, at least with regards to the full-screen app problem, would probably be that it's because Xorg isn't a compositor; it's a display server/api)

  9. #9
    Join Date
    Jul 2008
    Posts
    69

    Default

    Quote Originally Posted by ChrisXY View Post
    I don't get why one needs to run a game "full screen". Just draw a window with the size of the desktop and use the fullscreen function of your windowmanager.
    No need for implementing fullscreen-window-managing-functions into the application.
    This seems like the simple and correct method to support this. In KDE, setting these rules is exceptionally easy.

  10. #10
    Join Date
    Oct 2009
    Posts
    2,122

    Default

    ...just enough that they know the screen sizes and layout. Either the compositor can run a special client with access to the modesetting interface or changing the resolution and/or screen layout could just be part of the compositor.
    I don't like the idea of any application controlling the screen resolution at all under any circumstances. If the dumb game wants a different resolution, it should either be scaled or bordered. NEVER let a dumb game change the resolution.

    Note: hack to prevent dumb game from changing the resolution: xrandr to delete all non-native modes.

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
  •