On Wed, Feb 26, 2014 at 01:32:44PM +0000, Goel, Akash wrote: > To expose the panel fitter for arbitrary use by User-space, we will expose the manual scaling ratio & Input/Src size info to User, apart from the available scaling modes like Full screen, Centered, Aspect. > Please suggest that how shall we extend the current interface to incorporate these extra info, considering the options we have . > DRM_MODE_PROP_ENUM > DRM_MODE_PROP_RANGE > DRM_MODE_PROP_BITMASK > DRM_MODE_PROP_BLOB Either we should have two range properties (eg. crtc_width and crtc_height), or we could define a new property type that has both in the same value. Not sure if it's worth adding another type for this. Although we might be able to use such a type to reduce the number of properties a bit for planes and such (src and dst coordinages). The issue is that it limits the range a bit. Not a real issue for this case, but for plane src coordiantes we'd end up limit ourselves to 16.16 again, which may be a bit short sighted. And please, no scaling ratio property. Just explicit input and output sizes are better IMO. The output size should really be part of the mode as borders, but I'm not sure we want to be redefining the mode structure. I have no problem with the idea, but maybe other people are more reluctant. The alternative is to define the border through properties as well. We'd also need to figure out how to make this stuff cooperate decently with the way we deal with panel fixed modes currently. IMO ideally if the user specified the pfit stuff explicitly, we should really treat the display mode the user passed in as the adjusted_mode, and not just blindly overwrite it. This would also make it much easier to use cloning when one of the cloned displays has a fixed mode. Currently the user has no idea that the mode he passes in isn't what gets programmed into the timing generator, so other displays may not be able handle the mode even though it seemed perfectly valid from the user's perspective. I guess we could just add a new mode type flag to indicate the native mode of the display, but only in case where the display has a fixed mode (ie. it won't accept any input timings). Then userspace would know that if it wants to do cloning, it should check if any of the displays has a fixed mode, and use that for the timings. > > Best Regards > Akash > > -----Original Message----- > From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] > Sent: Thursday, February 20, 2014 1:41 PM > To: Ville Syrjälä > Cc: Goel, Akash; intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [Intel-gfx] Request for feedback : New Panel-fitter property for connectors > > On Wed, Feb 19, 2014 at 01:02:57PM +0200, Ville Syrjälä wrote: > > On Wed, Feb 19, 2014 at 09:33:11AM +0000, Goel, Akash wrote: > > > Thanks for your inputs. > > > > > > Actually for our use cases, the 'scaling_mode' property currently being used for 'lvds' & 'dp', cannot be used as it is. > > > > > > For our use cases, we need to provide a fine level control to User, so as to be able to choose the LetterBox/Pillar-box modes & also the Manual mode with horizontal & vertical scaling ratios. > > You can extend the current interface to add the extra modes (letter, pillarbox, and later the manual toggle). > > > > Please provide suggestions, that how we can extend/reuse the 'scaling_mode' property here. > > > > My plan is to somehow expose the panel fitter input and output sizes > > explicitly at some point. The output size could be expose by adding > > borders to the display mode structure (or some border properties if we > > don't want to change the user visible mode struct). And the input size > > could also be done via properties. > > Agreed, this is how we have talked about exposing the panel fitter for arbitrary use by userspace (such as overscan compensation). > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
