On Thu, Apr 19, 2018 at 10:11:05AM +0300, Tomi Valkeinen wrote: > On 19/04/18 09:34, Daniel Vetter wrote: > > >> But the kernel cannot know what the user wants to do, so it cannot > >> configure the planes. If we have an HDMI output which supports 2k+ and a > >> -2k LCD, and 4 hw planes, we can set up the planes at least in the > >> following ways: > >> > >> - One virtual plane on HDMI, two normal planes on LCD. Here the normal > >> planes can also be used on the HDMI, as long as the input width is -2k. > >> > >> - One virtual plane on HDMI, one virtual plane on LCD, but sometimes > >> both planes on the same display (either HDMI or LCD). > >> > >> - No virtual planes (and fbdev support disabled). This needs the > >> userspace to take care not to configure 2k+ planes. But considering that > >> the modes supported are still quit close to 2k in width, I believe > >> upscaling a 2k plane cover the whole display would provide quite ok image. > >> > >> Each of those requires a different virtual plane setup. > > > > Why do you want to hardcode this in DT? The recommended approach is to > > have a bunch of virtual planes, and runtime assign whatever hw resources > > you need to get there. If you run out of hw planes you just fail with > > -EINVAL in atomic_check. > > That is possible, but how many userspace apps will work correctly if the > planes work or don't work in a random manner (from userspace's point of > view)? I like the idea more that the DRM driver exposes a lesser number > of planes which always work, instead of exposing larger number of planes > which sometimes do not work. > > And with userspace apps, I don't mainly mean Weston and X, but instead > the numerous custom applications the customers write themselves. Perhaps > I'm worrying too much, but I can imagine a flood of support requests > about why plane setup is not working when one does this or that simple > setup. Stuff randomly not working is officially how atomic works. That's what the TEST_ONLY mode is for. There's a lot more than virtualized planes that might or might not push any given plane setup over some random hw limit: memory bandwidth, aggregate scaling limits (because not enough fifo), thermal limits, aggregate pixel clock limits. There's all kinds of cases where with one setup you can light up 4 planes, then move them a bit and only 3 work. And yes sometimes that means you can't light up all the outputs if you have a too fancy plane config on the other CRTC. Only userspace which is written with intimate knowledge of the exact kernel driver and hw it runs on can avoid TEST_ONLY and some kind of fallback strategy to "render everything into the 1 single primary plane". Both drm_hwcomposer and weston atomic have such a fallback strategy (with various degrees of intermediate cleverness). > Also one complication with runtime assignment is that the hw planes are > not identical: some support YUV modes, some don't, some support scaling, > some don't. That's probably not a show stopper, but it does limit the > options as e.g. we can't have all virtual planes advertising YUV support > when we have a hw plane that doesn't support YUV. Yeah that makes it a notch more complicated to implement. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
