Hi,
> > So just not using the swapping indeed looks like the only sensible
> > option. Which in turn implies there is no BGRA support for dumb
> > bos. Hmm, I can see the problem. Userspace expectation appears to be
> > that ADDFB configures a native endian framebuffer, which the driver
On 27/04/17 03:45 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> That is done using the RADEON_TILING_SWAP_{16,32}BIT flag mentioned in
>>> another thread?
>>
>> Right.
>>
>>
>>> What about dumb bos? You've mentioned the swap flag isn't used for
>>> those. Which implies they are in little endian byte
Hi,
> > That is done using the RADEON_TILING_SWAP_{16,32}BIT flag mentioned in
> > another thread?
>
> Right.
>
>
> > What about dumb bos? You've mentioned the swap flag isn't used for
> > those. Which implies they are in little endian byte order (both gpu and
> > cpu view).
>
> Right,
On 26/04/17 09:11 PM, Gerd Hoffmann wrote:
> Hi,
>
Just to reiterate, this won't work for the radeon driver, which programs
the GPU to use (effectively, per the current definition that these are
little endian GPU formats) DRM_FORMAT_XRGB with pre-R600 and
On Wed, Apr 26, 2017 at 11:00:09AM +0900, Michel Dänzer wrote:
> On 25/04/17 06:52 PM, Ville Syrjälä wrote:
> > On Tue, Apr 25, 2017 at 12:18:52PM +0900, Michel Dänzer wrote:
> >> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> >>> +#ifdef __BIG_ENDIAN
> >>> + switch (bpp) {
> >>> + case 8:
> >>> +
> uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
> {
> uint32_t fmt;
> #ifdef __BIG_ENDIAN
> enum { LITTLE_ENDIAN = 0 };
> #else
> enum { LITTLE_ENDIAN = 1 };
> #endif
> /* ... */
>
> (using an enum
On Wednesday, 2017-04-26 07:53:10 +0200, Gerd Hoffmann wrote:
> On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote:
> > On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> > > Return correct fourcc codes on bigendian. Drivers must be adapted to
> > > this change.
> > >
> > > Signed-off-by: Gerd
Hi,
> >> Just to reiterate, this won't work for the radeon driver, which programs
> >> the GPU to use (effectively, per the current definition that these are
> >> little endian GPU formats) DRM_FORMAT_XRGB with pre-R600 and
> >> DRM_FORMAT_BGRX with >= R600.
> >
> > Hmm, ok, how does
On 26/04/17 02:53 PM, Gerd Hoffmann wrote:
> On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote:
>> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
>>> Return correct fourcc codes on bigendian. Drivers must be adapted to
>>> this change.
>>>
>>> Signed-off-by: Gerd Hoffmann
>>
On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote:
> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> > Return correct fourcc codes on bigendian. Drivers must be adapted to
> > this change.
> >
> > Signed-off-by: Gerd Hoffmann
>
> Just to reiterate, this won't work for the
On 25/04/17 06:52 PM, Ville Syrjälä wrote:
> On Tue, Apr 25, 2017 at 12:18:52PM +0900, Michel Dänzer wrote:
>> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
>>> +#ifdef __BIG_ENDIAN
>>> + switch (bpp) {
>>> + case 8:
>>> + fmt = DRM_FORMAT_C8;
>>> + break;
>>> + case 24:
>>>
On Tue, Apr 25, 2017 at 12:18:52PM +0900, Michel Dänzer wrote:
> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> > Return correct fourcc codes on bigendian. Drivers must be adapted to
> > this change.
> >
> > Signed-off-by: Gerd Hoffmann
>
> Just to reiterate, this won't work
On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> Return correct fourcc codes on bigendian. Drivers must be adapted to
> this change.
>
> Signed-off-by: Gerd Hoffmann
Just to reiterate, this won't work for the radeon driver, which programs
the GPU to use (effectively, per the
Return correct fourcc codes on bigendian. Drivers must be adapted to
this change.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_fourcc.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c
14 matches
Mail list logo