Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses > > >> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses > > >> native endian packed colour values. > > > > > > Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get > > >

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses > > >> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses > > >> native endian packed colour values. > > > > > > Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get > > >

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Wed, 19 Apr 2017 10:01:47 +0900 Michel Dänzer wrote: > On 18/04/17 07:14 PM, Gerd Hoffmann wrote: > > Hi, > > > >>> Quite true that this proves nothing. However one should note that > >>> fbcon -> fbdev works, > >> > >> BTW, this supports Gerd's patch, since the KMS

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Wed, 19 Apr 2017 10:01:47 +0900 Michel Dänzer wrote: > On 18/04/17 07:14 PM, Gerd Hoffmann wrote: > > Hi, > > > >>> Quite true that this proves nothing. However one should note that > >>> fbcon -> fbdev works, > >> > >> BTW, this supports Gerd's patch, since the KMS fbdev emulation

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 18, 2017 at 11:19 PM, Ilia Mirkin wrote: > On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote: >> On 18/04/17 07:14 PM, Gerd Hoffmann wrote: >>> Hi, >>> > Quite true that this proves nothing. However one should note that > fbcon

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 18, 2017 at 11:19 PM, Ilia Mirkin wrote: > On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote: >> On 18/04/17 07:14 PM, Gerd Hoffmann wrote: >>> Hi, >>> > Quite true that this proves nothing. However one should note that > fbcon -> fbdev works, BTW, this

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote: > On 18/04/17 07:14 PM, Gerd Hoffmann wrote: >> Hi, >> Quite true that this proves nothing. However one should note that fbcon -> fbdev works, >>> >>> BTW, this supports Gerd's patch, since the KMS fbdev

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote: > On 18/04/17 07:14 PM, Gerd Hoffmann wrote: >> Hi, >> Quite true that this proves nothing. However one should note that fbcon -> fbdev works, >>> >>> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses >>>

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 18/04/17 07:14 PM, Gerd Hoffmann wrote: > Hi, > >>> Quite true that this proves nothing. However one should note that >>> fbcon -> fbdev works, >> >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses >> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 18/04/17 07:14 PM, Gerd Hoffmann wrote: > Hi, > >>> Quite true that this proves nothing. However one should note that >>> fbcon -> fbdev works, >> >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses >> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > Right. Very nice if we can trust the virtual machine at least getting > things right, gives some chance for people to test anything. Except... > that's a question of what kind of hardware the virtual machine > emulates. The display device defines what endianess it uses on > framebuffers,

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > Right. Very nice if we can trust the virtual machine at least getting > things right, gives some chance for people to test anything. Except... > that's a question of what kind of hardware the virtual machine > emulates. The display device defines what endianess it uses on > framebuffers,

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, 18 Apr 2017 15:39:53 +0200 Gerd Hoffmann wrote: > Hi, > > > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest > > > here, it drives the qemu stdvga with offb, not bochs-drm. > > > > I suppose this proves the virtual machine itself is

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, 18 Apr 2017 15:39:53 +0200 Gerd Hoffmann wrote: > Hi, > > > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest > > > here, it drives the qemu stdvga with offb, not bochs-drm. > > > > I suppose this proves the virtual machine itself is correct about > >

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest > > here, it drives the qemu stdvga with offb, not bochs-drm. > > I suppose this proves the virtual machine itself is correct about > framebuffer endianess? Except you are running it on a little-endian > host

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest > > here, it drives the qemu stdvga with offb, not bochs-drm. > > I suppose this proves the virtual machine itself is correct about > framebuffer endianess? Except you are running it on a little-endian > host

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, 18 Apr 2017 12:00:17 +0200 Gerd Hoffmann wrote: > Hi, > > > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > > > only format supported by bochs-drm), and we

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, 18 Apr 2017 12:00:17 +0200 Gerd Hoffmann wrote: > Hi, > > > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > > > only format supported by bochs-drm), and we have to interpret that

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > Quite true that this proves nothing. However one should note that > > fbcon -> fbdev works, > > BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses > e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses > native endian packed colour values. Same is

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > Quite true that this proves nothing. However one should note that > > fbcon -> fbdev works, > > BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses > e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses > native endian packed colour values. Same is

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > > only format supported by bochs-drm), and we have to interpret that in > > bigendian byte order on the host side to get a correct

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > > only format supported by bochs-drm), and we have to interpret that in > > bigendian byte order on the host side to get a correct

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 18/04/17 02:04 PM, Ilia Mirkin wrote: > On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote: >> On 17/04/17 03:43 PM, Ilia Mirkin wrote: >>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: > However, I totally agree with Alex that someone

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 18/04/17 02:04 PM, Ilia Mirkin wrote: > On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote: >> On 17/04/17 03:43 PM, Ilia Mirkin wrote: >>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: > However, I totally agree with Alex that someone with a BE machine > should review the

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote: > On 17/04/17 03:43 PM, Ilia Mirkin wrote: >> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: However, I totally agree with Alex that someone with a BE machine should review the whole

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote: > On 17/04/17 03:43 PM, Ilia Mirkin wrote: >> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: However, I totally agree with Alex that someone with a BE machine should review the whole stack before we could be confident with

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 17/04/17 03:43 PM, Ilia Mirkin wrote: > On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: >>> However, I totally agree with Alex that someone with a BE machine >>> should review the whole stack before we could be confident with anything. >> >> Here's what I'm confident

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On 17/04/17 03:43 PM, Ilia Mirkin wrote: > On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: >>> However, I totally agree with Alex that someone with a BE machine >>> should review the whole stack before we could be confident with anything. >> >> Here's what I'm confident about:

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: >> However, I totally agree with Alex that someone with a BE machine >> should review the whole stack before we could be confident with anything. > > Here's what I'm confident about: xf86-video-nouveau worked just fine >

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: >> However, I totally agree with Alex that someone with a BE machine >> should review the whole stack before we could be confident with anything. > > Here's what I'm confident about: xf86-video-nouveau worked just fine > on top of kernel 4.3 on

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, 11 Apr 2017 13:23:53 +0200 Gerd Hoffmann wrote: > Hi, > > > > Just let know what you need tested, I should be able to turn it around > > > within a couple of days. > > > > That's part of my problem. I don't really know what should be tested. > > What do people do

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, 11 Apr 2017 13:23:53 +0200 Gerd Hoffmann wrote: > Hi, > > > > Just let know what you need tested, I should be able to turn it around > > > within a couple of days. > > > > That's part of my problem. I don't really know what should be tested. > > What do people do with their BE

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 11, 2017 at 3:31 AM, Pekka Paalanen wrote: > On Mon, 10 Apr 2017 12:10:14 -0400 > Ilia Mirkin wrote: > >> On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote: > >> > I also wonder if a real BE machine could have

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 11, 2017 at 3:31 AM, Pekka Paalanen wrote: > On Mon, 10 Apr 2017 12:10:14 -0400 > Ilia Mirkin wrote: > >> On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote: > >> > I also wonder if a real BE machine could have different results than >> > the virtual machine. >> >> I have a PPC

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > Just let know what you need tested, I should be able to turn it around > > within a couple of days. > > That's part of my problem. I don't really know what should be tested. > What do people do with their BE machines that we should avoid breaking? For the virtual machine use case the

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > Just let know what you need tested, I should be able to turn it around > > within a couple of days. > > That's part of my problem. I don't really know what should be tested. > What do people do with their BE machines that we should avoid breaking? For the virtual machine use case the

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 12:10:14 -0400 Ilia Mirkin wrote: > On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote: > > I also wonder if a real BE machine could have different results than > > the virtual machine. > > I have a PPC G5 with an AGP

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 12:10:14 -0400 Ilia Mirkin wrote: > On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote: > > I also wonder if a real BE machine could have different results than > > the virtual machine. > > I have a PPC G5 with an AGP GeForce FX 5200 that I can test things on, > if

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 8:02 AM, Daniel Vetter wrote: > On Mon, Apr 10, 2017 at 12:12:01PM +0200, Gerd Hoffmann wrote: >> Ok, this is really a kickstart for a discussion. While working on >> graphics support for virtual machines on ppc64 (which exists in both >> little and big

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 8:02 AM, Daniel Vetter wrote: > On Mon, Apr 10, 2017 at 12:12:01PM +0200, Gerd Hoffmann wrote: >> Ok, this is really a kickstart for a discussion. While working on >> graphics support for virtual machines on ppc64 (which exists in both >> little and big endian variants)

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 10:45 AM, Ilia Mirkin wrote: > On Mon, Apr 10, 2017 at 10:17 AM, Gerd Hoffmann wrote: >> Hi, >> >>> which software have you used as representative of "reality"? >> >> ppc64 (big endian) virtual machine, running with qemu stdvga &

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 10:45 AM, Ilia Mirkin wrote: > On Mon, Apr 10, 2017 at 10:17 AM, Gerd Hoffmann wrote: >> Hi, >> >>> which software have you used as representative of "reality"? >> >> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm >> driver. Xorg with

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote: > On Mon, 10 Apr 2017 16:17:27 +0200 > Gerd Hoffmann wrote: > >> Hi, >> >> > which software have you used as representative of "reality"? >> >> ppc64 (big endian) virtual machine, running with qemu

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote: > On Mon, 10 Apr 2017 16:17:27 +0200 > Gerd Hoffmann wrote: > >> Hi, >> >> > which software have you used as representative of "reality"? >> >> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm >> driver. Xorg with

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 16:17:27 +0200 Gerd Hoffmann wrote: > Hi, > > > which software have you used as representative of "reality"? > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 16:17:27 +0200 Gerd Hoffmann wrote: > Hi, > > > which software have you used as representative of "reality"? > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > only

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 10:17 AM, Gerd Hoffmann wrote: > Hi, > >> which software have you used as representative of "reality"? > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 10:17 AM, Gerd Hoffmann wrote: > Hi, > >> which software have you used as representative of "reality"? > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > only format

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > which software have you used as representative of "reality"? ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and only format supported by bochs-drm), and we have to interpret that in bigendian

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > which software have you used as representative of "reality"? ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and only format supported by bochs-drm), and we have to interpret that in bigendian

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 12:12:01 +0200 Gerd Hoffmann wrote: > Ok, this is really a kickstart for a discussion. While working on > graphics support for virtual machines on ppc64 (which exists in both > little and big endian variants) I've figured the comments in the header > file

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, 10 Apr 2017 12:12:01 +0200 Gerd Hoffmann wrote: > Ok, this is really a kickstart for a discussion. While working on > graphics support for virtual machines on ppc64 (which exists in both > little and big endian variants) I've figured the comments in the header > file don't match

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 12:12:01PM +0200, Gerd Hoffmann wrote: > Ok, this is really a kickstart for a discussion. While working on > graphics support for virtual machines on ppc64 (which exists in both > little and big endian variants) I've figured the comments in the header > file don't match

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 12:12:01PM +0200, Gerd Hoffmann wrote: > Ok, this is really a kickstart for a discussion. While working on > graphics support for virtual machines on ppc64 (which exists in both > little and big endian variants) I've figured the comments in the header > file don't match

[RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Ok, this is really a kickstart for a discussion. While working on graphics support for virtual machines on ppc64 (which exists in both little and big endian variants) I've figured the comments in the header file don't match reality. They are not considered little endian (as suggested by the

[RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Ok, this is really a kickstart for a discussion. While working on graphics support for virtual machines on ppc64 (which exists in both little and big endian variants) I've figured the comments in the header file don't match reality. They are not considered little endian (as suggested by the