On Thu, Jan 05, 2017 at 02:46:06PM +0000, Jose Abreu wrote: > 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. I was asking if we can look at a specific modeline and whether we can tell from that if we would need to output it as 4:2:0. > Why does it feel wrong to you > expanding the uapi? Because it requires changing every single userspace kms client. And it's not something userspace should have to worry about. > > 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. Image quality control for userspace is a much bigger topic. And something we have no real precedent for at the moment (apart from user choosing a different fb pixel format). The performance arument is very hardware dependent, and not really all that relevant IMO. If the user wants the big mode they either get it or not depending on whether the system can deliver. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
