[PATCH] Declare enumeration wl_output.transform as bitfield.

[Auke Booij]

On 6 November 2015 at 13:03, Nils Christopher Brause
<nilschrbrause at gmail.com> wrote:
> The enumeration wl_output.transform is clearly a bitfield.
> The definition of a bitfield is that each bit has a distinct
> meaning. This is clearly the case in the enumeration
> wl_output.transform:
>
> - bit 0: rotate by 90 degree
> - bit 1: rotate by 180 degree
> - bit 2: flip around vertical axis

Just to complete the definitions: what is the right order of
operations here? How do I transform from "normal" to
wl_output::transform = 0b101, for example? First rotating 90 degrees
and then flipping is not the same as first flipping and then rotating
90 degrees. In mathematical terms, the symmetry group of the square is
not a commutative group.

> Every other value can be constructed by ORing together the
> above bits:
>
> - "270" = "90" | "180"
> - "flipped_90" = "90" | "flipped"
> - "flipped_180" = "180" | "flipped"
> - "flipped_270" = "90" | "180" | "flipped"

While I agree with this, this does not seem to be used anywhere in
weston's source code. Not saying I disagree with your claim that
wl_output::transform should be considered a bitfield, but why is it
necessary to do so?

> Therefore the bitfield="true" attribute has been added to
> the enumeration declaration. Since this bitfield is
> transferred as signed integer, the scanner had to be
> modified to accept that behaviour. This was also noted in
> the documentation.

As I made clear in our previous discusions, I don't think that it is a
safe idea to allow signed integers to be bitfields. Requiring
unsignedness is a sanity check. So I would not like this patch, if
only for the reason that it invalidates this check.