On Wed, Nov 19, 2014 at 3:24 PM, Rian Quinn <rianquinn@xxxxxxxxx> wrote:
> I am in the process of implementing the plane support now on the i915, and I
> ran into an issue that doesn't make much sense to me. When I call
> drmModeSetPlane, I get an "Invalid Argument" (which is always so helpful).
> Turning on DRM debugging, I was able to trace into the kernel where the
> problem was:
>
> if (src_w > 2048 || src_h > 2048 || width_bytes > 4096 || fb->pitches[0] >
> 4096) { DRM_DEBUG_KMS("Source dimensions exceed hardware limits\n"); return
> -EINVAL; }
+ intel-gfx
I'm not really sure if that 4k pitch limit is real or not.. it is at
least intel specific..
BR,
-R
> I then checked all of the variables, and the one that is failing is the
> pitch. Basically, if I allocate a dumb buffer greater than 1024,768 I get a
> pitch that is greater than 4096, which then of course gives me this error. I
> was able to validate this as once I set the dumb buffer size to 1024,768, it
> works fine, anything larger fails.
>
> Am I missing something? If I read this code correctly, the largest buffer
> width that is supported is 1024 (assuming 32bpp). If that's the case, it's
> not very helpful.
>
> Thanks a ton BTW.
> - Rian
>
> On Tue, Nov 11, 2014 at 8:50 PM, Rob Clark <robdclark@xxxxxxxxx> wrote:
>>
>> On Tue, Nov 11, 2014 at 8:40 PM, Rian Quinn <rianquinn@xxxxxxxxx> wrote:
>> > Right now I need to support Intel and AMD, and nVidia would be a great
>> > plus with VMWare being my sudo dev/test environment on travel. I have
>> > control of the kernel so it’s whatever I need.
>> >
>> > Can you point me to the “atomic-helpers” stuff. I have never heard of
>> > that. Is that exposed via LibDRM?
>> >
>>
>> well, right now, it is a pull-req for 3.19
>>
>> (http://lists.freedesktop.org/archives/dri-devel/2014-November/071623.html)
>> and ongoing driver work.. new userspace API or libdrm bits are not in
>> place yet, but hopefully following in next kernel version or two. I'd
>> expect support earlier for i915 and various other SoC hw.
>>
>> For now, for hw which advertises plane support (I think some
>> generations for i915 and nouveau? not really sure offhand about
>> radeon) you could use an overlay plane in addition to dummy crtc
>> scanout fb.
>>
>> BR,
>> -R
>>
>> > Thanks,
>> > - Rian
>> >
>> >> On Nov 11, 2014, at 8:35 PM, Rob Clark <robdclark@xxxxxxxxx> wrote:
>> >>
>> >> On Tue, Nov 11, 2014 at 8:25 PM, Rian Quinn <rianquinn@xxxxxxxxx>
>> >> wrote:
>> >>> Yeah, I had issues trying to get the first method to work across the
>> >>> board on all of the hardware that we need to support. One example that I saw
>> >>> was to use the second method, and then to use planes when you had to scale.
>> >>> So basically, if you could not find a match, you would select the lowest of
>> >>> the resolutions, and then setup planes for the ones that need to be scaled.
>> >>> From what I can see, this will end up consuming an extra frame buffer, but
>> >>> it takes care of the issue.
>> >>>
>> >>> Do you see any issues with that approach?
>> >>>
>> >>
>> >> This is basically a recent approach (meaning not necessarily supported
>> >> by all drivers, etc).. with the primary-plane feature you could even
>> >> configure the primary scanout layer via the plane API (but, keep in
>> >> mind, scaling is not something all hw supports). The new
>> >> 'atomic-helpers' stuff should help with exposing support for hw that
>> >> can do scaling on primary layer.
>> >>
>> >> So in the end, it depends on what hw, and what kernel versions, you
>> >> need to support. You may need to fallback to cropping without scaling
>> >> if you need to support everything. But one of the goals with the
>> >> 'atomic' work is to make it easier to expose scaling support on hw
>> >> that can do it.
>> >>
>> >>> Thanks,
>> >>> - Rian
>> >>>
>> >>>> On Nov 11, 2014, at 8:10 PM, Rob Clark <robdclark@xxxxxxxxx> wrote:
>> >>>>
>> >>>> On Tue, Nov 11, 2014 at 12:19 PM, Rian Quinn <rianquinn@xxxxxxxxx>
>> >>>> wrote:
>> >>>>> What exactly is the correct way to support cloned monitors using
>> >>>>> LibDRM. As
>> >>>>> I see it, there are two methods:
>> >>>>>
>> >>>>> - Use the connector array in drmModeSetCrtc
>> >>>>> - Use one crtc per connector, but share the same framebuffer.
>> >>>>>
>> >>>>> Right now I am using option #2 as it seems to be the most flexible,
>> >>>>> but my
>> >>>>> current issue is that on laptops, the connector for the laptop's
>> >>>>> main screen
>> >>>>> is only retuning 1 mode (tested on a Lenovo, and an HP folio), which
>> >>>>> means
>> >>>>> that your unlikely to find a common mode between the laptop monitor,
>> >>>>> and an
>> >>>>> external screen (monitor or projector).
>> >>>>
>> >>>> #2 is the method that will work on all hw.. usually DE's will pick
>> >>>> the closest matching modes between the two connectors/outputs, and
>> >>>> truncate edges on the smaller display (via non-zero x/y offset).
>> >>>> Some
>> >>>> hw may support upscaling to fit, although that isn't really exposed
>> >>>> in
>> >>>> a completely standard way at the moment.
>> >>>>
>> >>>> BR,
>> >>>> -R
>> >>>>
>> >>>>> So with the above problem, right now the only thing that I know to
>> >>>>> do would
>> >>>>> be to set the resolution of the laptop monitor and external monitor
>> >>>>> to be
>> >>>>> their "preferred" resolution, and then copy and scale for "cloned
>> >>>>> mode"
>> >>>>> which seems like a terrible idea considering the laptop monitor
>> >>>>> should be
>> >>>>> able to set itself to some more basic resolutions (like 800x600).
>> >>>>>
>> >>>>> - Rian
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> dri-devel mailing list
>> >>>>> dri-devel@xxxxxxxxxxxxxxxxxxxxx
>> >>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >>>>>
>> >>>
>> >
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
