On Tue, Jan 29, 2019 at 09:10:08PM +0100, Môshe van der Sterre wrote: > Hi Peter, > > On 01/29/2019 07:51 PM, Peter Jones wrote: > > The BGRT table's "status" field doesn't indicate "validity", but rather > > if and how the image is being displayed. As such, we shouldn't decide > > the table is invalid if status bits we don't understand are in use, and > > it's better to expose the values we do understand directly. > > This goes against the conclusion of this discussion from 2015: > https://patchwork.kernel.org/patch/6688521/ > I wasn't involved with that discussion, so I have CC-ed the participants. > > You noted in another mail that the version field was not updated while > the status field has been backwards-incompatibly changed. I honestly > don't know what to think of this, because it shatters any meaning the > words "must be zero" could have had. Around 8 months *after* that discussion, ASWG (the keepers of the ACPI spec) had a discussion about an ECR that added both the orientation bits and this clarification: - 1-byte status field indicating current status. + 1-byte status field indicating current status of the image. But that change did not change the version field. This was considered an erratum, though I don't have enough context to know why - my guess is that someone thought adding bits would be a harmless forward-compatible change, without thinking about how our implementation might work with respect to the version field or the reserved bits. I share your dismay, but I think it's now clear that these bits aren't intended as the status of the BGRT, but rather they merely describe the image it refers to. With that in mind, it doesn't appear reasonable to go on dismissing the whole thing based on the reserved bits of that field - we can still use the image just fine. But that's just my opinion :) -- Peter
