[PATCH] edid: Add quirk for ADA 1024x600 7" display.

2016-12-15 Thread Kai-Heng Feng 
Detailed mode reports 108 mm x 68 mm which is for smaller display.
Maximum image size reports 15 cm x 10 cm which aligns with its physical
size, use this size instead.

Signed-off-by: Kai-Heng Feng 
---
 hw/xfree86/modes/xf86EdidModes.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/xfree86/modes/xf86EdidModes.c b/hw/xfree86/modes/xf86EdidModes.c
index f24294e..f0e1e97 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -153,6 +153,11 @@ quirk_detailed_v_in_cm(int scrnIndex, xf86MonPtr DDC)
 static Bool
 quirk_detailed_use_maximum_size(int scrnIndex, xf86MonPtr DDC)
 {
+/* ADA 1024x600 7" display */
+if (memcmp(DDC->vendor.name, "ADA", 4) == 0 &&
+DDC->vendor.prod_id == 4)
+return TRUE;
+
 /* Bug #21324: Iiyama Vision Master 450 */
 if (memcmp(DDC->vendor.name, "IVM", 4) == 0 && DDC->vendor.prod_id == 6400)
 return TRUE;
-- 
2.10.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [qxl] xspice: Adjust to X.org 1.19 changes

2016-12-15 Thread Christophe Fergeau 
On Wed, Dec 14, 2016 at 12:07:55PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 14-12-16 11:51, Christophe Fergeau wrote:
> > In newer X.org versions, it's no longer supported to modify the set of
> > FDs passed to a BlockHandler method to get notified when the FD has data
> > to be read. This was limited anyway as we could only get read events
> > this way, and had to do our own polling to get notified about socket
> > writeability.
> > 
> > Starting from xserver 1.19, the supported way of doing this is to use
> > the SetNotifyFd/RemoveNotifyFd API, which is actually a much better way
> > as it matches very well the 'watch' API spice-server expects Xspice to
> > implement.
> > 
> > This commit switches to that new API, which removes the need for
> > RegisterBlockAndWakeupHandlers().
> 
> Thank you for doing this, one small comment inline, otherwise looks
> good:
> 
> Reviewed-by: Hans de Goede 

I had a small unapplied change in my working copy,
s/watch_update_mask2/watch_update_mask_internal/ which I squashed in.

> > +static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, 
> > void *opaque)
> > +{
> > +SpiceWatch *watch = malloc(sizeof(SpiceWatch));
> 
> This malloc may fail, please replace malloc with
> xnfalloc which stands for X no fail alloc, it works like
> the glib malloc functions.

There are several other occurrences of unchecked malloc in the Xspice
code, as well as a few strdup calls. I'll change these in a follow-up
patch.

Christophe


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [Spice-devel] [qxl] xspice: Adjust to X.org 1.19 changes

2016-12-15 Thread Uri Lublin 

Hi Christophe,

Please see some comments below

On 12/14/2016 12:51 PM, Christophe Fergeau wrote:

In newer X.org versions, it's no longer supported to modify the set of
FDs passed to a BlockHandler method to get notified when the FD has data
to be read. This was limited anyway as we could only get read events
this way, and had to do our own polling to get notified about socket
writeability.

Starting from xserver 1.19, the supported way of doing this is to use
the SetNotifyFd/RemoveNotifyFd API, which is actually a much better way
as it matches very well the 'watch' API spice-server expects Xspice to
implement.

This commit switches to that new API, which removes the need for
RegisterBlockAndWakeupHandlers().
---
I've lightly (xeyes/rxvt) tested this on f25, and tested this still builds on
f24.
This should fix the issues Hans mentioned in
https://lists.freedesktop.org/archives/spice-devel/2016-October/032501.html


 configure.ac |  5 ---
 src/spiceqxl_main_loop.c | 90 
 2 files changed, 84 insertions(+), 11 deletions(-)

[skip]

diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c
index 49b715a..81bc418 100644
--- a/src/spiceqxl_main_loop.c
+++ b/src/spiceqxl_main_loop.c

[skip]

@@ -276,7 +272,7 @@ static void xspice_block_handler(pointer data, OSTimePtr 
timeout, pointer readma
 /*
  * xserver only calls wakeup_handler with the read fd_set, so we
  * must either patch it or do a polling select ourselves, this is the
- * later approach. Since we are already doing a polling select, we
+ * latter approach. Since we are already doing a polling select, we
  * already select on all (we could avoid selecting on the read since
  * that *is* actually taken care of by the wakeup handler).
  */
@@ -338,9 +334,88 @@ static void xspice_wakeup_handler(pointer data, int nfds, 
pointer readmask)
 select_and_check_watches();
 }

+#else /* GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 23 */
+
+struct SpiceWatch {
+int fd;
+int event_mask;
+SpiceWatchFunc func;
+void *opaque;
+};
+
+static void watch_fd_notified(int fd, int xevents, void *data)
+{
+SpiceWatch *watch = (SpiceWatch *)data;
+
+if ((watch->event_mask & SPICE_WATCH_EVENT_READ) && (xevents & 
X_NOTIFY_READ)) {
+watch->func(watch->fd, SPICE_WATCH_EVENT_READ, watch->opaque);
+}
+
+if ((watch->event_mask & SPICE_WATCH_EVENT_WRITE) && (xevents & 
X_NOTIFY_WRITE)) {
+watch->func(watch->fd, SPICE_WATCH_EVENT_WRITE, watch->opaque);
+}
+}
+
+static int watch_update_mask2(SpiceWatch *watch, int event_mask)
+{
+SetNotifyFd(watch->fd, NULL, X_NOTIFY_NONE, NULL);
+watch->event_mask = 0;
+
+if (event_mask & SPICE_WATCH_EVENT_READ) {
+SetNotifyFd(watch->fd, watch_fd_notified, X_NOTIFY_READ, watch);
+} else if (event_mask & SPICE_WATCH_EVENT_READ) {


1. This should be (event_mask & SPICE_WATCH_EVENT_WRITE)
2. The "else if" fails to support event_mask which is READ | WRITE.
   Can it not watch both events ?

Regards,
Uri.


+SetNotifyFd(watch->fd, watch_fd_notified, X_NOTIFY_WRITE, watch);
+} else {
+DPRINTF(0, "Unexpected watch event_mask: %i", event_mask);
+return -1;
+}
+watch->event_mask = event_mask;
+
+return 0;
+}
+
+static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, void 
*opaque)
+{
+SpiceWatch *watch = malloc(sizeof(SpiceWatch));
+
+DPRINTF(0, "adding %p, fd=%d", watch, fd);
+
+watch->fd = fd;
+watch->func = func;
+watch->opaque = opaque;
+if (watch_update_mask2(watch, event_mask) != 0) {
+free(watch);
+return NULL;
+}
+
+return watch;
+}
+
+static void watch_update_mask(SpiceWatch *watch, int event_mask)
+{
+DPRINTF(0, "fd %d to %d", watch->fd, event_mask);
+watch_update_mask2(watch, event_mask);
+}
+
+static void watch_remove(SpiceWatch *watch)
+{
+DPRINTF(0, "remove %p (fd %d)", watch, watch->fd);
+RemoveNotifyFd(watch->fd);
+free(watch);
+}
+#endif
+
+static void channel_event(int event, SpiceChannelEventInfo *info)
+{
+NOT_IMPLEMENTED
+}
+
+
 SpiceCoreInterface *basic_event_loop_init(void)
 {
+#if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 23
 ring_init();
+#endif
 bzero(, sizeof(core));
 core.base.major_version = SPICE_INTERFACE_CORE_MAJOR;
 core.base.minor_version = SPICE_INTERFACE_CORE_MINOR; // anything less 
then 3 and channel_event isn't called
@@ -355,7 +430,10 @@ SpiceCoreInterface *basic_event_loop_init(void)
 return 
 }

+
 void xspice_register_handlers(void)
 {
+#if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 23
 RegisterBlockAndWakeupHandlers(xspice_block_handler, 
xspice_wakeup_handler, 0);
+#endif
 }



___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [Spice-devel] [qxl] xspice: Adjust to X.org 1.19 changes

2016-12-15 Thread Christophe Fergeau 
On Thu, Dec 15, 2016 at 02:01:03PM +0200, Uri Lublin wrote:
> Hi Christophe,
> 
> Please see some comments below
> 
> On 12/14/2016 12:51 PM, Christophe Fergeau wrote:
> > +static int watch_update_mask2(SpiceWatch *watch, int event_mask)
> > +{
> > +SetNotifyFd(watch->fd, NULL, X_NOTIFY_NONE, NULL);
> > +watch->event_mask = 0;
> > +
> > +if (event_mask & SPICE_WATCH_EVENT_READ) {
> > +SetNotifyFd(watch->fd, watch_fd_notified, X_NOTIFY_READ, watch);
> > +} else if (event_mask & SPICE_WATCH_EVENT_READ) {
> 
> 1. This should be (event_mask & SPICE_WATCH_EVENT_WRITE)

Oops, good catch!

> 2. The "else if" fails to support event_mask which is READ | WRITE.
>Can it not watch both events ?

For some reason, I think I decided this was not needed, but I can't see
why now. I'll update the code.

Christophe


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[qxl] Xspice: Replace malloc/strdup use with xnfalloc/xnfstrdup

2016-12-15 Thread Christophe Fergeau 
spiceqxl_*.c files are Xspice-only code. They contain a few uses of
malloc/strdup, and none of these are checked for failure. It's better to
replace these with xfnalloc/xnfstrdup which are provided by the X server
and cannot fail (aborts on failure).

Signed-off-by: Christophe Fergeau 
---
 src/spiceqxl_audio.c|  2 +-
 src/spiceqxl_main_loop.c|  4 ++--
 src/spiceqxl_spice_server.c | 12 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/spiceqxl_audio.c b/src/spiceqxl_audio.c
index 52a45f0..ec9260d 100644
--- a/src/spiceqxl_audio.c
+++ b/src/spiceqxl_audio.c
@@ -405,7 +405,7 @@ static void handle_one_change(qxl_screen_t *qxl, struct 
inotify_event *e)
 return;
 }
 
-fname = malloc(strlen(e->name) + strlen(qxl->playback_fifo_dir) + 1 + 
1);
+fname = xnfalloc(strlen(e->name) + strlen(qxl->playback_fifo_dir) + 1 
+ 1);
 strcpy(fname, qxl->playback_fifo_dir);
 strcat(fname, "/");
 strcat(fname, e->name);
diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c
index c9894bb..669e116 100644
--- a/src/spiceqxl_main_loop.c
+++ b/src/spiceqxl_main_loop.c
@@ -209,7 +209,7 @@ int watch_count = 0;
 
 static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, void 
*opaque)
 {
-SpiceWatch *watch = malloc(sizeof(SpiceWatch));
+SpiceWatch *watch = xnfalloc(sizeof(SpiceWatch));
 
 DPRINTF(0, "adding %p, fd=%d at %d", watch,
 fd, watch_count);
@@ -376,7 +376,7 @@ static int watch_update_mask_internal(SpiceWatch *watch, 
int event_mask)
 
 static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, void 
*opaque)
 {
-SpiceWatch *watch = malloc(sizeof(SpiceWatch));
+SpiceWatch *watch = xnfalloc(sizeof(SpiceWatch));
 
 DPRINTF(0, "adding %p, fd=%d", watch, fd);
 
diff --git a/src/spiceqxl_spice_server.c b/src/spiceqxl_spice_server.c
index 6e8cf50..38257d0 100644
--- a/src/spiceqxl_spice_server.c
+++ b/src/spiceqxl_spice_server.c
@@ -200,23 +200,23 @@ void xspice_set_spice_server_options(OptionInfoPtr 
options)
 len = strlen(x509_dir) + 32;
 
 if (x509_key_file_base) {
-x509_key_file = strdup(x509_key_file_base);
+x509_key_file = xnfstrdup(x509_key_file_base);
 } else {
-x509_key_file = malloc(len);
+x509_key_file = xnfalloc(len);
 snprintf(x509_key_file, len, "%s/%s", x509_dir, 
X509_SERVER_KEY_FILE);
 }
 
 if (x509_cert_file_base) {
-x509_cert_file = strdup(x509_cert_file_base);
+x509_cert_file = xnfstrdup(x509_cert_file_base);
 } else {
-x509_cert_file = malloc(len);
+x509_cert_file = xnfalloc(len);
 snprintf(x509_cert_file, len, "%s/%s", x509_dir, 
X509_SERVER_CERT_FILE);
 }
 
 if (x509_cacert_file_base) {
-x509_cacert_file = strdup(x509_cert_file_base);
+x509_cacert_file = xnfstrdup(x509_cert_file_base);
 } else {
-x509_cacert_file = malloc(len);
+x509_cacert_file = xnfalloc(len);
 snprintf(x509_cacert_file, len, "%s/%s", x509_dir, 
X509_CA_CERT_FILE);
 }
 }
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Xorg glx module: GLVND, EGL, or ... ?

2016-12-15 Thread Kyle Brenneman 

On 12/15/2016 10:53 AM, Hans de Goede wrote:

Hi,

On 15-12-16 17:08, Emil Velikov wrote:

On 15 December 2016 at 08:15, Michel Dänzer  wrote:


Hi Adam, Andy, Kyle,


even with GLVND in place and used by Mesa and other GL implementations,
one remaining issue preventing peaceful coexistence of Mesa based and
other GLX implementations is that other GLX implementations tend to 
ship

their own, mutually incompatible versions of the Xorg glx module. I'm
not sure about all the reasons for this, but an important one is that
the glx module in the xserver tree has been using the DRI driver
interface directly, which can only work with Mesa.

The "xfree86: Extend OutputClass config sections" series from Hans 
just landed.

With it one can correctly attribute/select the correct libglx.so,
which should tackle the issue ;-)


Not if you want to run some apps one GPU and other apps on the other
GPU ...

Regards,

Hans


More specifically, to allow different drivers on different screens, 
we'll need to define some interface that would dispatch each GLX request 
to the appropriate driver. Basically, a server-side counterpart to 
libglvnd's libGLX.so.


A server interface should be a lot simpler than the client interface, 
though. Everything runs on one thread, we only have to care about 
mapping based on XID's and context tags, we don't have to worry about 
multiple servers with different sets of vendors, we can ignore basically 
everything that libGLdispatch.so is needed for in the client, and the 
opcodes nicely define a dispatch table for us.


Using EGL might work, although I don't know my way around the server 
well enough to comment on what that would take. The biggest problem that 
I see is that if you've got a single, common library that translates GLX 
requests to EGL calls, then how would a vendor library define a new GLX 
extension?


Also note that they may or may not be mutually exclusive. If you can use 
libEGL.so to draw to a surface within the server, then I'd expect you 
could implement a vendor library that works by calling into EGL. Mind 
you, if you had two vendors trying to do that, then things would get hairy.


-Kyle

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Xorg glx module: GLVND, EGL, or ... ?

2016-12-15 Thread Hans de Goede 

Hi,

On 15-12-16 17:08, Emil Velikov wrote:

On 15 December 2016 at 08:15, Michel Dänzer  wrote:


Hi Adam, Andy, Kyle,


even with GLVND in place and used by Mesa and other GL implementations,
one remaining issue preventing peaceful coexistence of Mesa based and
other GLX implementations is that other GLX implementations tend to ship
their own, mutually incompatible versions of the Xorg glx module. I'm
not sure about all the reasons for this, but an important one is that
the glx module in the xserver tree has been using the DRI driver
interface directly, which can only work with Mesa.


The "xfree86: Extend OutputClass config sections" series from Hans just landed.
With it one can correctly attribute/select the correct libglx.so,
which should tackle the issue ;-)


Not if you want to run some apps one GPU and other apps on the other
GPU ...

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Xorg glx module: GLVND, EGL, or ... ?

2016-12-15 Thread Emil Velikov 
On 15 December 2016 at 08:15, Michel Dänzer  wrote:
>
> Hi Adam, Andy, Kyle,
>
>
> even with GLVND in place and used by Mesa and other GL implementations,
> one remaining issue preventing peaceful coexistence of Mesa based and
> other GLX implementations is that other GLX implementations tend to ship
> their own, mutually incompatible versions of the Xorg glx module. I'm
> not sure about all the reasons for this, but an important one is that
> the glx module in the xserver tree has been using the DRI driver
> interface directly, which can only work with Mesa.
>
The "xfree86: Extend OutputClass config sections" series from Hans just landed.
With it one can correctly attribute/select the correct libglx.so,
which should tackle the issue ;-)

> Adam, IIRC you previously mentioned the possibility of making the
> xserver glx module use EGL instead of the DRI driver interface. Another
> possibility might be to make it use GLVND. Is my understanding correct
> that those are basically two mutually exclusive approaches for
> addressing this issue? Maybe there's even more options I'm not aware of?
>
On the topic of using reimplementing DRI modules in terms of EGL I'm
slightly worried since this means a) new code (bugs, testing, etc.)
which very few people know and b) mixing APIs might end up nasty (see
below) not to mention the unnecessary complexity/overhead that we'll
get since we'll be going through GLVND every time.

Example:
Would happen if we one calls glXMakeCurrent which internally goes down
to eglMakeCurrent ? Are we going to clash since (iirc) one is not
allowed to do both on the same GL ctx ?

Some food for thought... considering I've not lost it and the above
sounds about right :-)
Emil
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [qxl] Xspice: Replace malloc/strdup use with xnfalloc/xnfstrdup

2016-12-15 Thread Hans de Goede 

Hi,

On 15-12-16 10:57, Christophe Fergeau wrote:

spiceqxl_*.c files are Xspice-only code. They contain a few uses of
malloc/strdup, and none of these are checked for failure. It's better to
replace these with xfnalloc/xnfstrdup which are provided by the X server
and cannot fail (aborts on failure).

Signed-off-by: Christophe Fergeau 


LGTM:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
 src/spiceqxl_audio.c|  2 +-
 src/spiceqxl_main_loop.c|  4 ++--
 src/spiceqxl_spice_server.c | 12 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/spiceqxl_audio.c b/src/spiceqxl_audio.c
index 52a45f0..ec9260d 100644
--- a/src/spiceqxl_audio.c
+++ b/src/spiceqxl_audio.c
@@ -405,7 +405,7 @@ static void handle_one_change(qxl_screen_t *qxl, struct 
inotify_event *e)
 return;
 }

-fname = malloc(strlen(e->name) + strlen(qxl->playback_fifo_dir) + 1 + 
1);
+fname = xnfalloc(strlen(e->name) + strlen(qxl->playback_fifo_dir) + 1 
+ 1);
 strcpy(fname, qxl->playback_fifo_dir);
 strcat(fname, "/");
 strcat(fname, e->name);
diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c
index c9894bb..669e116 100644
--- a/src/spiceqxl_main_loop.c
+++ b/src/spiceqxl_main_loop.c
@@ -209,7 +209,7 @@ int watch_count = 0;

 static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, void 
*opaque)
 {
-SpiceWatch *watch = malloc(sizeof(SpiceWatch));
+SpiceWatch *watch = xnfalloc(sizeof(SpiceWatch));

 DPRINTF(0, "adding %p, fd=%d at %d", watch,
 fd, watch_count);
@@ -376,7 +376,7 @@ static int watch_update_mask_internal(SpiceWatch *watch, 
int event_mask)

 static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, void 
*opaque)
 {
-SpiceWatch *watch = malloc(sizeof(SpiceWatch));
+SpiceWatch *watch = xnfalloc(sizeof(SpiceWatch));

 DPRINTF(0, "adding %p, fd=%d", watch, fd);

diff --git a/src/spiceqxl_spice_server.c b/src/spiceqxl_spice_server.c
index 6e8cf50..38257d0 100644
--- a/src/spiceqxl_spice_server.c
+++ b/src/spiceqxl_spice_server.c
@@ -200,23 +200,23 @@ void xspice_set_spice_server_options(OptionInfoPtr 
options)
 len = strlen(x509_dir) + 32;

 if (x509_key_file_base) {
-x509_key_file = strdup(x509_key_file_base);
+x509_key_file = xnfstrdup(x509_key_file_base);
 } else {
-x509_key_file = malloc(len);
+x509_key_file = xnfalloc(len);
 snprintf(x509_key_file, len, "%s/%s", x509_dir, 
X509_SERVER_KEY_FILE);
 }

 if (x509_cert_file_base) {
-x509_cert_file = strdup(x509_cert_file_base);
+x509_cert_file = xnfstrdup(x509_cert_file_base);
 } else {
-x509_cert_file = malloc(len);
+x509_cert_file = xnfalloc(len);
 snprintf(x509_cert_file, len, "%s/%s", x509_dir, 
X509_SERVER_CERT_FILE);
 }

 if (x509_cacert_file_base) {
-x509_cacert_file = strdup(x509_cert_file_base);
+x509_cacert_file = xnfstrdup(x509_cert_file_base);
 } else {
-x509_cacert_file = malloc(len);
+x509_cacert_file = xnfalloc(len);
 snprintf(x509_cacert_file, len, "%s/%s", x509_dir, 
X509_CA_CERT_FILE);
 }
 }


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Xorg glx module: GLVND, EGL, or ... ?

2016-12-15 Thread Michel Dänzer 

Hi Adam, Andy, Kyle,


even with GLVND in place and used by Mesa and other GL implementations,
one remaining issue preventing peaceful coexistence of Mesa based and
other GLX implementations is that other GLX implementations tend to ship
their own, mutually incompatible versions of the Xorg glx module. I'm
not sure about all the reasons for this, but an important one is that
the glx module in the xserver tree has been using the DRI driver
interface directly, which can only work with Mesa.

Adam, IIRC you previously mentioned the possibility of making the
xserver glx module use EGL instead of the DRI driver interface. Another
possibility might be to make it use GLVND. Is my understanding correct
that those are basically two mutually exclusive approaches for
addressing this issue? Maybe there's even more options I'm not aware of?

I'd be interested in any thoughts you guys could share on this topic, in
particular on which of the above two options would be better.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel