[Xcb] Lua binding for XCB
peter.harris at hummingbird.com
Wed Nov 7 11:22:11 PST 2007
Barton C Massey wrote:
> In message <4731ECFF.60501 at hummingbird.com> you wrote:
>> As to how it goes, it seems to work surprisingly well given the amount
>> of effort I've spent on it so far. I believe I've spent more time on my
>> visual-id-matching algorithm than I have spent with XCB, which speaks
>> well to the ease-of-use of XCB.
> I also have xcb_aux_find_visual_by_id() ready to commit to
I suspect you misunderstand. When playing back a trace, the problem is
"The connection block in the trace has these properties. Which visuals
(on which screens) available from the server most closely resemble those
in the trace?"
This is a problem specific to my application, and not something I expect
to find in any library.
>> There are a few nits, of course. I seem to recall that GetProperty was
>> surprising to implement correctly.
> I think this is a bug (or perhaps several bugs); if you
> would please post it to bugs.freedesktop.org, that would be
>> ChangeProperty is not correctly implemented in luaxcb because I haven't
>> gotten around to inverting "op". My current plan is to wait until you
>> finish xserver-XCB and borrow that code.
> The Python code (if that is what you mean) should be in soon.
Actually, I was referring to xcb-server (as seen on
>> The other minor nit is the lack of type information for
>> the CreateWindow, ChangeWindowAttributes, Create/ChangeGC,
>> and ConfigureWindow bit masks. This is the only place (so
>> far) where I've had to manually set type information (XID
>> vs integer).
> I'm not quite following. The masks aren't XIDs...
No, but the data blobs that the masks refer to might be XIDs.
For example, I have this line in my perl code:
CreateWindow => [ 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1 ],
Those flags refer to backround pixmap id, background color, border
pixmap id, border color, bit gravity, ..., override redirect, colormap
id, cursor id, just like the mask. Some of these things are XIDs, some
of these things are not. libxcb just takes an array of uint32_t, and
ignores any possible semantic meaning (xcb_pixmap_t vs xcb_cursor_t vs
things that really are uint32_t).
This is fine for libxcb, but it doesn't work for my purposes. At least,
not without the above line as an additional hint to my code.
This isn't something that can be fixed in XCB/proto without changing
xcb.xsd, which I don't feel qualified to do.
It's also really low priority, since there are only a couple of requests
that use masks. Manually maintaining this information is easier (in the
short term) than writing code to parse the information out of .xml files
modified to use a (hypothetical) new .xsd, even without doing the work
to modify the .xsd and .xml files.
>> byte swap if necessary. Implementing all the possible GLX/Render
>> sub-requests is a huge chore, but at least I'm not the only person who
>> would use such a thing. Any xmond, xscope, or similar based on XCB will
>> want to be able to take apart the contents of GLX/Render, too.
> An enhancement request bug should be filed for this.
Hummingbird Connectivity - A Division of Open Text
Peter Harris http://connectivity.hummingbird.com
Research and Development Phone: +1 905 762 6001
peter.harris at hummingbird.com Toll Free: 1 877 359 4866
More information about the Xcb