[PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[Ибрагимов Ринат]

libvdpau uses second DRI driver name to determine which VDPAU driver
to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
it would be convenient to have this driver selection working without manual
driver selection.

Signed-off-by: Rinat <ibragimovrinat@mail.ru>
---
 src/sna/sna_dri.c   |    5 +++--
 src/uxa/intel_dri.c |    5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/sna/sna_dri.c b/src/sna/sna_dri.c
index 1569251..0ba373d 100644
--- a/src/sna/sna_dri.c
+++ b/src/sna/sna_dri.c
@@ -2299,7 +2299,7 @@ bool sna_dri_open(struct sna *sna, ScreenPtr screen)
 	DRI2InfoRec info;
 	int major = 1, minor = 0;
 #if DRI2INFOREC_VERSION >= 4
-	const char *driverNames[1];
+	const char *driverNames[2];
 #endif
 
 	DBG(("%s()\n", __FUNCTION__));
@@ -2336,9 +2336,10 @@ bool sna_dri_open(struct sna *sna, ScreenPtr screen)
 	info.ScheduleSwap = sna_dri_schedule_swap;
 	info.GetMSC = sna_dri_get_msc;
 	info.ScheduleWaitMSC = sna_dri_schedule_wait_msc;
-	info.numDrivers = 1;
+	info.numDrivers = 2;
 	info.driverNames = driverNames;
 	driverNames[0] = info.driverName;
+	driverNames[1] = info.driverName;
 #endif
 
 #if DRI2INFOREC_VERSION >= 6
diff --git a/src/uxa/intel_dri.c b/src/uxa/intel_dri.c
index 0370034..2d33380 100644
--- a/src/uxa/intel_dri.c
+++ b/src/uxa/intel_dri.c
@@ -1553,7 +1553,7 @@ Bool I830DRI2ScreenInit(ScreenPtr screen)
 	int dri2_major = 1;
 	int dri2_minor = 0;
 #if DRI2INFOREC_VERSION >= 4
-	const char *driverNames[1];
+	const char *driverNames[2];
 #endif
 
 	if (intel->force_fallback) {
@@ -1620,9 +1620,10 @@ Bool I830DRI2ScreenInit(ScreenPtr screen)
 	info.ScheduleSwap = I830DRI2ScheduleSwap;
 	info.GetMSC = I830DRI2GetMSC;
 	info.ScheduleWaitMSC = I830DRI2ScheduleWaitMSC;
-	info.numDrivers = 1;
+	info.numDrivers = 2;
 	info.driverNames = driverNames;
 	driverNames[0] = info.driverName;
+	driverNames[1] = info.driverName;
 #endif
 
 	return DRI2ScreenInit(screen, &info);
-- 
1.7.10.4

Re: [PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[Rinat Ibragimov]

Ping.

Пятница, 16 августа 2013, 14:31 +04:00 от Ибрагимов Ринат<ibragimovrinat@mail.ru>:
> libvdpau uses second DRI driver name to determine which VDPAU driver
> to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
> I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
> it would be convenient to have this driver selection working without manual
> driver selection.
> 
> Signed-off-by: Rinat <ibragimovrinat@mail.ru>
> ---
>  src/sna/sna_dri.c   |    5 +++--
>  src/uxa/intel_dri.c |    5 +++--
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/src/sna/sna_dri.c b/src/sna/sna_dri.c
> index 1569251..0ba373d 100644
> --- a/src/sna/sna_dri.c
> +++ b/src/sna/sna_dri.c
> @@ -2299,7 +2299,7 @@ bool sna_dri_open(struct sna *sna, ScreenPtr screen)
>  	DRI2InfoRec info;
>  	int major = 1, minor = 0;
>  #if DRI2INFOREC_VERSION >= 4
> -	const char *driverNames[1];
> +	const char *driverNames[2];
>  #endif
>  
>  	DBG(("%s()\n", __FUNCTION__));
> @@ -2336,9 +2336,10 @@ bool sna_dri_open(struct sna *sna, ScreenPtr screen)
>  	info.ScheduleSwap = sna_dri_schedule_swap;
>  	info.GetMSC = sna_dri_get_msc;
>  	info.ScheduleWaitMSC = sna_dri_schedule_wait_msc;
> -	info.numDrivers = 1;
> +	info.numDrivers = 2;
>  	info.driverNames = driverNames;
>  	driverNames[0] = info.driverName;
> +	driverNames[1] = info.driverName;
>  #endif
>  
>  #if DRI2INFOREC_VERSION >= 6
> diff --git a/src/uxa/intel_dri.c b/src/uxa/intel_dri.c
> index 0370034..2d33380 100644
> --- a/src/uxa/intel_dri.c
> +++ b/src/uxa/intel_dri.c
> @@ -1553,7 +1553,7 @@ Bool I830DRI2ScreenInit(ScreenPtr screen)
>  	int dri2_major = 1;
>  	int dri2_minor = 0;
>  #if DRI2INFOREC_VERSION >= 4
> -	const char *driverNames[1];
> +	const char *driverNames[2];
>  #endif
>  
>  	if (intel->force_fallback) {
> @@ -1620,9 +1620,10 @@ Bool I830DRI2ScreenInit(ScreenPtr screen)
>  	info.ScheduleSwap = I830DRI2ScheduleSwap;
>  	info.GetMSC = I830DRI2GetMSC;
>  	info.ScheduleWaitMSC = I830DRI2ScheduleWaitMSC;
> -	info.numDrivers = 1;
> +	info.numDrivers = 2;
>  	info.driverNames = driverNames;
>  	driverNames[0] = info.driverName;
> +	driverNames[1] = info.driverName;
>  #endif
>  
>  	return DRI2ScreenInit(screen, &info);
> -- 
> 1.7.10.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

---
Rinat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[Rinat Ibragimov]

Ping.


Пятница, 16 августа 2013, 14:31 +04:00 от Ибрагимов Ринат<ibragimovrinat@mail.ru>:
> libvdpau uses second DRI driver name to determine which VDPAU driver
> to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
> I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
> it would be convenient to have this driver selection working without manual
> driver selection.
> 
> Signed-off-by: Rinat <ibragimovrinat@mail.ru>
> ---
>  src/sna/sna_dri.c   |    5 +++--
>  src/uxa/intel_dri.c |    5 +++--
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/src/sna/sna_dri.c b/src/sna/sna_dri.c
> index 1569251..0ba373d 100644
> --- a/src/sna/sna_dri.c
> +++ b/src/sna/sna_dri.c
> @@ -2299,7 +2299,7 @@ bool sna_dri_open(struct sna *sna, ScreenPtr screen)
>  	DRI2InfoRec info;
>  	int major = 1, minor = 0;
>  #if DRI2INFOREC_VERSION >= 4
> -	const char *driverNames[1];
> +	const char *driverNames[2];
>  #endif
>  
>  	DBG(("%s()\n", __FUNCTION__));
> @@ -2336,9 +2336,10 @@ bool sna_dri_open(struct sna *sna, ScreenPtr screen)
>  	info.ScheduleSwap = sna_dri_schedule_swap;
>  	info.GetMSC = sna_dri_get_msc;
>  	info.ScheduleWaitMSC = sna_dri_schedule_wait_msc;
> -	info.numDrivers = 1;
> +	info.numDrivers = 2;
>  	info.driverNames = driverNames;
>  	driverNames[0] = info.driverName;
> +	driverNames[1] = info.driverName;
>  #endif
>  
>  #if DRI2INFOREC_VERSION >= 6
> diff --git a/src/uxa/intel_dri.c b/src/uxa/intel_dri.c
> index 0370034..2d33380 100644
> --- a/src/uxa/intel_dri.c
> +++ b/src/uxa/intel_dri.c
> @@ -1553,7 +1553,7 @@ Bool I830DRI2ScreenInit(ScreenPtr screen)
>  	int dri2_major = 1;
>  	int dri2_minor = 0;
>  #if DRI2INFOREC_VERSION >= 4
> -	const char *driverNames[1];
> +	const char *driverNames[2];
>  #endif
>  
>  	if (intel->force_fallback) {
> @@ -1620,9 +1620,10 @@ Bool I830DRI2ScreenInit(ScreenPtr screen)
>  	info.ScheduleSwap = I830DRI2ScheduleSwap;
>  	info.GetMSC = I830DRI2GetMSC;
>  	info.ScheduleWaitMSC = I830DRI2ScheduleWaitMSC;
> -	info.numDrivers = 1;
> +	info.numDrivers = 2;
>  	info.driverNames = driverNames;
>  	driverNames[0] = info.driverName;
> +	driverNames[1] = info.driverName;
>  #endif
>  
>  	return DRI2ScreenInit(screen, &info);
> -- 
> 1.7.10.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

---
Rinat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 912 bytes --]

Ибрагимов Ринат <ibragimovrinat@mail.ru> writes:

> libvdpau uses second DRI driver name to determine which VDPAU driver
> to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
> I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
> it would be convenient to have this driver selection working without manual
> driver selection.

If it's a generic driver, why would it need a "i965" string passed over
the DRI2 protocol to find it?

One of the things I'm planning on doing is removing use of the
protocol-provided DRI2 driver name from Mesa -- Mesa knows what drivers
it has built, and it knows how to detect those devices (in the EGL
code), so why would we pay attention to what the X Server thinks our
driver's name is?  Seems like vdpau could probably do the same.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[Rinat Ibragimov]

Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt <eric@anholt.net>:
> Ибрагимов Ринат <ibragimovrinat@mail.ru> writes:
> 
> > libvdpau uses second DRI driver name to determine which VDPAU driver
> > to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> > with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
> > I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
> > it would be convenient to have this driver selection working without manual
> > driver selection.
> 
> If it's a generic driver, why would it need a "i965" string passed over
> the DRI2 protocol to find it?

It doesn't actually. It's just to simplify distribution package management.
If one names driver libvdpau_nvidia.so.1, it will break VDPAU on
nVidia equipped machines. With this patch one can name it
libvdpau_i965.so.1 and driver will be loaded on intel equipped
machines only.

> 
> One of the things I'm planning on doing is removing use of the
> protocol-provided DRI2 driver name from Mesa -- Mesa knows what drivers
> it has built, and it knows how to detect those devices (in the EGL
> code), so why would we pay attention to what the X Server thinks our
> driver's name is?  Seems like vdpau could probably do the same.
> 

VDPAU uses entry point library (libvdpau) which loads backend drivers.
libvdpau uses second DRI2 driver name amongst other methods to determine
which driver to load. It can not rely on Mesa's internal knowledge, because
it must work with proprietary nVidia driver too.

---
Rinat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 1938 bytes --]

Rinat Ibragimov <ibragimovrinat@mail.ru> writes:

> Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt <eric@anholt.net>:
>> Ибрагимов Ринат <ibragimovrinat@mail.ru> writes:
>> 
>> > libvdpau uses second DRI driver name to determine which VDPAU driver
>> > to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
>> > with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
>> > I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
>> > it would be convenient to have this driver selection working without manual
>> > driver selection.
>> 
>> If it's a generic driver, why would it need a "i965" string passed over
>> the DRI2 protocol to find it?
>
> It doesn't actually. It's just to simplify distribution package management.
> If one names driver libvdpau_nvidia.so.1, it will break VDPAU on
> nVidia equipped machines. With this patch one can name it
> libvdpau_i965.so.1 and driver will be loaded on intel equipped
> machines only.
>
>> 
>> One of the things I'm planning on doing is removing use of the
>> protocol-provided DRI2 driver name from Mesa -- Mesa knows what drivers
>> it has built, and it knows how to detect those devices (in the EGL
>> code), so why would we pay attention to what the X Server thinks our
>> driver's name is?  Seems like vdpau could probably do the same.
>> 
>
> VDPAU uses entry point library (libvdpau) which loads backend drivers.
> libvdpau uses second DRI2 driver name amongst other methods to determine
> which driver to load. It can not rely on Mesa's internal knowledge, because
> it must work with proprietary nVidia driver too.

Right, I meant "couldn't libvdpau have a method to determine which
driver to load based on looking at your hardware, like how Mesa's EGL
does?", since only libvdpau is likely to know how pieces of hardware map
to driver binaries.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[Rinat Ibragimov]

Понедельник, 26 августа 2013, 16:22 -07:00 от Eric Anholt <eric@anholt.net>:
> Rinat Ibragimov <ibragimovrinat@mail.ru> writes:
> 
> > Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt <eric@anholt.net>:
> >> Ибрагимов Ринат <ibragimovrinat@mail.ru> writes:
> >> 
> >> > libvdpau uses second DRI driver name to determine which VDPAU driver
> >> > to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> >> > with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
> >> > I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
> >> > it would be convenient to have this driver selection working without manual
> >> > driver selection.
> >> 
> >> If it's a generic driver, why would it need a "i965" string passed over
> >> the DRI2 protocol to find it?
> >
> > It doesn't actually. It's just to simplify distribution package management.
> > If one names driver libvdpau_nvidia.so.1, it will break VDPAU on
> > nVidia equipped machines. With this patch one can name it
> > libvdpau_i965.so.1 and driver will be loaded on intel equipped
> > machines only.
> >
> >> 
> >> One of the things I'm planning on doing is removing use of the
> >> protocol-provided DRI2 driver name from Mesa -- Mesa knows what drivers
> >> it has built, and it knows how to detect those devices (in the EGL
> >> code), so why would we pay attention to what the X Server thinks our
> >> driver's name is?  Seems like vdpau could probably do the same.
> >> 
> >
> > VDPAU uses entry point library (libvdpau) which loads backend drivers.
> > libvdpau uses second DRI2 driver name amongst other methods to determine
> > which driver to load. It can not rely on Mesa's internal knowledge, because
> > it must work with proprietary nVidia driver too.
> 
> Right, I meant "couldn't libvdpau have a method to determine which
> driver to load based on looking at your hardware, like how Mesa's EGL
> does?", since only libvdpau is likely to know how pieces of hardware map
> to driver binaries.
> 

VDPAU drivers have separate code from libvdpau, while Mesa have drivers
inside it (if I get it right). I can't figure out how libvdpau beeing separate
can determine mapping between hardware and driver to load. The only way
is to ask[1] DRI2.


[1] http://cgit.freedesktop.org/~aplattner/libvdpau/tree/src/vdpau_wrapper.c#n104
---
Rinat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 2905 bytes --]

Rinat Ibragimov <ibragimovrinat@mail.ru> writes:

> Понедельник, 26 августа 2013, 16:22 -07:00 от Eric Anholt <eric@anholt.net>:
>> Rinat Ibragimov <ibragimovrinat@mail.ru> writes:
>> 
>> > Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt <eric@anholt.net>:
>> >> Ибрагимов Ринат <ibragimovrinat@mail.ru> writes:
>> >> 
>> >> > libvdpau uses second DRI driver name to determine which VDPAU driver
>> >> > to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
>> >> > with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
>> >> > I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
>> >> > it would be convenient to have this driver selection working without manual
>> >> > driver selection.
>> >> 
>> >> If it's a generic driver, why would it need a "i965" string passed over
>> >> the DRI2 protocol to find it?
>> >
>> > It doesn't actually. It's just to simplify distribution package management.
>> > If one names driver libvdpau_nvidia.so.1, it will break VDPAU on
>> > nVidia equipped machines. With this patch one can name it
>> > libvdpau_i965.so.1 and driver will be loaded on intel equipped
>> > machines only.
>> >
>> >> 
>> >> One of the things I'm planning on doing is removing use of the
>> >> protocol-provided DRI2 driver name from Mesa -- Mesa knows what drivers
>> >> it has built, and it knows how to detect those devices (in the EGL
>> >> code), so why would we pay attention to what the X Server thinks our
>> >> driver's name is?  Seems like vdpau could probably do the same.
>> >> 
>> >
>> > VDPAU uses entry point library (libvdpau) which loads backend drivers.
>> > libvdpau uses second DRI2 driver name amongst other methods to determine
>> > which driver to load. It can not rely on Mesa's internal knowledge, because
>> > it must work with proprietary nVidia driver too.
>> 
>> Right, I meant "couldn't libvdpau have a method to determine which
>> driver to load based on looking at your hardware, like how Mesa's EGL
>> does?", since only libvdpau is likely to know how pieces of hardware map
>> to driver binaries.
>> 
>
> VDPAU drivers have separate code from libvdpau, while Mesa have drivers
> inside it (if I get it right). I can't figure out how libvdpau beeing separate
> can determine mapping between hardware and driver to load. The only way
> is to ask[1] DRI2.

Yet the Xorg 2D driver is even less related to the set of vdpau drivers
available than the vdpau driver loader (which could do things like look
at a symbol in the driver to find a probing mechanism, like the X Server
does to X drivers, or read some config directory containing mappings
installed by the external drivers).

The reason I'm making a point of this is that DRI3 is dropping the
driver name strings from the protocol.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[Rinat Ibragimov]

Среда, 28 августа 2013, 16:26 -07:00 от Eric Anholt <eric@anholt.net>:
> Rinat Ibragimov <ibragimovrinat@mail.ru> writes:
> 
> > Понедельник, 26 августа 2013, 16:22 -07:00 от Eric Anholt <eric@anholt.net>:
> >> Rinat Ibragimov <ibragimovrinat@mail.ru> writes:
> >> 
> >> > Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt <eric@anholt.net>:
> >> >> Ибрагимов Ринат <ibragimovrinat@mail.ru> writes:
> >> >> 
> >> >> > libvdpau uses second DRI driver name to determine which VDPAU driver
> >> >> > to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> >> >> > with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
> >> >> > I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
> >> >> > it would be convenient to have this driver selection working without manual
> >> >> > driver selection.
> >> >> 
> >> >> If it's a generic driver, why would it need a "i965" string passed over
> >> >> the DRI2 protocol to find it?
> >> >
> >> > It doesn't actually. It's just to simplify distribution package management.
> >> > If one names driver libvdpau_nvidia.so.1, it will break VDPAU on
> >> > nVidia equipped machines. With this patch one can name it
> >> > libvdpau_i965.so.1 and driver will be loaded on intel equipped
> >> > machines only.
> >> >
> >> >> 
> >> >> One of the things I'm planning on doing is removing use of the
> >> >> protocol-provided DRI2 driver name from Mesa -- Mesa knows what drivers
> >> >> it has built, and it knows how to detect those devices (in the EGL
> >> >> code), so why would we pay attention to what the X Server thinks our
> >> >> driver's name is?  Seems like vdpau could probably do the same.
> >> >> 
> >> >
> >> > VDPAU uses entry point library (libvdpau) which loads backend drivers.
> >> > libvdpau uses second DRI2 driver name amongst other methods to determine
> >> > which driver to load. It can not rely on Mesa's internal knowledge, because
> >> > it must work with proprietary nVidia driver too.
> >> 
> >> Right, I meant "couldn't libvdpau have a method to determine which
> >> driver to load based on looking at your hardware, like how Mesa's EGL
> >> does?", since only libvdpau is likely to know how pieces of hardware map
> >> to driver binaries.
> >> 
> >
> > VDPAU drivers have separate code from libvdpau, while Mesa have drivers
> > inside it (if I get it right). I can't figure out how libvdpau beeing separate
> > can determine mapping between hardware and driver to load. The only way
> > is to ask[1] DRI2.
> 
> Yet the Xorg 2D driver is even less related to the set of vdpau drivers
> available than the vdpau driver loader (which could do things like look
> at a symbol in the driver to find a probing mechanism, like the X Server
> does to X drivers, or read some config directory containing mappings
> installed by the external drivers).
> 
> The reason I'm making a point of this is that DRI3 is dropping the
> driver name strings from the protocol.
> 

Now I see, it should work (with probing mechanism). But there are too many
pieces should be touched to get this working, although it looks like the right
thing to do.

On the other hand, all I'm trying to do is to find minimal change to make
driver autoloading work.

---
Rinat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx