All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sharma, Shashank" <shashank.sharma@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>,
	"Jia, Lin A" <lin.a.jia@intel.com>,
	"Sharma, Akashdeep" <akashdeep.sharma@intel.com>,
	Emil Velikov <emil.l.velikov@gmail.com>,
	dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Jim Bride <jim.bride@linux.intel.com>
Subject: Re: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
Date: Thu, 3 Nov 2016 19:04:37 +0530	[thread overview]
Message-ID: <ed4ae38f-43dc-5f80-a4d0-4d1d786b2857@intel.com> (raw)
In-Reply-To: <20161103132616.GQ4617@intel.com>

Regards

Shashank


On 11/3/2016 6:56 PM, Ville Syrjälä wrote:
> On Thu, Nov 03, 2016 at 06:40:11PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/3/2016 6:32 PM, Ville Syrjälä wrote:
>>> On Thu, Nov 03, 2016 at 12:47:39PM +0000, Sharma, Shashank wrote:
>>>> Hi Ville,
>>>> (-dri-devel)
>>>> I would appreciate an internal discussion before going to dri-devel. a
>>> Added back. Private discussions are pointless.
>> Noted.
>>>> What did this patch break ?
>>> Intel ddx. It will reject any mode with flags it doesn't know about.
>>> Other ddxen like -ati or -modesetting will also suffer, but potentially
>>> in a different way since they don't even check the flags and instead
>>> just directly stuff them into the randr mode flags, which will result
>>> in an out of spec mode as far randr is concerned.
>> Then its a fault of intel-ddx design. We are adding new flags to
>> indicate aspect ratios, so its obvious that the implementation should be
>> modified to accept new flags.
>> I dont see why you should revert patch for it.
> Rule 1 of kernel development: You simply don't break existing userspace
Again, we are adding something new, for which userspace should be modified.
If the userspace in written in such a way that it wont accept changes, 
its not saleable design.

Even in this case, we should go and extend the userspace (which I am 
ready to do) instead of reverting the patch.
If you still think you should send this revert, I am removing my NACK. 
Pls Go ahead.
>>>> This is exposed in the same way, as the 3D flags.
>>> Not it isn't. We have a client cap for 3D flags.
>>>
>>>> The information is already available in form of flags, all you have to do in userspace is read and print that. Its already being done in Android.
>>> Please stop relying on Android for testing upstream patches. Test with
>>> actual userspace people are using.
>> Please note that android goes through HDMI compliance certification, and
>> several commercial test infrastructures, so
>> that's one of the best infrastructure to test. And when we have common
>> branch for all of Linux flavors, we should consider all.
> You can test with Android as much as you like. That probably won't
> catch ABI breaks and whatnot though since you don't generally just plop
> a new kernel onto an existing Android device.
>
> So you really must test with normal userspace as well. That has a long
> history and so any ABI/behaviour change is actually a big deal.
>
>>>>    
>>>> NACK until we get to the right reason.
>>>>
>>>> Regards
>>>> Shashank
>>>> -----Original Message-----
>>>> From: ville.syrjala@linux.intel.com [mailto:ville.syrjala@linux.intel.com]
>>>> Sent: Thursday, November 3, 2016 6:02 PM
>>>> To: dri-devel@lists.freedesktop.org
>>>> Cc: Sharma, Shashank <shashank.sharma@intel.com>; Lin; Jia, Lin A <lin.a.jia@intel.com>; Sharma, Akashdeep <akashdeep.sharma@intel.com>; Jim Bride <jim.bride@linux.intel.com>; Jose Abreu <Jose.Abreu@synopsys.com>; Daniel Vetter <daniel.vetter@ffwll.ch>; Emil Velikov <emil.l.velikov@gmail.com>
>>>> Subject: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
>>>>
>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>
>>>> This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.
>>>>
>>>> Adding new mode flags willy nilly breaks existing userspace. We need to coordinate this better, potentially with a new client cap that only exposes the aspect ratio flags when userspace is prepared for them (similar to what we do with stereo 3D modes).
>>>>
>>>> Cc: Shashank Sharma <shashank.sharma@intel.com>
>>>> Cc: Lin, Jia <lin.a.jia@intel.com>
>>>> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com>
>>>> Cc: Jim Bride <jim.bride@linux.intel.com>
>>>> Cc: Jose Abreu <Jose.Abreu@synopsys.com>
>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>> Cc: Emil Velikov <emil.l.velikov@gmail.com>
>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>> ---
>>>>    drivers/gpu/drm/drm_modes.c | 12 ------------  include/uapi/drm/drm_mode.h |  6 ------
>>>>    2 files changed, 18 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index f64ac86deb84..725faa6409aa 100644
>>>> --- a/drivers/gpu/drm/drm_modes.c
>>>> +++ b/drivers/gpu/drm/drm_modes.c
>>>> @@ -1513,12 +1513,6 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,
>>>>    	case HDMI_PICTURE_ASPECT_16_9:
>>>>    		out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
>>>>    		break;
>>>> -	case HDMI_PICTURE_ASPECT_64_27:
>>>> -		out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
>>>> -		break;
>>>> -	case DRM_MODE_PICTURE_ASPECT_256_135:
>>>> -		out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
>>>> -		break;
>>>>    	case HDMI_PICTURE_ASPECT_RESERVED:
>>>>    	default:
>>>>    		out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; @@ -1580,12 +1574,6 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
>>>>    	case DRM_MODE_FLAG_PIC_AR_16_9:
>>>>    		out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
>>>>    		break;
>>>> -	case DRM_MODE_FLAG_PIC_AR_64_27:
>>>> -		out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
>>>> -		break;
>>>> -	case DRM_MODE_FLAG_PIC_AR_256_135:
>>>> -		out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
>>>> -		break;
>>>>    	default:
>>>>    		out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>>>>    		break;
>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 084b50a02dc5..5c142b1387ac 100644
>>>> --- a/include/uapi/drm/drm_mode.h
>>>> +++ b/include/uapi/drm/drm_mode.h
>>>> @@ -81,8 +81,6 @@ extern "C" {
>>>>    #define DRM_MODE_PICTURE_ASPECT_NONE		0
>>>>    #define DRM_MODE_PICTURE_ASPECT_4_3		1
>>>>    #define DRM_MODE_PICTURE_ASPECT_16_9		2
>>>> -#define DRM_MODE_PICTURE_ASPECT_64_27		3
>>>> -#define DRM_MODE_PICTURE_ASPECT_256_135		4
>>>>    
>>>>    /* Aspect ratio flag bitmask (4 bits 22:19) */
>>>>    #define DRM_MODE_FLAG_PIC_AR_MASK		(0x0F<<19)
>>>> @@ -92,10 +90,6 @@ extern "C" {
>>>>    			(DRM_MODE_PICTURE_ASPECT_4_3<<19)
>>>>    #define  DRM_MODE_FLAG_PIC_AR_16_9 \
>>>>    			(DRM_MODE_PICTURE_ASPECT_16_9<<19)
>>>> -#define  DRM_MODE_FLAG_PIC_AR_64_27 \
>>>> -			(DRM_MODE_PICTURE_ASPECT_64_27<<19)
>>>> -#define  DRM_MODE_FLAG_PIC_AR_256_135 \
>>>> -			(DRM_MODE_PICTURE_ASPECT_256_135<<19)
>>>>    
>>>>    /* DPMS flags */
>>>>    /* bit compatible with the xorg definitions. */
>>>> --
>>>> 2.7.4
>>>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-11-03 13:34 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-03 12:31 [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer" ville.syrjala
2016-11-03 12:31 ` [PATCH 2/2] Revert "drm: Add aspect ratio parsing " ville.syrjala
2016-11-03 12:47   ` Sharma, Shashank
     [not found] ` <FF3DDC77922A8A4BB08A3BC48A1EA8CB411AE158@BGSMSX101.gar.corp.intel.com>
     [not found]   ` <20161103130253.GM4617@intel.com>
2016-11-03 13:04     ` [PATCH 1/2] Revert "drm: Add and handle new aspect ratios " Ville Syrjälä
2016-11-03 13:09       ` Ville Syrjälä
2016-11-03 13:22         ` Sharma, Shashank
     [not found]     ` <2ededbc1-b923-200e-8443-f1ee522402bf@intel.com>
2016-11-03 13:26       ` Ville Syrjälä
2016-11-03 13:34         ` Sharma, Shashank [this message]
2016-11-03 13:49           ` Ville Syrjälä
2016-11-03 16:03             ` Daniel Vetter
2016-11-03 16:19               ` Sharma, Shashank
2016-11-07  7:43                 ` Sharma, Shashank
2016-11-07 15:26                   ` Emil Velikov
2016-11-07 15:48                     ` Sharma, Shashank
2016-11-07 16:57                       ` Emil Velikov
2016-11-03 16:02   ` Daniel Vetter
2016-11-11 17:00 ` Ville Syrjälä
2016-11-11 17:03   ` Ville Syrjälä
2016-11-11 17:07   ` Alex Deucher
2016-11-11 17:08     ` Daniel Vetter
2016-11-11 17:22     ` Ville Syrjälä
2016-11-14 14:44   ` Sharma, Shashank
2016-11-14 15:49     ` Ville Syrjälä
2016-11-14 16:07       ` Sharma, Shashank
2016-11-14 16:20         ` Ville Syrjälä
2016-11-14 16:42           ` Sharma, Shashank
2016-11-14 16:45             ` Ville Syrjälä
2016-11-14 16:56               ` Sharma, Shashank
2016-11-15  8:51                 ` Daniel Vetter
2016-11-15  9:00                   ` Sharma, Shashank
2016-11-15 10:00                     ` Daniel Vetter
2016-11-15 10:06                       ` Sharma, Shashank
2016-11-15 10:52                         ` Daniel Vetter
2016-11-15 13:48                           ` Jose Abreu
2016-11-15 14:18                             ` Ville Syrjälä
2016-11-15 15:10                               ` Sharma, Shashank
2016-11-15 15:18                                 ` Ville Syrjälä
2016-11-15 15:13                               ` Sharma, Shashank
2016-11-15 13:54                       ` Ville Syrjälä
2016-11-15 14:03                         ` Daniel Vetter
2016-11-15 14:18                           ` Alex Deucher
2016-11-15 14:24                             ` Ville Syrjälä
2016-11-15 14:26                             ` Daniel Vetter
2016-11-15 15:26                               ` Alex Deucher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ed4ae38f-43dc-5f80-a4d0-4d1d786b2857@intel.com \
    --to=shashank.sharma@intel.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=akashdeep.sharma@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=jim.bride@linux.intel.com \
    --cc=lin.a.jia@intel.com \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.