NVIDIA 495 Linux Beta Driver Released With GBM Support

[birdie]

Nobody's "peddling Wayland". You started yet another argument about this shit and we're correcting you. A while back I argued with a bunch (about 10) conspiracy theorists who were flat earthers, gravity deniers, moonlandering deniers, etc. for about three weeks. Every time I corrected them about something, explained something to them, broke something down for them, or provided a links and videos that disproved what they were saying, they would deny that I ever provided any information to begin with and/or start acting like I'm in on the conspiracy and I'm peddling the "ball-earth theory" to people. You give me sooooo much of that energy.

I provided you with some articles and directory of found X11 vulnerabilities and you sadi I haven't provided you with anything. Now you're claiming I'm peddling Wayland to you when you entered the conversation on your own free will because bitching about things that you don't know about makes you hard.

Theoretical X11 vulnerabilities, OK? You're a flat earther yourself, pal, if you're saying something is "broken" when nothing has been shown to ever exploit it. You are a believer in X11 shortcomings.

Let's check your directory:

1. https://medium.com/geekculture/explo...s-cc0e2184cece - everything under it seemingly requires local access at which point you're f-ed regardless. Secondly, the TCP feature of X.org has never been enabled by default. IOW, this wonderful article affects those who already got owned. What a vulnerability. Oh, in the end it's talking about modifying the lightdm.conf file which is only possible for the root user. Are you trying to imply X.org is insecure because the root user can set it up insecurely? Woooooooooooooooow. A ton of Linux daemons and application servers can be misconfigured to allow to hack into the system effortlessly.

2. https://www.rapid7.com/db/modules/ex...keyboard_exec/ - Absolutely no info given about it aside from "This module exploits open X11 servers by connecting and registering a virtual keyboard" - so, again the X11 server needs to be manually misconfigured, right?

3. https://www.rapid7.com/db/modules/ex...rg_x11_server/ - "A permission check flaw exists for -modulepath and -logfile options when starting Xorg. This allows unprivileged users that can start the server the ability to elevate privileges and run arbitrary code under root privileges" - has nothing to do with the X11 protocol or inherent Xorg insecurity, and it only affected OpenBSD, AIX 7.1/7.2. Already fixed.

4. https://www.rapid7.com/db/?q=x11&type=&page=1 - a great catalogue of already fixed vulnerabilities. Yes, X.org is a very complex piece of code, yes, by Xorg runs under the root user, so it has a very large attack surface considering the sheer amount of interfaces it has to interact with the user.

So, what do we have in the end?

The X11/Xorg server has seen over 800 vulnerabilities according to rapid7.com, a large number of it are down to it running under the root user which Wayland solves automatically. I will not argue, doubt or question that. However, you heavily implied that Xorg is insecure by default even with all the vulnerabilities fixed which you have never demonstrated. I'm glad you're capable of proving that Earth is not flat, but you're failed miserably at proving that Xorg is insecure by definition. It's simply false.

Here's my last argument, quite a serious one.

https://www.helpnetsecurity.com/2021...ise-linux-8-1/
https://www.dbta.com/Editorial/News-...-8-148562.aspx

You don't get it for broken insecure pieces of code. Redhat must have bribed someone, right?

[Myownfriend]

Time to derail the pointless bickering about Wayland (It's the only pony for the future, get on board or get left behind, X11 is consigned to knacker's yard)

Has anyone gotten SwayWM to work with the new Nvidia BETA yet? I heard the driver dev had gotten it working, but I'm still facing errors with this release.

I don't use Sway but I believe I saw a poster on Reddit say that they got it working but they still needed to set "mynextGPUwontbeNvidia" or whatever it's called. What issues are you running into?

[Azrael5]

I think you're on to something here. Whoever built Wayland, built it like they were in a vacuum, with little to no respect to user's needs.
I'm sure they had the best intentions, but I really have a problem with their attitude when people started to point out shortcomings in their creation and their response was mostly "that's not secure" or "not our job".

Imagine if IPv6 came along and said "yeah, we're not doing the whole subnet and broadcast address things because they're not secure/out of scope. But implementers are free to implement them on their own".

Matter is more simple: transitional phase. The transitional phase is longer and problematic in non commercial and low spread Oses because the interest to support the transition is little and it is longer based on the complexity. As example: Nvidia has missed to support Wayland by GBM for long time and doesn't well support MESA. This fact has had aftermaths because oses developers had to face with the problem to make the operating system compliant based on the hardware. It doesn't deal with Wayland. Wayland developers cannot develop what is someone else's responsibility, they cannot replace other developers. Developers make available a product which involve other programs. The developers of the other programs have to implement it. A new graphical stack involves many other instances (desktop environment, frameworks, kernel, compositors and so on) so the complexity increase. The more the complexity, the more the difficulty. So how to face the aftermaths? By active patience: soliciting the developers in progress supporting them by feedback. It's useless to state that a software doesn't work because it is in the process to be integrated. This attitude is not clever. About integration an apparent example: pipewire. Pipewire is an evolution of alsa which improves alsa and is made to take benefit from Wayland. So one benefit generates another benefit. But... before pipewire was developed, Wayland stack had been interfacing just with ALSA and it is meant to replace PULSEAUDIO and JACK as well. The complexity cannot be evaluated with a simple: "I like it" or " I don't like it". Complexity must be examined by objectivity which asks for rational analysis of many several factors.

[MrCooper]

For example back in the day when X was created, it had to target a lot more OS's (the various nix's/bsd's were a lot more popular then) where as Wayland really only target Linux (with other POSIX's OS's having to fend for themselves).

Each OS has always had to stand on its own, even in XFree86/Xorg.

FWIW, the Wayland protocol libraries are now working on FreeBSD, and this is tested in upstream CI to prevent it from breaking. Any other POSIX OS is welcome to join the party.

[oiaohm]

The reorder here is important.

I don't know what you mean by "first version" (first draft, first ratified RFC?), but you made me look. A. Tanenbaum explains IPv4 in IPv6 in 1998. RFC3177 talks about IPv6 subnets in 2001.
You'll have to agree this is in stark contrast to the above features missing in Wayland 13 years in.

https://datatracker.ietf.org/doc/html/rfc1883 IPv6 started life in the RFC standard process in 1995. Go read rfc1883 is down right bare bones the 1995 version of IPv6. Yes iPv4 in IPv6 is 3 years latter. Subnets is 6 years later. Yes I was referring to the first ratified RFC IPv6.

To come to agreement you need parties attempt to implement the standard. Wayland got bound up in many issues include the nvidia. It is fine to complain that the wayland process is being slow. Problem is what you did off the start line. that I have moved to second part.

Fractional scaling, working clipboard and color management should have been part of Wayland since day 1, because they are features no modern desktop can do without.
Instead of that, devs took years to implement one of these and are still figuring out how to deal with the other two.

Notice you said those features should have been part of wayland from day 1. But the 1995 IPv6 rfc1883 makes the case that those features have to be in there from day 1 false idea. The standard is to include what everyone has agree on up until that point.

Then for the areas that you do not have agreement on you need people to implement the different ideas and see what ones are working solutions to the problems and what ones are non working solutions to the problem so you don't make non working a requirement of the standard.

Do any of the missing features listed above look like the kitchen sink to you?

Yes some of the features you do list do look like possible kitchen sink. Fractional scaling and color management may have no part in the wayland protocol itself. Why this could be information that should be in DMA BUF object that is passed around by file handle. Doing this could implement this in a X11/Wayland neutral way. Of course that was not possible while nvidia was using their own structure to define buffers with no means to putting generic metadata on it..

When I say possible kitchen sink it is that those feature could be implemented outside the wayland protocol using like Gbm/DRI/DMA BUF then be generically used back with X11 as well.

Remember IPv6 was not dealing with a Nvidia bit of hardware with network cards. Please don't think the Nvidia of network cards did not exist in 1995 they still existed in the year 2000 new. I remember in the year 2000 have a true POS 1 was IBM PC that would only use IPv4(yes that type of network card will not do IPv6 or any other protocol) and POS 2 had a third party network card that unless you had netbeui connection to some other computer would not allow IPv4 or iPv6 traffic. Fun boss at this business would unplug his laptop and the two shop point of sales computers would disconnect from each other. Yes the boss laptop was provided the second netbeui to one pos so allowing IPv4 to work between the two point of sales computers. Hardware vendors are not always in the right. The good part was is these nightmare network cards did not have major market shares so did not really delay the implementation stage.

bug77 if you want to complain that the Wayland process is slow that fine I will no disagree with this. You do have to remember the dispute with nvidia over dma buf/gbm has slowed down Wayland being implemented by different parts and has slowed the process of testing different possible solutions to find working solutions to expand the wayland protocol with. Yes the way the implementation path of wayland has been been made harder due to dispute with Nvidia I would expect up to 3 to 4 the delays we saw in the IPv6 case.

Big thing bug77 please stop making not realistic day 1 feature mandates. IPv6 from 1995 should kind of make it clear this is not how the standard process works that all features will be there on day one. You hope that in under 5 years of a standard starting that all key features will be there. Bad new I said hope this does not always happen particularly when you have a party like Nvidia disputing over a core feature. Hopefully now that Nvidia getting out the way the wayland standardisation process can speed up. Yes I am serousally crossing fingers that Nvidia or some other major party does not start arguement in a different section.

[bug77]

oiaohm There's a crucial difference here: the RFCs you talk about were drafts, something that was being talked about before ratifying and implementing the new protocol. Wayland simply dropped the crippled code onto the world and expecting everyone else to fill in the gaps.

IPv6 saw almost no adoption until it worked out every kink. While we were somehow supposed to jump onto the Wayland bandwagon the moment it was good enough to power kiosks and other simple devices.

[oiaohm]

oiaohm There's a crucial difference here: the RFCs you talk about were drafts, something that was being talked about before ratifying and implementing the new protocol. Wayland simply dropped the crippled code onto the world and expecting everyone else to fill in the gaps..

https://datatracker.ietf.org/doc/htm...g-ipv6-spec-01 Try again bug77 rfc1883 is in fact ratified as a new protocol. If it was just a draft it has the word draft at the start.

IPv6 saw almost no adoption until it worked out every kink. While we were somehow supposed to jump onto the Wayland bandwagon the moment it was good enough to power kiosks and other simple devices.

https://mirrors.deepspace6.net/Linux...pv6-linux.html
That right November 1996 is when IPv6 was first added to Linux. kernel. This is well before IPv6 is complete.

https://datatracker.ietf.org/doc/htm...gwg-bsd-api-05
Yes this is where testing out of IPv4 in IPv6 started. Subnets are still missing. So Linux kernel users beta testing new parts of the IPv6 protocol here.

bug77 like it or not we are Linux users when it comes to protocols we are commonly early adopters. I am using IPv6 as example but I could pull out examples that not IPv6. Like compiz and the first compositing desktops the X11 extensions that allowed that to work at first were not ratified into the X11 protocol when distributions where releasing with the first composting desktops. In the software stack you have the history of pulseaudio being next to alsa, esound, artsd... before it was ready on Linux and now pipewire next to pulseaudio on many distributions in recent years before it was ready.

bug77 like it or not you claims about not take on Wayland until it ready does not match the Linux world general behavour. The general behavour is take on a new protocol next to existing fill it out then possible in future get rid of the old protocol.

Yes bug77 I will give there has been extra pressure on end users to migrate to Wayland before it ready. This did come about because X11 bare metal was in need of a new maintainer so was going to be left unmaintained so come a dead project. Yes after 2 years of X11 bare metal been in dead state of development we finally got a person willing to take up X11 bare metal maintainer ship but they are also not fund todo this. Yes those wishing to stay on x11 bare metal really do need to work out how to fund the maintainer of X11 bare metal.

bug77 there is something else important that explains some of the X11 servers long term bugs for desktop users the maintainers of X11 on baremetal even the redhat ones only need the kiosks and other simple devices case to work well. There is a problem when you are living on free lunches where you are not getting the option to order the food you like.

Like it or not you arguments are not really based on how the Linux world works. Windows and Mac OS and BSD are not your early adopter OSs. The Linux systems are your early adopter OSs and being early adopter OSs some behaviours should be expected as status normal like:
1) Having the option to use items before they are fully complete
2) Using particular distributions you maybe forced you into trying out particular features before they are complete because the other options may not be provided.
Yes both of those cases is just the normal way Linux works.
Yes Linux is way more early adopter than even using Windows insider versions. If you don't accept this fact about Linux you will not only end up complaining about Wayland you will end up complaining about future things that will happen the same way because its just the nature of Linux.

[tildearrow]

https://datatracker.ietf.org/doc/htm...g-ipv6-spec-01 Try again bug77 rfc1883 is in fact ratified as a new protocol. If it was just a draft it has the word draft at the start.



https://mirrors.deepspace6.net/Linux...pv6-linux.html
That right November 1996 is when IPv6 was first added to Linux. kernel. This is well before IPv6 is complete.

https://datatracker.ietf.org/doc/htm...gwg-bsd-api-05
Yes this is where testing out of IPv4 in IPv6 started. Subnets are still missing. So Linux kernel users beta testing new parts of the IPv6 protocol here.

bug77 like it or not we are Linux users when it comes to protocols we are commonly early adopters. I am using IPv6 as example but I could pull out examples that not IPv6. Like compiz and the first compositing desktops the X11 extensions that allowed that to work at first were not ratified into the X11 protocol when distributions where releasing with the first composting desktops. In the software stack you have the history of pulseaudio being next to alsa, esound, artsd... before it was ready on Linux and now pipewire next to pulseaudio on many distributions in recent years before it was ready.

bug77 like it or not you claims about not take on Wayland until it ready does not match the Linux world general behavour. The general behavour is take on a new protocol next to existing fill it out then possible in future get rid of the old protocol.

Yes bug77 I will give there has been extra pressure on end users to migrate to Wayland before it ready. This did come about because X11 bare metal was in need of a new maintainer so was going to be left unmaintained so come a dead project. Yes after 2 years of X11 bare metal been in dead state of development we finally got a person willing to take up X11 bare metal maintainer ship but they are also not fund todo this. Yes those wishing to stay on x11 bare metal really do need to work out how to fund the maintainer of X11 bare metal.

bug77 there is something else important that explains some of the X11 servers long term bugs for desktop users the maintainers of X11 on baremetal even the redhat ones only need the kiosks and other simple devices case to work well. There is a problem when you are living on free lunches where you are not getting the option to order the food you like.

Like it or not you arguments are not really based on how the Linux world works. Windows and Mac OS and BSD are not your early adopter OSs. The Linux systems are your early adopter OSs and being early adopter OSs some behaviours should be expected as status normal like:
1) Having the option to use items before they are fully complete
2) Using particular distributions you maybe forced you into trying out particular features before they are complete because the other options may not be provided.
Yes both of those cases is just the normal way Linux works.
Yes Linux is way more early adopter than even using Windows insider versions. If you don't accept this fact about Linux you will not only end up complaining about Wayland you will end up complaining about future things that will happen the same way because its just the nature of Linux.

Stop saying like it or not because you do not tell what should people be using.
Linux is not totally an early adopter OS because there are distributions like SLES, RHEL, Ubuntu LTS and openSUSE Leap which are not rolling-release (AKA early adopter) and therefore are more stable.
Wayland development feels slower than X11 development. In just 5 years X11 had enough features to have windowing and a graphical user interface. Surely it did not have data query or screen grabbing, but that was 1990. In just a few years Mac OS 8, AmigaOS 3 and Windows 3.0 had full-featured graphical user interfaces and even setting hotkeys was possible. Heck even on DOS this was possible with TSR.
On the other hand Wayland protocol didn't evolve too much in 5 years since 2008 all it supported was displaying surfaces on the screen and the Weston toolkit didn't even have buttons on the client-side decorations so you could not close applications. It felt like a tech demo. AmigaOS (with some exceptions like AmigaShell and Say), Windows, System/Mac OS and even damn X with TWM had window decorations with BUTTONS that ALLOWED YOU to at least CLOSE the application.
This is because Wayland was not intended for desktop but rather for embedded and stuff, in where it probably got some marketshare.

This brings a problem to the table which is that Wayland devs simply REFUSE to listen to its users, which are majority desktop users, not embedded users.
Truth is that Wayland devs do NOT desire data query, permission system or even global hotkeys in the protocol and instead tell us to implement it ourselves which only leads to more fragmentation as several different and incompatible methods are made.
Nobody (and by this I mean Average Joe) cares if this fancy car runs Wayland or not, but everyone cares if we can set an easy hotkey for e.g. starting a call.

Compositing protocol on X11 taking a long time is because nobody did desktop compositing back then (talking about 1990's) as it was expensive. It only became a thing with Mac OS X and eventually Windows Vista so X11 isn't that late.
Wayland was designed with compositing in mind from previous experience but had Wayland been made 25 years ago then it would not have been like that.
It is like BIOS vs. UEFI. BIOS was designed during a time where computers only had up to 640KB of memory, and storage was scarce. The MBR was tiny and had the boot code but when advanced operating systems arrived like Linux or Windows NT the MBR wasn't enough so the boot program basically became a "load this other boot code then jump" code.
UEFI was designed with modern computing in mind from previous experience so it supported loading larger binaries and drivers.

[tildearrow]

bug77 if you want to complain that the Wayland process is slow that fine I will no disagree with this. You do have to remember the dispute with nvidia over dma buf/gbm has slowed down Wayland being implemented by different parts and has slowed the process of testing different possible solutions to find working solutions to expand the wayland protocol with. Yes the way the implementation path of wayland has been been made harder due to dispute with Nvidia I would expect up to 3 to 4 the delays we saw in the IPv6 case.

Big thing bug77 please stop making not realistic day 1 feature mandates.

Yep, the NVIDIA EGLStreams thing has slowed down Wayland development, but not by much. It is developer attitude that has.

We are not requesting features from day 1. It is day 4766 and it is amazing to see how global hotkeys and data query are NOT in the protocol yet.

[Myownfriend]

We are not requesting features from day 1.

That was in response to when Bug77 said that things like fractional scaling, color management, and clipboard should have been part of the protocol on day one... even though clipboard was there since day one.

Also I wasn't sure what "data query" was so I looked it up and when you search "'data query' wayland" on Google, the first page only brings up three relevant results and two are posts by you. Just based on that, it doesn't seem to be a super requested feature so I don't see why it would be so amazing that it's not part of the protocol yet. I'm not saying it wouldn't be a useful feature but I think some people are putting certain features at priorities that don't match their importance.

One of the aforementioned posts of yours, dated February 23, 2021, is from your website and says that Wayland was cleverly designed to be Gnome-centric. You said that Wayland's lack of support of server-side decorations was proof of that even though Wayland 1.15 added XDG-decoration to negotiation the use of CSD or SSD in 2018. Then you acknowledged that the extension existed in the next sentence and complained that Gnome and Weston didn't implement it and said the only reason they didn't implement it was because they were selfish and wanted to pretend that KDE/MATE/Cinnamon didn't exist. I'm not exactly sure what Gnome and Weston have to do with them though. There's no way to comment on your site so I'm asking for an explanation here.

Also why not write a draft for these extensions yourself or at least open an issue or participate in discussions on Wayland's Gitlab?