Announcement

Collapse
No announcement yet.

NVIDIA 495 Linux Beta Driver Released With GBM Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by tildearrow View Post
    The problem is that this solution is vendor-specific and tied to one implementation (kglobalaccel5). This means that any other compositor would have to pretend to be kglobalaccel5 and even bring in some other toolkit like Qt or KF5, which is super messy.
    kglobalaccel5 is based on dbus as the IPC between applications. KDE applications demo that a dbus for doing Global shortcuts is in fact functional by the kglobalaccel5 work. What is missing is like a org.freedesktop.globalshortcut1 standard. Another interesting point is kglobalaccel5 has had proto code doing it as a privileged dbus service using libinput. So global short cuts might be able to be done without any compositor/display server code.

    Originally posted by tildearrow View Post
    Using D-Bus means that if the compositor processes D-Bus messages in a synchronous and single-threaded way then the stutter problem would not be gone.
    http://www.burtonini.com/blog/2005/0...us-dbus-calls/
    Point that is over looked is that D-Bus is designed to be able operate asynchronous and if you look at the weston dbus code closely is using asynchronous dbus processing.

    This is also why I questioned if libweston dbus handling code should be moved to libwayland-server and libwayland-client.

    Originally posted by tildearrow View Post
    Sorry using D-Bus means possible stutter and stalls. If the compositor does not do it well and handles D-Bus events in a synchronous, single-threaded way (it potentially could!) then it will be no different from X11 in this regard.
    If the compositor does this its not up to the reference weston compositor standard. Asyncronous dbus is what you need to pass the testsuite of wayland as well.

    Originally posted by tildearrow View Post
    Screen recording and casting? Already done by PipeWire which seems to be what most compositors are using.
    No its not PipeWire alone this is a combination of PipeWire and DBus. The DBus side is define under xdg-desktop-portal. https://flatpak.github.io/xdg-deskto...rtal-docs.html so this is using dbus.

    Originally posted by tildearrow View Post
    Querying of the mouse position, keyboard LED state, etc. (data query)? This is missing. AT-SPI2 is not a solution as it is incomplete and GNOME-only. So it is missing, at least in a standard way.
    This one serous-ally need to be shorted out. This is still possible something doable by dbus particularly that lot of this stuff you want behind permissions.

    Originally posted by tildearrow View Post
    Global shortcuts? This is missing. At least in a standard way.
    I don't see why this cannot be standard on dbus. So being like screencapture and systemtray. Personally I would want to put this in xdg-desktop-portal because you would think flatpak/snap/contained applications would want to have means to setup Global shortcuts as a permission granted thing. This would get us on a path where xace or other methods that disable keyboard snooping under X11 don't result in non functional applications that need to use global shortcuts.

    Originally posted by tildearrow View Post
    System tray? I personally ignore this point, but yeah. It could be something like org.freedesktop.ApplicationTray1 or wait even better why not extend the notification system to support it?
    https://www.freedesktop.org/wiki/Spe...sNotifierItem/
    org.freedesktop.StatusNotifierItem, org.freedesktop.StatusNotifierWatcher and org.freedesktop.StatusNotifierHost-id are already define to do System tray over dbus. Gnome and KDE and many others already use this. So system tray in lot cases is already neutral between X11/Wayland implementations. Yes the old system tray over X11 was deprecated by this Status NotifierItem thing for X11 usage as well.

    So system tray support could be marked as done. Yes System tray done using the dbus StatusNotifierItem does not have to be run in the wayland compositor so could be a generic wayland application providing system tray as well.

    Sorry I skipped system tray because in my mind its ready done. No reason for system tray to be in wayland protocol at all and if you did put system tray in the wayland protocol you are creating duplication.

    Originally posted by tildearrow View Post
    Graphical settings management? Missing in a standard way. Currently you have to use D-Bus and rewrite your code THREE times. One for KWin (KScreen), one for GNOME (whatever it is) and one more for Sway (wlroots). And if somebody uses Weston then you are out of luck as it does not provide any interface for display setup. If there was a standard, like org.freedesktop.DisplayConfiguration1 then that would be nice.
    Please do remember with dbus is possible for a dbus service to call back to dbus to use another dbus service. So the 3 different ways could be put behind a xdg-desktop-portal wrapper so making application developers time simpler.

    Originally posted by tildearrow View Post
    Fast user switching/multiple? I ignore this point.
    This really most likely falls under the logind dbus interfaces. So this might already be done part the optimisations to suspend to disk users not currently active. Remember the wayland compositor is to run as your user so when you switch to a different user they should have their own wayland compositor. So fast user switching/multiple users is not something that owns in the wayland protocol at all because 2 users should not be using the same wayland compositor.

    Originally posted by tildearrow View Post
    Session configuration? I ignore this point as well.
    Lot of this is in fact ready done by different means over dbus. Yes a lot of this does need to be standardised.

    Originally posted by tildearrow View Post
    Thing is that the secondary IPC on Windows, macOS, iOS and Android is fast. Android does it at a near-kernel level. Windows does it using syscalls. But D-Bus is slow. Usually.
    On Linux systems dbus using dbus-broker is not slow turns out to be faster than windows syscall methods(these are not exactly fast). Yes there does need to work to improve dbus performance on freebsd and other things.

    System tray the solution to that already existed as a dbus so there is no need for wayland protocol to have a systemtray this would just mean you have to write special system trey code for wayland. The dbus system tray solution works under X11 and Wayland so code once and you are done.

    tildearrow this is something important to remember. The items you can do by dbus can be used generically on a X11 desktop or a wayland desktop.

    tildearrow please note I am not saying things don't need fixing. People are complaining that they are hitting a brick wall because they are asking for features to be in wayland protocol without asking the question should this be part of the wayland protocol. Lot of cases when you think about it those features don't really make sense to be in wayland protocol. Yes the feature may not be standardised between implementations yet but items like kglobalaccel5 for global shortcuts demo that the dbus solution providing this feature can be fully functional.

    Remember one of the things you complained about that you did not want to have to rewrite something 3 times. Do you want to have to write this stuff twice long term once for X11 mode and once for Wayland mode? The stuff you can implement using dbus can result in 1 interface that does not care if you are running X11 or Wayland.

    xdg-desktop-portal really should support global short cuts. If we were get xdg-desktop-portal used commonly for global short cuts under X11 it would be possible to turn off global keyboard snooping on X11 so fixing up security problem there. So allow fixing X11 security problem while filling in missing functionality on Wayland in a generic way so 2 birds 1 stone.

    Comment


    • Originally posted by oiaohm View Post

      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.
      Any card with either Maxwell 1 or Maxwell 2 is still supported but the GT 750M is based on a Kepler GPU

      Comment


      • Originally posted by Myownfriend View Post

        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?
        I'm finding the cursor is borked, likely just teething issues caused by running a mishmash of unstable libs.
        Code:
        00:00:01.580 [DEBUG] [wlr] [xcursor/wlr_xcursor.c:243] Loaded cursor theme 'default' at size 24 (124 available cursors)
        00:00:01.581 [DEBUG] [wlr] [render/allocator.c:30] Trying to create gbm allocator
        00:00:01.581 [DEBUG] [wlr] [render/gbm_allocator.c:196] Created GBM allocator with backend nvidia
        00:00:01.581 [DEBUG] [wlr] [render/gbm_allocator.c:199] Using DRM node /dev/dri/card0
        00:00:01.581 [DEBUG] [wlr] [types/wlr_output.c:1187] Failed to intersect display and render modifiers for format 0x34325241
        00:00:01.581 [ERROR] [wlr] [types/wlr_output.c:1258] Failed to pick cursor format
        00:00:01.581 [ERROR] [wlr] [types/wlr_output.c:1342] Failed to render cursor buffer
        00:00:01.581 [DEBUG] [wlr] [types/wlr_output.c:1403] Falling back to software cursor on output 'DP-2'

        Comment

        Working...
        X