search for: addfb

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