Displaying 14 results from an estimated 14 matches for "addfb".
Did you mean:
addb
2018 Sep 19
0
[PATCH v3 3/5] drm/bochs: fix DRM_FORMAT_* handling for big endian machines.
Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the default created by drm_crtc_init(). That way the plane
format list is correct on bigendian machines.
Also re-add the f...
2018 Sep 05
0
[PATCH v2 5/6] drm/bochs: fix DRM_FORMAT_* handling for big endian machines.
Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the default created by drm_crtc_init(). That way the plane
format list is correct on bigendian machines.
With this patch a...
2018 Sep 03
0
[PATCH 4/5] drm/bochs: fix DRM_FORMAT_* handling for big endian machines.
Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code
on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver
feature flag so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the default created by drm_crtc_init(). That way the plane
format list is correct on bigendian machines.
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the...
2018 Sep 05
0
[PATCH v2 6/6] drm/virtio: fix DRM_FORMAT_* handling
Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a different mapping on bigendian machines is wrong.
It's there because of broken drm_mode_addfb() behavior. So with...
2018 Sep 19
0
[PATCH v3 5/5] drm/virtio: fix DRM_FORMAT_* handling
Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a different mapping on bigendian machines is wrong.
It's there because of broken drm_mode_addfb() behavior. So with...
2018 Sep 03
0
[PATCH 5/5] drm/virtio: fix DRM_FORMAT_* handling
Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code
on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver
feature flag so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a different mapping on bigendian machines is wrong.
It's there because of broken drm_mode_addfb() behavior. So with
drm_mode_addfb() being fixed we can fix this too.
While...
2018 Feb 07
2
nouveau 30bpp / deep color status
...n wrote:
> > In case anyone's curious about 30bpp framebuffer support, here's the
> > current status:
> >
> > Kernel:
> >
> > Ben and I have switched the code to using a 256-based LUT for Kepler+,
> > and I've also written a patch to cause the addfb ioctl to use the
> > proper format. You can pick this up at:
> >
> > https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
> > https://patchwork.freedesktop.org/patch/202322/
> >
> > With these two, you should be able to use "X -depth 30&q...
2018 Feb 04
4
nouveau 30bpp / deep color status
In case anyone's curious about 30bpp framebuffer support, here's the
current status:
Kernel:
Ben and I have switched the code to using a 256-based LUT for Kepler+,
and I've also written a patch to cause the addfb ioctl to use the
proper format. You can pick this up at:
https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
https://patchwork.freedesktop.org/patch/202322/
With these two, you should be able to use "X -depth 30" again on any
G80+ GPU to bring up a screen (as you coul...
2018 Mar 05
2
nouveau 30bpp / deep color status
...n wrote:
>>
>> In case anyone's curious about 30bpp framebuffer support, here's the
>> current status:
>>
>> Kernel:
>>
>> Ben and I have switched the code to using a 256-based LUT for Kepler+,
>> and I've also written a patch to cause the addfb ioctl to use the
>> proper format. You can pick this up at:
>>
>> https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
>> https://patchwork.freedesktop.org/patch/202322/
>>
>> With these two, you should be able to use "X -depth 30" aga...
2018 Feb 09
0
nouveau 30bpp / deep color status
...case anyone's curious about 30bpp framebuffer support, here's the
>> > current status:
>> >
>> > Kernel:
>> >
>> > Ben and I have switched the code to using a 256-based LUT for Kepler+,
>> > and I've also written a patch to cause the addfb ioctl to use the
>> > proper format. You can pick this up at:
>> >
>> > https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
>> > https://patchwork.freedesktop.org/patch/202322/
>> >
>> > With these two, you should be able to u...
2018 Feb 07
0
nouveau 30bpp / deep color status
...018 at 06:50:45PM -0500, Ilia Mirkin wrote:
> In case anyone's curious about 30bpp framebuffer support, here's the
> current status:
>
> Kernel:
>
> Ben and I have switched the code to using a 256-based LUT for Kepler+,
> and I've also written a patch to cause the addfb ioctl to use the
> proper format. You can pick this up at:
>
> https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
> https://patchwork.freedesktop.org/patch/202322/
>
> With these two, you should be able to use "X -depth 30" again on any
> G80+ GP...
2018 Mar 08
0
nouveau 30bpp / deep color status
...t; In case anyone's curious about 30bpp framebuffer support, here's the
>>> current status:
>>>
>>> Kernel:
>>>
>>> Ben and I have switched the code to using a 256-based LUT for Kepler+,
>>> and I've also written a patch to cause the addfb ioctl to use the
>>> proper format. You can pick this up at:
>>>
>>> https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
>>> https://patchwork.freedesktop.org/patch/202322/
>>>
>>> With these two, you should be able to use &qu...
2018 Mar 05
0
nouveau 30bpp / deep color status
On 02/05/2018 12:50 AM, Ilia Mirkin wrote:
> In case anyone's curious about 30bpp framebuffer support, here's the
> current status:
>
> Kernel:
>
> Ben and I have switched the code to using a 256-based LUT for Kepler+,
> and I've also written a patch to cause the addfb ioctl to use the
> proper format. You can pick this up at:
>
> https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
> https://patchwork.freedesktop.org/patch/202322/
>
> With these two, you should be able to use "X -depth 30" again on any
> G80+ GP...
2012 Dec 12
43
[PATCH 00/37] [RFC] revamped modeset locking
Hi all,
First thing first: It works, I now no longer have a few dropped frames every 10s
on my testbox here with the pageflip i-g-t tests.
Random notes:
- New design has per-crtc locks to protect the crtc input-side (pageflip,
cursor) for r/w and the output state of the crtc (mode, dpms) as read-only. It
also required completely revamped fb lifecycle management, those are now
refcounted