Announcement

Collapse
No announcement yet.

Linux 4.15 Will Treat The HTC Vive VR Headset As "Non-Desktop"

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

  • hikingpete
    replied
    This sounds like it may be useful for DLP based SLA 3D printers. These devices often connect via HDMI to a host computer, and the display is used to expose resin.

    Leave a comment:


  • haagch
    replied
    Originally posted by DMJC View Post
    What's stopping this being added to the PSVR? It already works on Linux.
    Nothing, you just have to make an entry like that: https://github.com/torvalds/linux/co...d1f3ae8ed01922
    Sucks a bit that it's embedded in the kernel source code. Would be much better if it were a user writeable database so you don't have to wait for the next major kernel release to get direct mode whenever a new HMD comes out.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by danboid View Post
    Have GNOME, KDE or any other desktop announced any plans to utilise this new display mode?
    The entire point of a "non desktop" flag is that desktops don't use it. It's basically a way of saying "I know this looks like a normal display, but it's not"... software that actually knows what to do with a VR display will use it, and everything else should pretend it doesn't exist.

    Leave a comment:


  • DMJC
    replied
    What's stopping this being added to the PSVR? It already works on Linux.

    Leave a comment:


  • haagch
    replied
    By default, the displays will permanently be shown as "disconnected" in stuff like randr.

    Yes, the kernel part is not tied to Xorg. I mean if you write an app that can use the API directly, it doesn't have to run with xorg, it's just the wiring up of randr and the vulkan extensions etc. that is first done for X.
    I think..

    Leave a comment:


  • beniwtv
    replied
    Originally posted by haagch View Post
    Actually "drm leases" will be Xorg only for the time being, but as I understand it, it shouldn't be hard to add it to wayland too.
    Hmm, not sure if I get how these DRM leases are supposed to work - aren't they a part of the Kernel DRM infrastructure? What role does X.Org play in them?

    In my mind, leases sounded like a purely DRM/Kernel thing, and when an app such as SteamVR requests a "lease" for a display, that display would have just been hidden from the normal DE's / XOrg / Wayland (i.e. "display disconnected"), so it can be used by the app directly, using Mesa GL/Vulkan via EGL or such and the Kernel drivers, without XOrg or Wayland.

    Which then wouldn't need patches to XOrg / Wayland.

    But I probably have everything wrong






    Leave a comment:


  • haagch
    replied
    Actually "drm leases" will be Xorg only for the time being, but as I understand it, it shouldn't be hard to add it to wayland too.

    Gnome, KDE etc. won't want to use this directly, unless they want to become "VR compositors".
    With OpenVR/SteamVR it works like this: You start SteamVR, which includes a "vrcompositor". The compositor gets the respective HMD display, ideally with exclusive access in "direct mode", and then just displays some basic environment on it. When you start a VR app, it connects to the compositor and submits two textures per frame to the compositor, for the left and right eye. The compositor then deals with distorting the textures so when they are viewed through the lenses, the image is undistorted, and it also displays something that doesn't cause motion sickness when the application doesn't submit frames fast enough. (It's really disorienting when an image that fills your field of view just freezes in front of your face when you expect it to follow your movements).

    Of course kwin/mutter/etc. *could* become VR compositors like that, but so far I only heard that people from gnome are *possibly* looking into it and no concrete plans.

    A VR application can also disregard any compositor and just open a display with direct mode itself, and display something that hopefully looks right when viewed through a HMD.

    As the developers said, the "drm leases" infrastructure may also be used by other displays that shouldn't be used for desktop displays, like the Apple Touchbar display, so you will either have dedicated applications that can render to displays like the touchbar via drm leases, or - what I'd like to see - you get a wrapper script where you can display any X application on such a display.

    Leave a comment:


  • FishPls
    replied
    Originally posted by danboid View Post
    Will both Xorg and Wayland be able to use this new "non-desktop" display mode or will it be Wayland only?

    Have GNOME, KDE or any other desktop announced any plans to utilise this new display mode?
    It's actually X11 only right now, AFAIK.. At least KeithP only wrote X server patches for taking advantage of the leasing stuff.

    Leave a comment:


  • Ardje
    replied
    Originally posted by danboid View Post
    Will both Xorg and Wayland be able to use this new "non-desktop" display mode or will it be Wayland only?

    Have GNOME, KDE or any other desktop announced any plans to utilise this new display mode?
    The problem is that the kernel boots up, sees a display, and starts spewing out console on a display that might get burn damage from it. I actually love that property. I really had my share of kernel bugs when there were to framebuffers and the kernel could not decide on which to put a fbcon. And when it decided wrong (depends on loading race), it will panic about that device on that same device.
    In those cases I had to carefully remove anything that could trigger the enabling of fbcon.

    For wayland and xorg it's not a problem, because you can configure them before using them. Neither wayland or xorg are consoles.

    Leave a comment:


  • danboid
    replied
    Will both Xorg and Wayland be able to use this new "non-desktop" display mode or will it be Wayland only?

    Have GNOME, KDE or any other desktop announced any plans to utilise this new display mode?

    Leave a comment:

Working...
X