5 ms·

Well, they've developed their EGLStream approach and that probably cost some resources on their end so the question is why they decided to go that way at all. I

Well, they've developed their EGLStream approach and that probably cost some resources on their end so the question is why they decided to go that way at all. It seems like a waste to me to develop something nobody is going to use and I don't see the business reason for this particular development.

thayne 7y ago
afaict the only people who really care about EGLStream are nvidia. And while GNOME and KDE might have the resources to support both API's (much as they don't want to), smaller projects like sway simply don't have the resources to worry about that. I think one of the biggest failings of wayland is that it requires so much duplication of effort between different compositors. Ideally, the compositor shouldn't have to care very much about which drivers the user is using for their graphics card.
- pzone 7y ago
  Even KDE was only able to gain support for EGLStreams after an NVidia developer Erik Kurzinger contributed the necessary changes to Kwin.
  - josefx 7y ago
    As far as I know that was mostly because they refused to even try and not because it was too hard or even complicated.
    - kelnos 7y ago
      If one of the kwin developers had nvidia hardware, likely they would have cared enough to try. And if they didn't, how would they test and maintain the nvidia-specific code? Adding an entirely new code path for rendering would be a large support and testing burden that they may not have had the resources to take on.
      - josefx 7y ago
        > If one of the kwin developers had nvidia hardware, So what your are saying is that NVIDIA could have just sent them a crate full of low end $50 dollar hardware and been done with it? I find that rather unlikely, or rather as an end user I prefer to think that there wouldn't be that much drama over what amounts to nothing.
        kelnos 7y ago
        Maybe? I don't know. But, either way, having two completely separate graphics code paths means a much larger maintenance burden than one. Even with hardware to test on, I'd consider it perfectly reasonable to decide to only support one, especially if the odd company out is one with a history of not playing ball with the community.
- imtringued 7y ago
  >Ideally, the compositor shouldn't have to care very much about which drivers the user is using for their graphics card. That would require a single standard for communication with GPUs and the problem is that Nvidia is refusing to implement that standard.
  - traverseda 7y ago
    Or some kind of abstraction layer.
  - arghwhat 7y ago
    All it requires is a single standard interface for managing buffers, which exists and is named GBM. Wayland doesn't care how you draw your buffers, and a custom EGL library as they already do, while gross as hell, is not at all a compatibility problem.
jcelerier 7y ago
EGLStreams is heavily used in industrial embedded, eg in nvidia's car platforms.
- arghwhat 7y ago
  You got that the wrong way around: Nvidia's platforms are a large part of industrial embedded, on which the users have no option but to use EGLStream.

thayne 7y ago

afaict the only people who really care about EGLStream are nvidia. And while GNOME and KDE might have the resources to support both API's (much as they don't want to), smaller projects like sway simply don't have the resources to worry about that. I think one of the biggest failings of wayland is that it requires so much duplication of effort between different compositors. Ideally, the compositor shouldn't have to care very much about which drivers the user is using for their graphics card.

pzone 7y ago
Even KDE was only able to gain support for EGLStreams after an NVidia developer Erik Kurzinger contributed the necessary changes to Kwin.
- josefx 7y ago
  As far as I know that was mostly because they refused to even try and not because it was too hard or even complicated.
  - kelnos 7y ago
    If one of the kwin developers had nvidia hardware, likely they would have cared enough to try. And if they didn't, how would they test and maintain the nvidia-specific code? Adding an entirely new code path for rendering would be a large support and testing burden that they may not have had the resources to take on.
    - josefx 7y ago
      > If one of the kwin developers had nvidia hardware, So what your are saying is that NVIDIA could have just sent them a crate full of low end $50 dollar hardware and been done with it? I find that rather unlikely, or rather as an end user I prefer to think that there wouldn't be that much drama over what amounts to nothing.
      - kelnos 7y ago
        Maybe? I don't know. But, either way, having two completely separate graphics code paths means a much larger maintenance burden than one. Even with hardware to test on, I'd consider it perfectly reasonable to decide to only support one, especially if the odd company out is one with a history of not playing ball with the community.
imtringued 7y ago
>Ideally, the compositor shouldn't have to care very much about which drivers the user is using for their graphics card. That would require a single standard for communication with GPUs and the problem is that Nvidia is refusing to implement that standard.
- traverseda 7y ago
  Or some kind of abstraction layer.
- arghwhat 7y ago
  All it requires is a single standard interface for managing buffers, which exists and is named GBM. Wayland doesn't care how you draw your buffers, and a custom EGL library as they already do, while gross as hell, is not at all a compatibility problem.

jcelerier 7y ago

EGLStreams is heavily used in industrial embedded, eg in nvidia's car platforms.

arghwhat 7y ago
You got that the wrong way around: Nvidia's platforms are a large part of industrial embedded, on which the users have no option but to use EGLStream.