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 >>>>> >>> > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
