Hi Ville, On 05-01-2017 11:46, Ville Syrjälä wrote: > On Thu, Jan 05, 2017 at 10:07:45AM +0000, Jose Abreu wrote: >> Hi Ville, >> >> >> On 04-01-2017 16:36, Ville Syrjälä wrote: >>> On Wed, Jan 04, 2017 at 04:15:01PM +0000, Jose Abreu wrote: >> >> [snip] >> >>>>> Why does userspace need to know this? My thinking has been that the >>>>> driver would do the right thing automagically. >>>>> >>>>> We do probably want some kind of output colorspace property to allow the >>>>> user to select between RGB vs. YCbCr etc. But I think even with that we >>>>> should still allow the driver to automagically select YCbCr 4:2:0 output >>>>> since that's the only way the mode will work. >>>> I agree. When only 4:2:0 is supported there is no need to expose >>>> the flag to userspace. How shall then I signal drivers for this >>>> 4:2:0'only sampling mode? >>>> >>>> So, for the remaining modes, you propose a new field in the mode >>>> structure called 'colorspace' which contains the list of >>>> supported sampling modes for the given mode? I think it would be >>>> a nice addition. This way if a mode supports only RGB we only >>>> passed RGB flag; if 4:2:0 was also supported we passed the 4:2:0 >>>> flag, ... And then user could select. We also have to inform user >>>> which one is being actually used. >>> IIRC there aren't any "RGB only" modes or anything like that. So >>> YCbCr 4:2:0 is the special case here. We could just add something to the >>> mode struct for it, or do we already have some other flags thing that's >>> not exposed to userspace? And I guess drivers should be able to opt into >>> supporting these 4:2:0 modes in similar way they opt into >>> interlaced/stereo/whatever. >> I mean, if a source EDID does not declare support for YCbCr modes >> (4:2:2 and 4:4:4 [i think they have to be both supported if sink >> supports != RGB]) then only RGB can be used. Or is any YCbCr that >> is pre-required? Still, I see your point. When EDID declares >> support for YCbCr then all modes can use it, and not only some of >> them. >> >> I think for stereo modes the flags can be opt in/out in userspace >> exposing. There is a function called >> drm_mode_expose_to_userspace() which only exposes stereo modes if >> user asks to. We could do something similar for 4:2:0 modes (or >> even for all pixel encoding). i.e. expose which encoding can be >> used in current video mode. What do you think? >> >> About drivers opting in for 4:2:0 modes, then you propose a new >> field in drm_connector (called for example ycbcr_420_allowed) >> which only does the parsing of the 4:2:0 modes and adds them to >> the list when set to true? > Thinking a bit more about this, we do have a slight problem with not > exposing this information to userspace. Namely we can't actually tell > whether any user provided mode would need to output as 4:2:0 or not. > With the new flag userspace could at least inherit that from the kernel > and pass it back in. But still, expanding the uapi for something like > this feels quite wrong to me. Can we simply look at a particular user > supplied mode and tell whether it needs to be output as 4:2:0 (based > on eg. dotclock)? > The pixel clock rate is half of the TMDS character rate in 4:2:0 (in 24 bit), but for example in deep color 48 bit it will be the same rate. There is also a reduction to half of htotal, hactive, hblank, hfront, hsync and hback but I don't think it's a good solution to guide us from there. Why does it feel wrong to you expanding the uapi? I think its important to say that the chosen colorspace can improve performance in systems: for example, as I said, 4:2:0 24-bit uses half the rate that RGB 24-bit uses so we have less trafic in the bus. I am recently working with a FPGA connected trough pcie and I can definitely say that this is true. But, as expected, less traffic means less quality in final image so its not a matter of letting kernel decide, I think its a matter of user choosing between performance vs. quality. Best regards, Jose Miguel Abreu _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
