[Mesa-dev] [PATCH 7/7] st/va: add headless support, i.e. VA_DISPLAY_DRM

Emil Velikov emil.l.velikov at gmail.com
Tue Oct 20 09:35:57 PDT 2015

On 20 October 2015 at 17:06, Julien Isorce <julien.isorce at gmail.com> wrote:
> On 19 October 2015 at 17:16, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 17 October 2015 at 00:14, Julien Isorce <julien.isorce at gmail.com>
>> wrote:
>> > This patch allows to use gallium vaapi without requiring
>> > a X server running for your second graphic card.
>> >
>> I've sent a lengthy series which should mitigate the need of some hunks.
> Ok I'll wait for your patches to land before going further on this patch.
> Should I expect vl_winsy_drm.c in your patches ? Not sure do understood that
> part. Actually I though about having "vl_screen_create_drm" and renames
> vl_screen_create to vl_screen_create_x11 (because it takes XDisplay in
> params) but then I got confused because vl_winsys.h includes Xlib.h. Should
> future vl_screen_create_drm be in another header, vl_drm.h ?
My series flattens the if GALLIUM_STATIC_TARGETS spaghetti. Although
it's more of a FYI rather than "wait until they land".

On the winsys_dri vs winsys_drm side - I'm not planning to do any work
there, neither I did notice the Xlib.h dependency in vl_winsys.h.

What I'm pondering is about having a 'proper' drm backend, although
admittedly I haven't looked exactly what libva{-intel-driver,}'s
definition of that is. I'd assume that moving the non-winsys specifics
(from vl_winsys_dri.c) to vl_winsys.h and adding a
vl_screen_texture_from_drawable() equivalent for drm (amongst others).
As you can tell much of this is guesswork, so if you don't have the
time and others are happy with the approach as is, feel free to


More information about the mesa-dev mailing list