Originally posted by GizmoChicken
View Post
Announcement
Collapse
No announcement yet.
X.Org Server 1.20 RC4 Released, EGLStreams For XWayland Might Still Land
Collapse
X
-
Originally posted by kaprikawn View Post
I'm not saying we should only have one format. I'm saying it should not be incumbent on everyone else to support Nvidia's bs.
But in any case, even in you are not opposed to EGLStreams, I find it nearly as troubling that you wish to prohibit Adam Jackson from working on the project of his choice.
- Likes 2
Comment
-
Originally posted by You- View PostI would suspect that the vast majority of desktop machines do not have nVidia - just intel with integrated graphics.
Comment
-
Originally posted by dkasak View PostWhere is the motivation for nVidia to follow through on their promises if this is merged? As for lack of accelerated nVidia support hurting Wayland adoption ... ha ... not likely. Wayland adoption will pick up when all the major *functionality* falls into place ... which will be pretty soon, hence distros planning to flip to Wayland by default. nVidia users will either have to deal with software rendering, or switch back to X by default. So a handful of Linux users with nVidia GPUs will not be using Wayland, sure. That's really not the end of the world, and in no way stops the majority of Linux users from moving on.
Comment
-
Originally posted by indepe View PostPerhaps Khronos should define a standard for "device memory allocation" and make it part of OpenGL 4.7 and Vulkan 1.2.
Comment
-
Originally posted by RomuloP View PostAnd this is my point, why don't it support protocols in terms of modules or any encapsulation that
The trick is that the API/ABI used for drivers is subject to change (and usually does change) between releases, out-of-tree modules will have to be adjusted to these changes to keep working, thus requiring some kind of constant maintenance. While the in-tree drivers will be migrated to the new API/ABI by whoever does the change in the kernel (i.e. with no burden on the driver developer).
But this isn't terribly hard to do, for most things.
avoid this excuse of "it is not sane to accept those kind of patches because it is not free/need to be maintained/etc". I really don't get people that are pro "don't accept".
I don't see how this is difficult to understand, or bad.
- Likes 1
Comment
-
Originally posted by Britoid View PostIsn't GBM part of Mesa? Which makes it somewhat a vendor implementation, so what means its automatically better than nVidia's EGLStreams?
Mesa is used by all opensource 3D drivers. Intel, AMD, Freedreno, VC4 (raspberry pi), Etnaviv, and whatever.
Comment
-
Here's what I don't get:
Nvidia is already working on a unified device memory allocation API which replaces both GBM and EGLStreams (to my knowledge). Why would we want to merge EGLStreams now if its replacement is already being worked on? The amount of maintenance overhead this will introduce for the limited amount of time it'll be useful just doesn't seem worth it.
Comment
-
Originally posted by Veerappan View PostHere's what I don't get:
Nvidia is already working on a unified device memory allocation API which replaces both GBM and EGLStreams (to my knowledge). Why would we want to merge EGLStreams now if its replacement is already being worked on? The amount of maintenance overhead this will introduce for the limited amount of time it'll be useful just doesn't seem worth it.
Comment
-
Originally posted by starshipeleven View PostYou're probably underestimating the timescale of the development of this new API. I'm not holding my breath for it to appear soon.
Every day I bang my head on my desk when I go through debugging/troubleshooting of code that was written 15 years ago (and wasn't always well-written to begin with), and it's this long-term maintenance burden that I'd be worried about here.
Comment
Comment