NVIDIA 495 Linux Beta Driver Released With GBM Support

[tildearrow]

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.

Small correction to my statement: No desktop supported fractional scaling when Wayland was started in 2008 since HiDPI displays were a niche that only stopped being so when Apple released their Retina Displays.

[oiaohm]

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.

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/nvidia-linux/1284412-nvidia-495-linux-beta-driver-released-with-gbm-support?p=1285224#post1285224

You are not bug Bug77 absolutely did.

Data query I guess this means query server state. Wayland protocol that is off limits.

global hotkey registration is most likely something that should be dbus portals..

http://blog.martin-graesslin.com/blog/2015/06/global-shortcut-handling-in-a-plasma-wayland-session/

At this stage gnome/kde... all have different ideas how global hotkeys should be done. Of course the new solutions from KDE and gnome don't end up with a growing pool of programs keylogging as you do under X11 of old.

tildearrow I am shocked that we have had X11 server for 36years and we don't in fact in the X11 protocol have a proper system for global hotkeys either. Yes global hotkey handling is not part of X11 protocol either. This is something that does need to be properly fixed in Wayland and X11.

Yes it global hotkey processing using multi X11 input backends that lead to X11 servers at times stalling out for seconds at a time. Remember X11 protocol has had 36 years to have agreement to have a common hotkey solution instead of just keylog everything looking for the hotkey. Yes every application under X11 historically using global hot key is keylogging every single key pressed. This is very wasteful on CPU and makes locking issues in the input system more likely to raise their ugly head.

[tildearrow]

https://www.phoronix.com/forums/foru...24#post1285224
You are not bug Bug77 absolutely did.

Data query I guess this means query server state. Wayland protocol that is off limits.

global hotkey registration is most likely something that should be dbus portals..

http://blog.martin-graesslin.com/blo...yland-session/
At this stage gnome/kde... all have different ideas how global hotkeys should be done. Of course the new solutions from KDE and gnome don't end up with a growing pool of programs keylogging as you do under X11 of old.

tildearrow I am shocked that we have had X11 server for 36years and we don't in fact in the X11 protocol have a proper system for global hotkeys either. Yes global hotkey handling is not part of X11 protocol either. This is something that does need to be properly fixed in Wayland and X11.

Yes it global hotkey processing using multi X11 input backends that lead to X11 servers at times stalling out for seconds at a time. Remember X11 protocol has had 36 years to have agreement to have a common hotkey solution instead of just keylog everything looking for the hotkey. Yes every application under X11 historically using global hot key is keylogging every single key pressed. This is very wasteful on CPU and makes locking issues in the input system more likely to raise their ugly head.

I made a correction above.

Data query (at least that is how I call it) means like being able to retrieve keyboard input, mouse position, mouse events, current active window, window positions and layouts and other things.
X11, Windows and even freaking macOS have protocols/APIs for that. Wayland does not. And no, those shall be part of the Wayland spec because nobody, and literally nobody is willing to write the same code 100 times just to support every Wayland compositor in existence. Same thing happened with EGLStreams. Nobody had the will to write code to support that weird buffer system so NVIDIA after 7 years of selfishness finally understood and added GBM support as the title of this very thread and discussion reads (it still amazes me how much we can derail here).

oiaohm yes global hotkeys under X is a hack but at least IT WORKS. But it was the same way on MS-DOS you had to listen to every key and look for the key. on Wayland you cannot even do that which is A FLAW.
macOS did it amazingly. Secure and featureful. Data query is possible and guarded by a permission system as it should be.

As long as these X vs. Wayland wars keep going and:
- there are people who don't realize X11 is insecure
- there are people who don't realize Wayland is incomplete (including its devs)
then we will never see the future of desktop Linux.

[oiaohm]

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.

Having the option to use items before they are fully complete
This feature exist in all those distributions you just listed. SLES, RHEL, Ubuntu LTS and openSUSE all include packages you can choose to install and user that are not fully complete. Like it or not almost all Linux distributions do have early adopter nature. So software will be included before its fully functional.

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.

This absolutely not different to the IPv6 process or the X11 protocol development process or many other development processes. Yes this is a process where you make several different and possible incompatible methods and them bless one that works the best into the standard/reference implementation. Of course to do this process you need some users.

1) global hotkeys is a unsolved problem with X11 protocol. They are many bugs that are caused by the way people hack around X11 protocol.

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.

This is not getting why Wayland did not include it. How would like you to press a button to make a call only to find out the system stalled out for 15 seconds and you missed the call or if a mute was delayed. This happens under x.org X11 server at what appears to be random. Yes its the multi X11 input system mixed with multi different keylogggers running resulting in mega screw up.

The realty is every time you use a global hotkey under X11 you are rolling a dice if it works right. Yes it also a cause why input under X11 can stutter badly when particular mixes of applications are loaded.

So welcome to hell. You have users asking wayland developers to implement features of X11 that are in fact broken and not working right. These features need to be redesigned.

Average Joe is not happy with the behavour of X11 in many places either. People complaining about not being able to restart Wayland compositor there is a mirror problem that you cannot restart x11 server generally either. Remember Xpra has been around for a very long time and if it methods had been embedded in toolkits there is a good chance that we could just randomally fully restart the X11 server.

The broken state of X11 you can find by look at the features that are missing from Wayland then checking out if they in fact work properly under X11. 99.9% of the time(and that not a guessed number) the case is X11 is also broken in that area. Lot of ways instead of demarding Wayland get particular feature instead the focus should be how to implement these feature so into the future it can work right under X11 and Wayland for new applications.

[oiaohm]

Data query (at least that is how I call it) means like being able to retrieve keyboard input, mouse position, mouse events, current active window, window positions and layouts and other things.

This get interesting.

macOS did it amazingly. Secure and featureful. Data query is possible and guarded by a permission system as it should be.

There is a problem here. Is most of this data query using the compositor protocol of MacOS. The answer is no. Wayland protocol is the compositor protocol. MacOS is use their equal to dbus back to the compositor for the Data query stuff on windows positions. This would be more like a freedesktop portal protcol like how screen capture is being done.

oiaohm yes global hotkeys under X is a hack but at least IT WORKS. But it was the same way on MS-DOS you had to listen to every key and look for the key. on Wayland you cannot even do that which is A FLAW.

This is a hack that not part of the specification. MS-Dos by design did not technically support global hotkeys either. Yes the TSR hack. Please note both MS-DOS and X11 global hotkey hacks break down if you get too many applications attempting todo global hotkeys at the same time. This is not IT Works this is "It works for me while I am lucky" one day you lucky will run out.

As long as these X vs. Wayland wars keep going and:
- there are people who don't realize X11 is insecure
- there are people who don't realize Wayland is incomplete (including its devs)
then we will never see the future of desktop Linux.

There is a third. People like you who have the idea that feature that don't exactly make sense to be in a compositor protocol should be in a compositor protocol.

There are particular things that were done under X11 by hack methods that really should be moved to dbus and the likes of org.freedesktop.portal.

The final standards for a wayland desktop should be a mix of wayland protocol for output and generic input and stack of dbus protocols for items that need permissions like query the real location of mouse on screen and real window positions.

tildearrow the the third problem type that you are is that you have the wayland hammer in you hand and now everything thing to drive in has to be a nail right. The correct answer is not that black and white. Some things should be solved by wayland protocol, others should be solved in mesa/graphics stack and others should be solved with dbus protocols and there is possible another other.

[Myownfriend]

Data query (at least that is how I call it)

Wasn't aware of this whole page of discussion when I edited my last post where I mentioned that searching "'data query' Wayland" on Google only resulted in three relevant results on the first page and two of them were you. This explains why.

[Myownfriend]

there are people who don't realize Wayland is incomplete (including its devs)

They know that. That's why they release new versions and that's why Wayland 1.0 was give a version number at all. Linux isn't "complete" either. No software or protocols in their positions are ever really complete because they're part of an ever changing ecosystem.

[Myownfriend]

There is a third. People like you who have the idea that feature that don't exactly make sense to be in a compositor protocol should be in a compositor protocol.

I agree with this. Wayland isn't the only means of implementing standardized protocols used by the Linux ecosystem and just because Wayland doesn't implement things, it doesn't mean that people all need to create their own independent implementations of those features. Pipewire is the most popular example of that. It's not part of the Wayland, Gnome, or KDE projects yet it works with Wayland and Gnome, KDE, Chrome, and Firefox use it. Since it's also an audio server that's includes compatibilities layers for PulseAudio and Jack, it even has use in X11 sessions.

Maybe some of the naysayers would understand that if Pipewire and portals were used to do capture in X11 sessions or something, too. Is there anything prevents that? I'm not really sure.

[adlerhn]

Kepler is gone.

Also, picking a Kepler from supported-gpus.json from the extracted installer...

"devid":"0x11B4","name":"Quadro K4200","legacybranch":"470.xx"

Any chance that Nvidia will backport the GBM support to the 470 series, for Kepler support? (GeForce GT 750M)

[oiaohm]

Any chance that Nvidia will backport the GBM support to the 470 series, for Kepler support? (GeForce GT 750M)

I would no to Kepler Nvidia has even announced they are dropping windows driver development for Kepler as well that there will be no new features so this is not a Linux only policy. https://www.techradar.com/news/nvidi...chopping-block but GeForce GT 750M is technically not Kepler that is a Maxwell at the silicon level. adlerhn your guess is as good as mine if the GeForce GT 750M will be supported at some point or not because its a Kepler by number and a Maxwell by silicon(as in 800 series).

This is one of the problems with closed source drivers vendors can draw totally made up lines in the sand that have no relationship to what the silicon really is.