On Thu, May 11, 2017 at 11:23:11PM +0200, Pavel Machek wrote:
> On Fri 2017-04-21 14:08:04, Ville Syrjälä wrote:
> > On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> > > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd
On Fri 2017-04-21 14:08:04, Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > > > While working on graphics support for virtual
On 25/04/17 07:26 PM, Ville Syrjälä wrote:
> On Tue, Apr 25, 2017 at 10:12:37AM +0900, Michel Dänzer wrote:
>> On 24/04/17 10:03 PM, Ville Syrjälä wrote:
>>> On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote:
On 22/04/17 07:05 PM, Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at
On Tue, Apr 25, 2017 at 10:12:37AM +0900, Michel Dänzer wrote:
> On 24/04/17 10:03 PM, Ville Syrjälä wrote:
> > On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote:
> >> On 22/04/17 07:05 PM, Ville Syrjälä wrote:
> >>> On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote:
>
On 25/04/17 10:12 AM, Michel Dänzer wrote:
> On 24/04/17 10:03 PM, Ville Syrjälä wrote:
>> On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote:
>>> On 22/04/17 07:05 PM, Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote:
> Hi,
>
>>> My
On 24/04/17 10:03 PM, Ville Syrjälä wrote:
> On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote:
>> On 22/04/17 07:05 PM, Ville Syrjälä wrote:
>>> On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote:
Hi,
>> My personal opinion is that formats in drm_fourcc.h
On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote:
> On 22/04/17 07:05 PM, Ville Syrjälä wrote:
> > On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote:
> >> Hi,
> >>
> My personal opinion is that formats in drm_fourcc.h should be
> independent of the CPU byte
On 22/04/17 07:05 PM, Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote:
>> Hi,
>>
My personal opinion is that formats in drm_fourcc.h should be
independent of the CPU byte order and the function
drm_mode_legacy_fb_format() and drivers
On 23/04/17 04:24 AM, Ilia Mirkin wrote:
>
> fbdev also creates fb's that expect cpu endianness, as disabling the
> byteswap logic caused a green fbcon terminal to show up. (So at least
> something somewhere in the fbcon -> nouveau's fbdev emulation pipeline
> is expecting cpu endianness. This
Hi,
> > I guess that makes changing drm_mode_legacy_fb_format + drivers a
> > reasonable option ...
>
> Yeah, I came to the same conclusion after chatting with some
> folks on irc.
>
> So my current idea is that we change any driver that wants to follow the
> CPU endianness to declare support
On Sat, Apr 22, 2017 at 9:48 AM, Ilia Mirkin wrote:
> On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin wrote:
>> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
>> wrote:
>>> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia
On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin wrote:
> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
> wrote:
>> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote:
>>> On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
>>>
On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
wrote:
> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote:
>> On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
>> wrote:
>> > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia
On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > My personal opinion is that formats in drm_fourcc.h should be
> > > independent of the CPU byte order and the function
> > > drm_mode_legacy_fb_format() and drivers depending on that incorrect
> > > assumption be
On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote:
> On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
> wrote:
> > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
> >> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote:
>
On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
wrote:
> On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
>> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote:
>> > While working on graphics support for virtual machines on ppc64
Hi,
> > My personal opinion is that formats in drm_fourcc.h should be
> > independent of the CPU byte order and the function
> > drm_mode_legacy_fb_format() and drivers depending on that incorrect
> > assumption be fixed instead.
>
> The problem is this isn't a kernel-internal thing any
On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote:
> > While working on graphics support for virtual machines on ppc64 (which
> > exists in both little and big endian variants) I've figured the comments
> > for
Thanks, Christian for adding me.
On 2017-04-21 09:27 AM, Christian König wrote:
Adding Harry to this mail thread as well, cause is one of the people
really affected by this.
Christian.
Am 21.04.2017 um 15:21 schrieb Christian König:
Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann:
Hi,
On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote:
> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
>
>
Adding Harry to this mail thread as well, cause is one of the people
really affected by this.
Christian.
Am 21.04.2017 um 15:21 schrieb Christian König:
Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann:
Hi,
"native" to me feels more like "native to the GPU" since these things
really are
Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann:
Hi,
"native" to me feels more like "native to the GPU" since these things
really are tied to the GPU not the CPU. That's also why I went with the
explicit endianness originally so that the driver could properly declare
what the GPU supports.
Hi,
> > "native" to me feels more like "native to the GPU" since these things
> > really are tied to the GPU not the CPU. That's also why I went with the
> > explicit endianness originally so that the driver could properly declare
> > what the GPU supports.
> And to be honest I would really
Am 21.04.2017 um 13:49 schrieb Ville Syrjälä:
On Fri, Apr 21, 2017 at 02:40:18PM +0300, Pekka Paalanen wrote:
On Fri, 21 Apr 2017 14:08:04 +0300
Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
On Fr, 2017-04-21 at 12:25
Am 21.04.2017 um 13:08 schrieb Ville Syrjälä:
On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
While working on graphics support for virtual machines on ppc64
On Fri, Apr 21, 2017 at 02:40:18PM +0300, Pekka Paalanen wrote:
> On Fri, 21 Apr 2017 14:08:04 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> > > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > > >
Hi,
> > I personally find "native" more intuitive, but at the end of the day I
> > don't mind much. If people prefer "host" over "native" I'll change it.
>
> "native" to me feels more like "native to the GPU" since these things
> really are tied to the GPU not the CPU.
Ok, then maybe "host"
On Fri, 21 Apr 2017 14:08:04 +0300
Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > > >
On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > > While working on graphics support for virtual machines on ppc64 (which
> > > exists in both little and
On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > > While working on graphics support for virtual machines on ppc64 (which
> > > exists in both little and
On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > While working on graphics support for virtual machines on ppc64 (which
> > exists in both little and big endian variants) I've figured the comments
> > for various drm fourcc
On Fri, Apr 21, 2017 at 11:38:28AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Leaving the yuv formats as-is. I have no idea if and how those are used
> > > on bigendian machines.
>
> > just an idea - since we are not sure how the remaining formats are being
> > used, should those be marked
Hi,
> > Leaving the yuv formats as-is. I have no idea if and how those are used
> > on bigendian machines.
> just an idea - since we are not sure how the remaining formats are being
> used, should those be marked somehow uncertain whether they are little
> or native endian?
ATM the yuv don't
On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
>
> Comments
On Fri, 21 Apr 2017 09:58:24 +0200
Gerd Hoffmann wrote:
> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
While working on graphics support for virtual machines on ppc64 (which
exists in both little and big endian variants) I've figured the comments
for various drm fourcc formats in the header file don't match reality.
Comments says the RGB formats are little endian, but in practice they
are native
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
> > >
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
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
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
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
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,
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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 &
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
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
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
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
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
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
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
64 matches
Mail list logo