dri2: SProcDRI2Connect - send the response.

Submitted by Michal Srb on May 4, 2012, 4:29 p.m.

Details

Message ID 2391089.ABGY0Qo0ou@dhcp71
State Accepted
Headers show

Not browsing as part of any series.

Commit Message

Michal Srb May 4, 2012, 4:29 p.m.
The swapped implementation of DRI2Connect is always responding with empty
device and driver values. However the response was only prepared and never
sent (also had undefined .type member), causing e.g. glxinfo get stuck waiting
for response when started remotely from machine with different endianity.

Signed-off-by: Michal Srb <msrb@suse.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
---
 hw/xfree86/dri2/dri2ext.c |    3 +++
 1 file changed, 3 insertions(+)

Patch hide | download patch | download mbox

diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
index 73ef7f2..c7749ba 100644
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -592,12 +592,15 @@  SProcDRI2Connect(ClientPtr client)
     if (sizeof(*stuff) / 4 != client->req_len)
        return BadLength;
 
+    rep.type = X_Reply;
     rep.sequenceNumber = client->sequence;
     swaps(&rep.sequenceNumber);
     rep.length = 0;
     rep.driverNameLength = 0;
     rep.deviceNameLength = 0;
 
+    WriteToClient(client, sizeof(xDRI2ConnectReply), &rep);
+
     return Success;
 }
 

Comments

On Fre, 2012-05-04 at 18:29 +0200, Michal Srb wrote: 
> The swapped implementation of DRI2Connect is always responding with empty
> device and driver values. However the response was only prepared and never
> sent (also had undefined .type member), causing e.g. glxinfo get stuck waiting
> for response when started remotely from machine with different endianity.
> 
> Signed-off-by: Michal Srb <msrb@suse.com>
> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>

Tested-by: Michel Dänzer <michel@daenzer.net>

This should also go to stable trees.
Michal Srb <msrb@suse.com> writes:

> The swapped implementation of DRI2Connect is always responding with empty
> device and driver values. However the response was only prepared and never
> sent (also had undefined .type member), causing e.g. glxinfo get stuck waiting
> for response when started remotely from machine with different
> endianity.

Merged.
   457fc77..9bc53d8  master -> master