On Tue, May 21, 2019 at 12:01:29PM +0300, Pekka Paalanen wrote: > Hi Daniel, > > what says the assumption of the only monitor being driven by CRTC 0 > was a bad one? :-p > > It's probably not obvious that userspace needs to explicitly try to > avoid invalid configuration combinations by inspecting the current full > configuration and not just the one CRTC/connector it wants to use. Well the entire point of atomic is that you do set the entire config. The -modesetting atomic conversation tried to just use the atomic ioctl by 1:1 replacing legacy ioctl calls, and they screwed things up. If it would have applied the entire configuration in one go, it would work. > > All current atomic in -modesetting can do is pageflip and dpms off/on > > on the first screen on the first crtc. Anything more fancy goes boom, > > like where you change the connector/crtc links. > > > > It's _really_ broken :-) > > But it worked exactly that much, until a kernel change broke it, right? > Yes, I totally see the sillyness, but if it worked and we have these > no-regression rules... Which is why the offending patch has been reverted. Any the way forward is to just disable atomic from the kernel for X.org, because the legacy path actually works. We also have patches to disable atomic in -modesetting, but they're stuck. > > > I don't personally really like these rules, but if these are the rules, > > > then so be it. In my opinion it would be a huge step forward to get and > > > require uAPI specifications, that people could verify both kernel and > > > userspace against. Verifying against kernel code with no spec is what > > > leads to the -modesetting issue by the sounds of it. > > > > > > Documenting kernel internal interfaces is not it. People reading > > > DRM internal interface docs would need to know how DRM works internally > > > before they could map that information into uAPI, which makes it less > > > useful if not even useless for userspace developers. > > > > vgem is the idea here for validation, but if people ship atomic code > > that was never tested except for "boots on my laptop", then nothing is > > going to help. > > A testing pattern library with vkms would be awesome indeed. > > > And yes we have a huge gap with uapi documentation. btw for properties > > those section are meant to be useful for userspace people too: > > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties > > > > and all subsequent chapters. I guess it's a bit burried, but this part > > is meant to be the uapi spec for properties. Is that also failing your > > expectations? > > Yes: it is hard to find (it is in Driver Developer's Guide, buried > several chapters in), it is interleaved with lots of DRM internal > details, makes references to DRM internal functions, and probably > relies on DRM internals behaviour through the references by not > repeating what they do. > > It is useful once you find it, but I don't think it's enough for making > good use in userspace for someone who hasn't been a DRM kernel > developer. Summarizing our long irc chat on this: I agree, everyone else agrees, but it's a question of making it happen and having someone with sufficient tech writer experience to make it useful. What we have now is essentially what happens if I type uapi specs (I pushed for these property docs). As you can see, it ain't pretty :-/ I think at least the process v4l has, where missing docs for uapi causes the doc build to fail, is sound. I have no idea how to adapt that to what we do, both from a "this will take a few years to fill the gaps and I don't know how to write good specs" and more implementation pov - properties can be created anywhere, no changes to include/uapi required. So hard to spot automatically. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
