Jason Ekstrand <jason@xxxxxxxxxxxxxx> writes: > That seems good to me. Unless, of course, DPMS is something we expect to > change over time somehow. Then again, we don't handle that at all right > now so meh. Let's go with what you wrote above for now. It's not even the dpms value, it's the dpms property itself, which DRM never changes. > They shouldn't be and that's why I'm a fan of making them asserts which get > compiled out instead of actual checks. Also, I find this pseudo reference > counting to be somewhat confusing and adding asserts informs the reader of > the assumptions made. Ok, I've added this. > What test suite? Honestly, I know of no code anywhere that actually uses > this API for anything other than VR headsets. > > I guess it's kind-of a question of how much effort we want to put into > this. One option would be to add VK_KHR_display support to vkcube and make > it automatically show up on all your displays using hotplug events. > > If we're going to not care, returning VK_ERROR_FEATURE_NOT_PRESENT is > probably the best thing to do since at least the app has feedback. Not caring seems best to me -- the Vulkan display API isn't capable of supporting a "real" window system; for that, you'd really want to use DRM directly and create some way to share that with Vulkan like the extension I wrote to pass the DRM master FD into the driver at init time. > Awesome. I think we're really close on this one. I'll send out the current series and you can see if you like it. -- -keith
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
