No subject


Mon Oct 20 08:17:21 PDT 2008


    def GetCrtcInfo(self, crtc, config_timestamp):
        buf = cStringIO.StringIO()
        buf.write(pack('xx2xII', crtc, config_timestamp))
        return self.send_request(xcb.Request(buf.getvalue(), 20, False, True),
                                 GetCrtcInfoCookie(),
                                 GetCrtcInfoReply)


So GetCrtcInfo takes two arguments and they are both 4-byte unsigned
(CARD32, "I" in pack() parlance) values.  What is their significance? 
Beats me, xpyb is just a binding.  Looks like one of them is an index
and one is a standard X11 timestamp.

Also from randr.py:

class GetCrtcInfoReply(xcb.Reply):
    def __init__(self, parent):
        xcb.Reply.__init__(self, parent)
        count = 0
        (self.status, self.timestamp, self.crtc, self.x, self.y, self.width, sel
f.height, self.mode, self.rotation, self.rotations, self.num_outputs, self.num_p
ossible_outputs,) = unpack_from('xB2x4xIIhhHHIHHHH', self, count)
        count += 36
        self.outputs = xcb.List(self, count, self.num_outputs, 'I', 4)


So the reply is a bunch of structure fields and then a list of CARD32. 
The question is whether this accurately matches what is on the wire.

There was a bug in xpyb 0.9 where it didn't work properly on 64-bit
systems and the "buffer object too short" error would be thrown, but
that's supposedly fixed in 1.0.


> Ok, I did as you said and I called that function in the following way
> (note: crtc.id <http://crtc.id> is equal to resources.crtcs[it]):
>
> cookie = self.conn.randr.GetCrtcInfo(crtc.id <http://crtc.id>,
> resources.config_timestamp)
> info = cookie.reply()
>
> but I get this:
> File "/usr/local/lib/python2.5/site-packages/xcb/randr.py", line 227,
> in __init__
>     self.outputs = xcb.List(self, count, self.num_outputs, 'I', 4)
> xcb.Exception: Protocol object buffer too short.
>
> This is weird as I have no problem when I call GetOutputInfo():
> cookie = self.conn.randr.GetOutputInfo(output.id <http://output.id>,
> resources.config_timestamp)
>
> I have tried the latest release of xpyb (1.0) too but it doesn't solve
> the problem.
>
> Any ideas?
>


-- 
Eamon Walsh <ewalsh at tycho.nsa.gov>
National Security Agency



More information about the Xcb mailing list