Hi,
On 11-06-19 16:04, Ard Biesheuvel wrote:
On Mon, 10 Jun 2019 at 17:12, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
On Wed, 29 May 2019 at 17:46, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
reserved. These bits are now used to indicate if the image needs to be
rotated before being displayed.
The efifb code does not support rotating the image before copying it to
the screen.
This commit adds a check for these new bits and if they are set leaves the
fb contents as is instead of trying to use the un-rotated BGRT image.
Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
Acked-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
BTW should we make sure that this patch and the efi-bgrt patch get
merged at the same time?
The 2 patches are related but merging them at the same time is not
necessary.
I guess the net result is just that we get
rid of some error in the log, but a rotated BMP will be ignored
otherwise.
Right, worse case (if the bmp fits pre-rotation) it will be displayed
rotated. Note on the one machine I'm aware of which uses these bits
the bmp does not fit pre-rotation, so we end up triggering:
error:
memunmap(bgrt_image);
pr_warn("efifb: Ignoring BGRT: unexpected or invalid BMP data\n");
}
Which this patch replaces with hitting:
if (bgrt_tab.status & 0x06) {
pr_info("efifb: BGRT rotation bits set, not showing boot graphics\n");
return;
}
Instead. So at least on the one machine I know of this is 99% cosmetic.
Or is it relevant for userland in some other way?
No.
Regards,
Hans
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
