Jason Ekstrand <ja...@jlekstrand.net> writes: > I think I like option 1 (KEITHP_kms_display). If the client knows the > difference between render and primary for 2, then they are most likely > already opening the master node themselves or at least have access to > the FD.
Ok, I'll work on cleaning up that extension and renaming it. I have no idea how to get new words into the Vulkan spec, but it would be good to have that done too. I guess the question is whether I should bother to leave the current try-to-open-primary kludge in place. In good news, under X, both radv and anv "fail" to use the primary device as another master is already running, so at least we aren't running with a primary FD open? > Sorry, I'm just not feeling all that opinionated about this at the moment. > :-) No more than I; either way is fine with me, if you're happy to use something like the existing code I've got, that's even nicer. > Clearly, we need systemd-edidd. :-) A library would be nice; we have the edid data everywhere, we just don't have it in a useful form except inside the X server and kernel. > Yes, *if* it has a preferred resolution, we should return that one. If it > doesn't, we should walk the list and return the largest instead of just > defaulting to 1024x768. At least that's what the spec seems to say to > me. Oh. I totally missed that part. Yeah, that's just wrong. I've just pushed a patch that finds the largest mode when there isn't a preferred one. Oddly, I have no devices here which don't specify a preferred mode, so it will be somewhat difficult to test... > Yup. Let's just drop INHERIT and only advertise OPAQUE. Done. I've updated my drm-lease branch with all of these changes merged into the existing patches (and so noted), plus the new patch described above which looks for the largest mode when no preferred mode is specified. Thanks again for all of your careful review; while we haven't changed any significant semantics, we have found a bunch of outright bugs in the code. -- -keith
Description: PGP signature
_______________________________________________ mesa-dev mailing list firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev