<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard <span dir="ltr"><<a href="mailto:keithp@keithp.com" target="_blank">keithp@keithp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes:<br>
<br>
> I think I like option 1 (KEITHP_kms_display).  If the client knows the<br>
<span class="">> difference between render and primary for 2, then they are most likely<br>
> already opening the master node themselves or at least have access to<br>
> the FD.<br>
<br>
</span>Ok, I'll work on cleaning up that extension and renaming it. I have no<br>
idea how to get new words into the Vulkan spec, but it would be good to<br>
have that done too.<br></blockquote><div><br></div><div>Once we're sure that's what we want, create an MR against the spec that just adds enough to the XML to reserve your extension number.  That will get merged almost immediately.  Then make a second one with the actual extension text and we'll iterate on that either in Khronos gitlab or, if you prefer, you can send it as a patch to mesa-dev and then make a Khrons MR once it's baked.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess the question is whether I should bother to leave the current<br>
try-to-open-primary kludge in place. In good news, under X, both radv<br>
and anv "fail" to use the primary device as another master is already<br>
running, so at least we aren't running with a primary FD open?<span class=""><br></span></blockquote><div><br></div><div>See also my comments about GEM handle ownership.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Sorry, I'm just not feeling all that opinionated about this at the moment.<br>
> :-)<br>
<br>
</span>No more than I; either way is fine with me, if you're happy to use<br>
something like the existing code I've got, that's even nicer.<br>
<span class=""><br>
> Clearly, we need systemd-edidd. :-)<br>
<br>
</span>A library would be nice; we have the edid data everywhere, we just don't<br>
have it in a useful form except inside the X server and kernel.<span class=""><br></span></blockquote><div><br></div><div>Yeah, in the scary new world of Wayland compositors, having an edid library would be a very good thing.  No sense in having everyone fail to handle it properly themselves.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Yes, *if* it has a preferred resolution, we should return that one.  If it<br>
> doesn't, we should walk the list and return the largest instead of just<br>
> defaulting to 1024x768.  At least that's what the spec seems to say to<br>
> me.<br>
<br>
</span>Oh. I totally missed that part. Yeah, that's just wrong. I've just<br>
pushed a patch that finds the largest mode when there isn't a preferred<br>
one. Oddly, I have no devices here which don't specify a preferred mode,<br>
so it will be somewhat difficult to test...<br>
<span class=""><br>
> Yup.  Let's just drop INHERIT and only advertise OPAQUE.<br>
<br>
</span>Done.<br>
<br>
I've updated my drm-lease branch with all of these changes merged into<br>
the existing patches (and so noted), plus the new patch described above<br>
which looks for the largest mode when no preferred mode is specified.<br>
<br>
Thanks again for all of your careful review; while we haven't changed<br>
any significant semantics, we have found a bunch of outright bugs in the<br>
code.<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Glad to help. :-)  I figure I should learn something about KMS one day and reviewing this is as good an opportunity as any.<br></div></div>