On Wed, Feb 26, 2014 at 01:32:44PM +0000, Goel, Akash wrote:
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.
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.
In VLV, we have to program PANEL fitter control register in terms of Auto/Manual/LetterBox/PillarBox modes, along with explicit scaling ratios, if Manual mode is used. Whereas for HSW, we program the PF register in terms of the display window size & its location. So the new interface should be such that this difference is handled seamlessly on Driver side and also it has to be used in conjunction with 'scaling_mode' property.
Can we expose the property where User can specify the Display Window size & its location, & based on that Driver will decide with which mode to program the Panel fitter. The SRC dimensions can be read from the PIPE_SRC register programmed earlier in the Mode set. This will fit directly into the HSW case, but for VLV a conversion will be needed.
The 'scaling_mode' property provides 3 Panel fitter modes. 1. Full Screen : Since the SRC image is to be shown on full screen , we may not need any other input from User for this mode. 2. Aspect Ratio : Here User wants to preserve the Aspect ratio of SRC, but here Driver currently on its own decides that whether the Letterboxing or Pillar boxing is required. Here probably there is a scope of input from User side, where it can specify both the horizontal & vertical borders in Display window. 3. Centered : Here User wants to show up the SRC image in the middle of the screen, here also same input of horizontal & vertical borders in Display window could be accepted from User.
Best Regards Akash
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Wednesday, February 26, 2014 7:28 PM To: Goel, Akash Cc: Chris Wilson; intel-gfx@lists.freedesktop.org; G, Pallavi; Kannan, Vandana; dri-devel@lists.freedesktop.org Subject: Re: [Intel-gfx] Request for feedback : New Panel-fitter property for connectors
On Wed, Feb 26, 2014 at 01:32:44PM +0000, Goel, Akash wrote:
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.
-- Ville Syrjälä Intel OTC
On Wed, Feb 26, 2014 at 03:58:27PM +0200, Ville Syrjälä wrote:
One thing on top of Ville's comments:
pfit should get moved to the crtc if we want to expose it generally. On ilk-bdw we have per-pipe scalers, and those might be really useful for e.g. upscaling video to an external screen. With atomic modeset there shouldn't be any flicker involved really, if we get it right. -Daniel
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Goel, Akash -
Ville Syrjälä