From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcus Lorentzon Subject: Re: [PATCH RFC 1/2] drm: add bitmask property type Date: Fri, 30 Mar 2012 13:00:43 +0200 Message-ID: <4F75925B.3040908@stericsson.com> References: <1333069366-2774-1-git-send-email-rob.clark@linaro.org> <20120330103723.GW4917@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eu1sys200aog115.obsmtp.com (eu1sys200aog115.obsmtp.com [207.126.144.139]) by gabe.freedesktop.org (Postfix) with ESMTP id 4D084A0BC0 for ; Fri, 30 Mar 2012 04:01:03 -0700 (PDT) In-Reply-To: <20120330103723.GW4917@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: =?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= Cc: Rob Clark , "patches@linaro.org" , "dri-devel@lists.freedesktop.org" , Rob Clark List-Id: dri-devel@lists.freedesktop.org On 03/30/2012 12:37 PM, Ville Syrj=E4l=E4 wrote: > On Thu, Mar 29, 2012 at 08:15:48PM -0500, Rob Clark wrote: >> On Thu, Mar 29, 2012 at 8:02 PM, Rob Clark wrote: >>> From: Rob Clark >>> >>> A bitmask property is similar to an enum. The enum value is a bit >>> position (0-63), and valid property values consist of a mask of >>> zero or more of (1<< enum_val[n]). >>> >>> TODO: word commit msg better >>> TODO: maybe "flags" would be a better name for the property type? >>> --- >>> See https://github.com/robclark/kernel-omap4/commit/970b7bb95993fc43b49= 77976bf8005dc2e1a4ad3#L6R411 >>> for an example usage. In this case combinations of "x-invert", "y-inve= rt" >>> and "xy-flip" can express all possible combinations of rotations of >>> multiples of 90 degrees plus mirroring. Which is sufficient for an >>> xrandr v1.2 rotation support. For arbitrary transforms in xrandr v1.3 >>> a different property with a transform matrix (if supported by the >>> driver) should be used. >> oh, and this shows the mapping between xrandr rotation/reflection mask >> and x-invert/y-invert/xy-flip: >> https://github.com/robclark/xf86-video-omap/commit/87ffbaf9d282831bf03da= 457e6f6c4e45a0d6b2b#L0R222 >> >> The other option is of course to make the rotation bitmask mirror the >> xrandr rotation mask values, which might be a better option to support >> drivers which only provide rotation and not mirroring. I'm ok with >> either option, whatever others prefer. > I would prefer something like that, but we shouldn't just blindly copy > the exact bit definitions. The xrandr reflection vs. rotation always > seemed to be backwards to me. To me it feels more natural to first > rotate, and then reflect/mirror. But it could be that I've just been > influenced by specific hardware designs. Exactly, and I would prefer a separate rotation (0,90,180,270) and = mirror (true,false) property. I see no reason to merge these using a = special bitmask property type. And if there is an issue with atomic commit of rotation and mirror, this = does not solve the general atomic commit issue. And if we solve that, we = don't need to merge two properties in one. > > Now that there seems to be a spur of activity in the property area, > could we come up with some way to better control what properties get > added, and how they're defined. Currently every driver is free to > define whatever ad-hoc properties they wish. > > I would suggest we either A) define some namespace for standard > properties, or B) introduce some new property mechanism that actually > uses integer property IDs. In either case new properties or changes to > existing standard properties should be carefully reviewed. I'm sort of > partial to option B, since doing a gazillion string comparisons when > pushing lots of properties to the driver seems like a pointless > waste of cycles. OTOH option A seems a little less revolutionary. > > In any case, the current mess just doesn't allow any kind of truly > generic user space code to be written. +1, I think a general mechanism for standard properties would be helpful = for applications that want to expose a dynamic interface with settings = supplied from kernel. Option A would be easy to add, but option B would make it easy to do = atomic commit with normal params and properties (as described in = previous email). So why not A+B? Add ids to make setting multiple = properties easier and add a name prefix. I assume these property names = are IDs and not something intended to be shown to the user directly = (i18n). And having standard property names would allow UI to include = translations for these properties. Non standard properties could just be = shown using their ID. /BR /Marcus