[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/4] bcm2835_fb: add framebuffer device for Rasp
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH 3/4] bcm2835_fb: add framebuffer device for Raspberry Pi |
Date: |
Wed, 2 Mar 2016 12:33:08 +0000 |
On 2 March 2016 at 00:19, Andrew Baumann <address@hidden> wrote:
>> From: Peter Maydell [mailto:address@hidden
>> More interestingly, why can't you just read from the source
>> pointer you're passed in here? The framebuffer_update_display()
>> code should have obtained it by looking up the location of the
>> host RAM where the guest video RAM is, so if you ignore it and
>> do a complete physical-address-to-memory-region lookup for every
>> pixel it's going to make redraws unnecessarily slow.
>
> That is what's happening for the 16-, 24- and 32-bit modes. For
> 8-bit, it appears to be doing a palette lookup (using the 8-bit
> value at the pointer as an index into the 256-colour palette
> starting at vcram_base).
Oh, right, it's a palette lookup. That's fine, then. A
comment mentioning that this is doing palette lookup would
help. I wouldn't worry about efficiency for this mode because
who's using 8-bit colour in 2016 ?
thanks
-- PMM