[Xcb] Re: xcb-proto: prelimininary support for XTEST, XC-MISC, SYNC

[Mikko Markus Torni]

[NOTE: This message is continuation from personal emails]

On Tue, Jun 22, 2004 at 05:49:32PM -0700, Jamey Sharp wrote:
> On Tue, Jun 22, 2004 at 06:41:25PM +0300, Mikko Markus Torni wrote:
> > Hi!
> 
> Hi!
> 
> > Just for my personal entertainment I wrote the attached interface files.
> > I used the X protocol specifications as the source.
> > 
> > I had a look at the generated code. I didn't notice anything
> > questionable. On the other hand, it's still untested code.
> 
> These look great! You rock. Can I have your permission to put your name
> and e-mail address in the changelog?

Sure. Permission granted.

> I'm committing the XC-Misc patch almost unchanged. I don't want the
> TOUPPER m4 macro to do anything except change lowercase letters to
> uppercase, though, so I took a simpler approach and renamed the file to
> 'xc_misc.xcb'. Other than that, I've left it as you wrote it.

ok.

> If you want, you could make XCB use this extension when it needs new
> XIDs. The source file to change is xcb_xid.c; feel free to hack up the
> _xcb_xid structure in xcbint.h too. This should be pretty easy to do,
> and would be a fairly significant contribution to XCB.

I'll have a look at it.

> As for the other two extensions, there are some small issues that need
> to be taken care of before I'll commit them, although they mostly look
> just fine.

I am aware that they have issues. I am not very familiar with XCB yet,
so I thought sending them to somebody for comments would be a good idea.

> > By the way, xcb-demo's xdpyinfo displays binary bytes when it's supposed
> > to list the extensions. Is this normal or am I the one to blame?
> 
> The four-argument ARRAYFIELD needs a little more examination. The bug
> you noticed is a symptom of a failure of the protocol description
> language, and this failure also affects the SYNC extension. I wrote the
> description language assuming that arrays and lists would never need
> padding. Last week Keith and I discovered that some of them do need
> padding, and assumed they all need padding. That assumption wasn't right
> either: only some lists and arrays need padding, and as the SYNC
> extension demonstrates, the amount of padding varies. I want to spend
> more thought on this before committing the SYNC extension.

This just shows what late night hacking does. I completely forgot to
explain all of what I did, especially the four-argument ARRAYFIELD.

> Be careful with enumerated types: you don't get to specify how many
> bytes they should occupy at this point. This might be considered a bug
> in the protocol description language, but unless it's fixed, you need to
> specify something like CARD8 instead of the enumerated type name
> everywhere it's used. I noticed this mostly in the SYNC extension.

Okay. I'll have another go at it.

> The only problem with the XTEST extension, in my opinion, is the
> FAKE_EVENT_TYPE enumeration. Those values are already available from
> xcb.h, and since enumerations can't currently be used for anything
> except giving names to values, this is redundant.

I commented FAKE_EVENT_TYPE out and added a comment about it.

> I think you probably meant to copyright these files in 2004 only, too.

Yes.

> > I tried to add support for BITMASK types, but couldn't figure out how
> > the m4 code generation works. (I am not a m4 guru) I'll have a go at it
> > again next week.
> 
> I'm not sure what you mean by that, exactly. If you're referring to the
> to-do item "Implement an m4 metalanguage mechanism for requests and
> replies to declare enumerated and bitfield types...", part of the reason
> I haven't done that yet is that I don't know what it should look like,
> and designing the language for it strikes me as hard. So what were you
> trying to do?

I was trying to come up with something like this (example from SYNC
implementation):

BITMASKREPLY(CARD32, `values_mask')
CONDREPLY(CARD32, `counter', `R->values_mask & 0x00000001')
CONDREPLY(CARD32, `value_type', `R->values_mask & 0x00000002')
CONDREPLY(CARD32, `value', `R->values_mask & 0x00000004')
etc...

This of course has the disadvantage of requiring a new conditional
version for each field type.

Somehow there should be an (extensible?) way to specify properties for
fields. By properties I mean ways to specify padding, conditionality and
number of elements.

> Thanks for taking a look at XCB. Would you mind directing further
> discussion to the mailing list? I prefer to make these sorts of
> conversations public, personally. And if you have a little time, a
> critique of the current protocol-description language would be really
> helpful.

-- 
-- personal: mikko.markus.torni at iki.fi / mikko.torni at iki.fi
-- mobile:   +358-44-5233421