Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 60

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

  1. #31
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    460

    Default

    Quote Originally Posted by V!NCENT View Post
    X.org is only still useful for the internet. An AMD 6800 has a 1GB framebuffer, for which you won't use all of it (not even 1/30) and with a GB LAN port and cables, this is totally neglect-able. You can simply transfer the raw framebuffer image over a gigabyte ethernet cable.
    You do realise that:

    a) not everyone has gigabit Ethernet?
    b) people routinely want to forward GUI apps over broadband which isn't even as fast as 10MB Ethernet?

    I was trying xpra last night, which does per-window X-forwarding by running its own X-server on the remote host sending bitmaps over the network, and the difference in latency between that and direct X-forwarding via SSH was very noticeable. Sending big bitmaps around networks is just crazy.

    In addition, this all assumes that the server you're running a GUI app from has a video card which can do the rendering; I've been working on a server which only supports the VESA driver and X-forwarding to a workstation which has a decent GPU and a decent driver. It would be even worse if it was a virtualised server with no GPU at all.

    Basing your display system on having local rendering hardware to render bitmaps that you'll then send around the network is just crazy.

  2. #32
    Join Date
    Sep 2010
    Posts
    146

    Default The Nvidia employee's comment is misleading

    Quote Originally Posted by 89c51 View Post
    this

    anybody know what the Nvidia guy means???
    By looking at the contents of that document, he means that window managers shouldn't be forced to use OpenGL for compositing. He seems to be criticizing the design of the Wayland reference implementation (which uses KMS/DRM/EGL/OpenGL).

    What he doesn't seem to acknowledge is that Wayland is actually a protocol for display servers to communicate with their clients, and is independent of any specific implementation. In other words, Nvidia wouldn't have to use the Wayland reference implementation - the entire point of defining a formal protocol is to allow others to create compliant implementations that fit their own needs. This means Nvidia could create their own Wayland implementation and composite windows however they want, with or without OpenGL. In fact, the Wayland protocol, by the very nature of a protocol, imposes no restrictions at all on how software implementing it should be designed.

  3. #33
    Join Date
    Oct 2010
    Posts
    417

    Default

    Isn't it Gb anyway, not GB? I have a hard time imagining whole GB's of information traveling through an Ethernet cable in a second or less. Then again, I haven't sent information through an Ethernet cable that wasn't coming from and/or going to a hard drive, so I may be biased.

  4. #34
    Join Date
    Jan 2010
    Posts
    159

    Default

    Quote Originally Posted by droidhacker View Post
    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.
    The application wouldn't change resolution. It would request the windowmanager to change resolution.

  5. #35
    Join Date
    Jan 2010
    Posts
    159

    Default

    Quote Originally Posted by Kazade View Post
    It's early days. If it looks like there is going to be a massive shift from X to Wayland across Linux distros then Nvidia will develop drivers for it.
    No they won't because it basically means open sourcing their drivers. KMS is a part of the Kernel and to have a KMS driver go into the Kernel you need to opensource it kernel developers wont allow an open KMS driver which only works for a closed driver (as with those infamous Intel cards) so nvidia is either stuck with X, opens their driver (which they won't do) or the nice Kernel Programmers make a third special way for the blobs.

  6. #36
    Join Date
    Sep 2010
    Posts
    146

    Default

    Quote Originally Posted by movieman View Post
    You do realise that:

    a) not everyone has gigabit Ethernet?
    b) people routinely want to forward GUI apps over broadband which isn't even as fast as 10MB Ethernet?

    I was trying xpra last night, which does per-window X-forwarding by running its own X-server on the remote host sending bitmaps over the network, and the difference in latency between that and direct X-forwarding via SSH was very noticeable. Sending big bitmaps around networks is just crazy.

    In addition, this all assumes that the server you're running a GUI app from has a video card which can do the rendering; I've been working on a server which only supports the VESA driver and X-forwarding to a workstation which has a decent GPU and a decent driver. It would be even worse if it was a virtualised server with no GPU at all.

    Basing your display system on having local rendering hardware to render bitmaps that you'll then send around the network is just crazy.
    Contrary to what you seem to think, Wayland is not based on sending bitmaps over a network. It's not a network-based protocol. The Wayland developers have stated their opinion that networking functionality belongs in toolkits, not in the display server. They have a point, too, because toolkits know a lot more about what they're trying to do - and can thus more efficiently store the information whatever information the client needs in order to render - than any display server ever can.

  7. #37
    Join Date
    Oct 2008
    Posts
    3,038

    Default

    Quote Originally Posted by Ragas View Post
    No they won't because it basically means open sourcing their drivers. KMS is a part of the Kernel and to have a KMS driver go into the Kernel you need to opensource it kernel developers wont allow an open KMS driver which only works for a closed driver (as with those infamous Intel cards) so nvidia is either stuck with X, opens their driver (which they won't do) or the nice Kernel Programmers make a third special way for the blobs.
    As has been mentioned several times now, Wayland only needs very minor modifications to use modesetting through the kernel blobs. It's really very similar to the KMS API that the OSS drivers use. The Wayland devs are not opposed to doing this, and Nvidia could do it quite easily. So there is no problem.

  8. #38
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Let me put it this way; 8mp jpeg is 2.5MB...

  9. #39
    Join Date
    Aug 2008
    Posts
    84

    Default

    Quote Originally Posted by glisse View Post
    There is a misunderstanding here, wayland doesn't strictly need KMS/GEM. Wayland can easily use some others interface to setup video mode and to share buffer. What wayland needs is an EGL driver and modesetting capabilities without X, then if the EGL implementation has the EGL image extension it all should work properly ie all you need is to change bit of wayland that is not exposed to its client to work on somethings else than KMS.
    It might get modified to allow this at some point, but currently Wayland is hard-coded to use KMS and DRI2 directly. Since the developers seem to prioritize code size and simplicity, I'm not sure this is ever likely to change.

    Quote Originally Posted by Plombo View Post
    What he doesn't seem to acknowledge is that Wayland is actually a protocol for display servers to communicate with their clients, and is independent of any specific implementation. In other words, Nvidia wouldn't have to use the Wayland reference implementation - the entire point of defining a formal protocol is to allow others to create compliant implementations that fit their own needs.
    So we can go back to the good old days of multiple competing display server implementations, each with their own bugs and quirks that had to be worked around? Yay.

  10. #40
    Join Date
    May 2007
    Posts
    231

    Default

    Quote Originally Posted by makomk View Post
    It might get modified to allow this at some point, but currently Wayland is hard-coded to use KMS and DRI2 directly. Since the developers seem to prioritize code size and simplicity, I'm not sure this is ever likely to change.
    This can be changed more easily than you think.


    Quote Originally Posted by makomk View Post
    So we can go back to the good old days of multiple competing display server implementations, each with their own bugs and quirks that had to be worked around? Yay.
    wayland protocol is small there isn't thousands of combination, it's really all boils down to: "hello here is a buffer please show it and send me input"

    No a monster protocol like X with several extensions and several weird behavior.

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
  •