Bug#908005: nvidia-driver: When initializing vulkan, driver opens default XDisplay

[Felix Dörre]

On 9/7/18 12:27 PM, Luca Boccassi wrote:
> Control: reassign -1 bumblebee
> Control: forcemerge 892646 -1
>
> On Wed, 2018-09-05 at 06:52 +0200, Felix Dörre wrote:
>> Package: nvidia-driver
>> Version: 390.77-1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> I have an Nvidia-Optimus setup and use bumblebee to activate the
>> Nvidia GPU on demand.
>>
>> When I use libvulkan.so.1 to run a Vulkan application the ICD from
>> Nvidia (installed in /usr/share/vulkan/icd.d/nvidia_icd.json,
>> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1) opens a connection to
>> the
>> default X Display (as specified by the DISPLAY environment variable).
>> When using bumblebee to activate the Nvidia GPU, the driver must
>> connect to Display :8, where bumblebee runs the secondary
>> X Server. However I want to run my application with the DISPLAY
>> environment variable set to :0 (as I want it displayed on :0).
>>
>> I generally would expect the Vulkan-Nvidia driver not to require an
>> X-connection when doing headless rendering and for 'normal' rendering
>> use the X-connection/display that is indicated by the surface-
>> creation functions, and not choose one by itself on startup.
>> If that is hard to achieve, I would at least expext the Nvidia-Driver
>> to have some override environment variable (like e.g. NV_DISPLAY)
>> that, when set, is passed by the Nvidia-Driver to XOpenDisplay, that
>> "normal" applications would ignore.
> Hi, Vulkan is not supported on Optimus, see #892646.
>
:-) Yes, that's exactly what I am currently trying to implement when I 
encountered this problem. The misbehavior I am describing is a problem 
in the nvidia driver that obstructs me from implementing a primus-like 
solution for vulkan. For this I only use bumblebee to activate the GPU 
and don't use/need primus for the GL-bridge.

Additionally I believe that also non-Optimus users can encounter this 
problem in non-standard usage scenarios, when the environment variable 
DISPLAY is wrong and the application uses another way to determine the 
correct display to call XOpenDisplay upon. The driver will then fail to 
load, however it should not depend on $DISPLAY at all.