Hi,
> > How stable are these numbers?
>
> In theory the mesa/gallium numbers aren't stable, though I've never
> seen them change yet,
>
> If they diverge in the future I'll just provide a remapping table
> inside the guest driver.
>
> So it should be fine to expose these formats for 2D use.
>
> Lets try to get away with 32bpp only in 2d mode then.
>
> bochsdrm likewise supports 32bpp only and I yet have to see a request
> for 16bpp or even 8bpp support.
>
>> I think we should probably move a few more formats from the 3D side
>> into the 2D side, so we can have the guests just pick the
On 15 October 2014 20:05, Gerd Hoffmann wrote:
> Hi,
>
>> +/* VIRTIO_GPU_RESP_OK_DISPLAY_INFO */
>> +#define VIRTIO_GPU_MAX_SCANOUTS 16
>> +struct virtio_gpu_resp_display_info {
>> +struct virtio_gpu_ctrl_hdr hdr;
>> +struct virtio_gpu_display_one {
>> +uint32_t enabled;
>> +
Hi,
> +/* VIRTIO_GPU_RESP_OK_DISPLAY_INFO */
> +#define VIRTIO_GPU_MAX_SCANOUTS 16
> +struct virtio_gpu_resp_display_info {
> +struct virtio_gpu_ctrl_hdr hdr;
> +struct virtio_gpu_display_one {
> +uint32_t enabled;
> +uint32_t width;
> +uint32_t height;
> +
Hi,
> >> >> +VIRTIO_GPU_FORMAT_B5G5R5A1_UNORM = 5,
> >> >> +VIRTIO_GPU_FORMAT_B5G6R5_UNORM= 7,
> >> >
> > Ok. But for 2D we can just not support it, right?
>
> We can, I expect some pushback at some point, people still want to
> test with 16bpp for other areas, and it would be nic
On 30 September 2014 17:55, Gerd Hoffmann wrote:
>
> On Di, 2014-09-30 at 10:27 +1000, Dave Airlie wrote:
>> > Triggered by the framebuffer endian issues we have with stdvga I've
>> > started to check where we stand with virtio-gpu and whenever we have to
>> > fix something in the virtio protocol
On Di, 2014-09-30 at 10:27 +1000, Dave Airlie wrote:
> > Triggered by the framebuffer endian issues we have with stdvga I've
> > started to check where we stand with virtio-gpu and whenever we have to
> > fix something in the virtio protocol before setting in stone with the
> > upstream merge.
>
On Di, 2014-09-30 at 10:27 +1000, Dave Airlie wrote:
> > Triggered by the framebuffer endian issues we have with stdvga I've
> > started to check where we stand with virtio-gpu and whenever we have to
> > fix something in the virtio protocol before setting in stone with the
> > upstream merge.
>
> Triggered by the framebuffer endian issues we have with stdvga I've
> started to check where we stand with virtio-gpu and whenever we have to
> fix something in the virtio protocol before setting in stone with the
> upstream merge.
Let me start by saying its not that I don't care about endiannes
Hi Dave,
Triggered by the framebuffer endian issues we have with stdvga I've
started to check where we stand with virtio-gpu and whenever we have to
fix something in the virtio protocol before setting in stone with the
upstream merge.
Fixed the protocol. Basically s/uint32_t/__le32/g. No chan
This patch adds the header file with structs and defines for
the virtio based gpu device. Covers 2d operations only.
Written by Dave Airlie and Gerd Hoffmann.
Signed-off-by: Dave Airlie
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virtgpu_hw.h | 207 +
11 matches
Mail list logo
