search for: drm_format_

On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote: > Hi, > > > > static const uint32_t virtio_gpu_cursor_formats[] = { > > > +#ifdef __BIG_ENDIAN > > > + DRM_FORMAT_BGRA8888, > > > +#else > > > DRM_FORMAT_ARGB8888, > > > +#endif > > > > DRM formats are supposed to be little endian, so this isn't really > > correct. > > Well, maybe they where *intended* to be little endian at some point in > the past....

...rtual machine use case this doesn't buy us much. The drm drivers (at least the ones used on both big and little endian guests) support only 32 bpp + depth 24 formats. And for these we don't need a "other endian" flag because we have fourcc codes for all sorts of byte orders (i.e. DRM_FORMAT_XRGB8888 little endian == DRM_FORMAT_BGRX8888 big endian). The DRM_FORMAT_BIG_ENDIAN flags also seems not be used anywhere in the code base (except in some format printing debug code ...). cheers, Gerd

...buy us much. > > The drm drivers (at least the ones used on both big and little endian > > guests) support only 32 bpp + depth 24 formats. And for these we don't > > need a "other endian" flag because we have fourcc codes for all sorts of > > byte orders (i.e. DRM_FORMAT_XRGB8888 little endian == > > DRM_FORMAT_BGRX8888 big endian). > > Yeah, those could be handled without the flag. But when mixed with any > other format the code would look a bit weird IMO. Well, there is a reason only the 32bpp formats are supported. With those you just adjust you...

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order mode_config bit so drm_mode_addfb() asks for the correct format code. Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little endian, so using a different mappin...

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order mode_config bit so drm_mode_addfb() asks for the correct format code. Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little endian, so using a different mappin...

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver feature flag so drm_mode_addfb() asks for the correct format code. Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little endian, so using a different mapping on...

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order mode_config bit so drm_mode_addfb() asks for the correct format code. Create our own plane and use drm_crtc_init_with_planes() instead of depending on the default created b...

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order mode_config bit so drm_mode_addfb() asks for the correct format code. Create our own plane and use drm_crtc_init_with_planes() instead of depending on the default created b...

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver feature flag so drm_mode_addfb() asks for the correct format code. Create our own plane and use drm_crtc_init_with_planes() instead of depending on the default created by drm...

Hi, > > static const uint32_t virtio_gpu_cursor_formats[] = { > > +#ifdef __BIG_ENDIAN > > + DRM_FORMAT_BGRA8888, > > +#else > > DRM_FORMAT_ARGB8888, > > +#endif > > DRM formats are supposed to be little endian, so this isn't really > correct. Well, maybe they where *intended* to be little endian at some point in the past. The actual code appears to interpret them a...

Hi, > > static const uint32_t virtio_gpu_cursor_formats[] = { > > +#ifdef __BIG_ENDIAN > > + DRM_FORMAT_BGRA8888, > > +#else > > DRM_FORMAT_ARGB8888, > > +#endif > > DRM formats are supposed to be little endian, so this isn't really > correct. Well, maybe they where *intended* to be little endian at some point in the past. The actual code appears to interpret them a...

On Thu, Apr 06, 2017 at 08:27:47PM +0300, Ville Syrj?l? wrote: > On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > static const uint32_t virtio_gpu_cursor_formats[] = { > > > > +#ifdef __BIG_ENDIAN > > > > + DRM_FORMAT_BGRA8888, > > > > +#else > > > > DRM_FORMAT_ARGB8888, > > > > +#endif > > > > > > DRM formats are supposed to be little endian, so this isn't really > > > correct. > > > > Well, maybe they where *intended* to be littl...

On Thu, Apr 06, 2017 at 08:27:47PM +0300, Ville Syrj?l? wrote: > On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > static const uint32_t virtio_gpu_cursor_formats[] = { > > > > +#ifdef __BIG_ENDIAN > > > > + DRM_FORMAT_BGRA8888, > > > > +#else > > > > DRM_FORMAT_ARGB8888, > > > > +#endif > > > > > > DRM formats are supposed to be little endian, so this isn't really > > > correct. > > > > Well, maybe they where *intended* to be littl...

...se this doesn't buy us much. > The drm drivers (at least the ones used on both big and little endian > guests) support only 32 bpp + depth 24 formats. And for these we don't > need a "other endian" flag because we have fourcc codes for all sorts of > byte orders (i.e. DRM_FORMAT_XRGB8888 little endian == > DRM_FORMAT_BGRX8888 big endian). Yeah, those could be handled without the flag. But when mixed with any other format the code would look a bit weird IMO. So my idea with the flag was that if you display is big endian you always have the flag, and then you don't ha...

...se this doesn't buy us much. > The drm drivers (at least the ones used on both big and little endian > guests) support only 32 bpp + depth 24 formats. And for these we don't > need a "other endian" flag because we have fourcc codes for all sorts of > byte orders (i.e. DRM_FORMAT_XRGB8888 little endian == > DRM_FORMAT_BGRX8888 big endian). Yeah, those could be handled without the flag. But when mixed with any other format the code would look a bit weird IMO. So my idea with the flag was that if you display is big endian you always have the flag, and then you don't ha...