On Tue, Apr 25, 2017 at 09:49:38AM +0900, Michel Dänzer wrote:
> On 24/04/17 11:26 PM, Ville Syrjälä wrote:
> > On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote:
> >> On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
> >>>
> > drm: fourcc byteorder: add DRM_FORMAT_CPU_*
> > drm:
On 24/04/17 11:26 PM, Ville Syrjälä wrote:
> On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote:
>> On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
>>>
> drm: fourcc byteorder: add DRM_FORMAT_CPU_*
> drm: fourcc byteorder: add bigendian support to
>
On Mon, Apr 24, 2017 at 05:26:03PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote:
> > On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
> > >
> > >>> drm: fourcc byteorder: add DRM_FORMAT_CPU_*
> > >>> drm: fourcc byteorder: add bigendian support to
> >
Hi,
On 24 April 2017 at 15:26, Ville Syrjälä wrote:
> On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote:
>> On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
>> > When running in opengl mode there will be a hardware-specific mesa
>> > driver in userspace,
On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote:
> On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
> >
> >>> drm: fourcc byteorder: add DRM_FORMAT_CPU_*
> >>> drm: fourcc byteorder: add bigendian support to
> >>> drm_mode_legacy_fb_format
> >>
> >> As I explained in my last
On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
>
>>> drm: fourcc byteorder: add DRM_FORMAT_CPU_*
>>> drm: fourcc byteorder: add bigendian support to
>>> drm_mode_legacy_fb_format
>>
>> As I explained in my last followup in the "[PATCH] drm: fourcc
>> byteorder: brings header file comments in
On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> Hi,
>
> Ok, different approach up for discussion. Given that userspace didn't
> made the transition from ADDFB to ADDFB2 yet it seems we still can muck
> with the fourcc codes without breaking everything, as long as we
> maintain ADDFB and fbdev
Hi,
Ok, different approach up for discussion. Given that userspace didn't
made the transition from ADDFB to ADDFB2 yet it seems we still can muck
with the fourcc codes without breaking everything, as long as we
maintain ADDFB and fbdev behavior (use cpu byte order format) so nothing
changes