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
13 matches
Mail list logo