NVIDIA hardware, prior to Kepler, only supports XBGR2101010. However drmAddFB with depth = 30 will use the mapping in drm_mode_legacy_fb_format and pick the XRGB version of the format.
One solution is to tell userspace "stop using addfb, move to addfb2". However I'm hoping that there's some sort of semi-clean way of dealing with such driver eccentricities without resorting to changing userspace.
Can the ioctl be handled in the driver perhaps? Or would it be reasonable to add a callback in drm_driver?
Suggestions welcome.
-ilia
On Sun, Dec 31, 2017 at 01:03:39AM -0500, Ilia Mirkin wrote:
NVIDIA hardware, prior to Kepler, only supports XBGR2101010. However drmAddFB with depth = 30 will use the mapping in drm_mode_legacy_fb_format and pick the XRGB version of the format.
One solution is to tell userspace "stop using addfb, move to addfb2". However I'm hoping that there's some sort of semi-clean way of dealing with such driver eccentricities without resorting to changing userspace.
Can the ioctl be handled in the driver perhaps? Or would it be reasonable to add a callback in drm_driver?
I don't think there's any sane way to allow the driver to remap these. How would generic userspace know which component order the driver actually picked?
Quoting Ville Syrjälä (2018-01-09 15:19:06)
On Sun, Dec 31, 2017 at 01:03:39AM -0500, Ilia Mirkin wrote:
NVIDIA hardware, prior to Kepler, only supports XBGR2101010. However drmAddFB with depth = 30 will use the mapping in drm_mode_legacy_fb_format and pick the XRGB version of the format.
One solution is to tell userspace "stop using addfb, move to addfb2". However I'm hoping that there's some sort of semi-clean way of dealing with such driver eccentricities without resorting to changing userspace.
Can the ioctl be handled in the driver perhaps? Or would it be reasonable to add a callback in drm_driver?
I don't think there's any sane way to allow the driver to remap these. How would generic userspace know which component order the driver actually picked?
With getfb? Wait, I'll get my coat. -Chris
On Tue, Jan 09, 2018 at 03:28:23PM +0000, Chris Wilson wrote:
Quoting Ville Syrjälä (2018-01-09 15:19:06)
On Sun, Dec 31, 2017 at 01:03:39AM -0500, Ilia Mirkin wrote:
NVIDIA hardware, prior to Kepler, only supports XBGR2101010. However drmAddFB with depth = 30 will use the mapping in drm_mode_legacy_fb_format and pick the XRGB version of the format.
One solution is to tell userspace "stop using addfb, move to addfb2". However I'm hoping that there's some sort of semi-clean way of dealing with such driver eccentricities without resorting to changing userspace.
Can the ioctl be handled in the driver perhaps? Or would it be reasonable to add a callback in drm_driver?
I don't think there's any sane way to allow the driver to remap these. How would generic userspace know which component order the driver actually picked?
With getfb? Wait, I'll get my coat.
debugfs would dump the actual pixel format, at least in 4.16 :-) -Daniel
On Tue, Jan 09, 2018 at 05:19:06PM +0200, Ville Syrjälä wrote:
On Sun, Dec 31, 2017 at 01:03:39AM -0500, Ilia Mirkin wrote:
NVIDIA hardware, prior to Kepler, only supports XBGR2101010. However drmAddFB with depth = 30 will use the mapping in drm_mode_legacy_fb_format and pick the XRGB version of the format.
One solution is to tell userspace "stop using addfb, move to addfb2". However I'm hoping that there's some sort of semi-clean way of dealing with such driver eccentricities without resorting to changing userspace.
Can the ioctl be handled in the driver perhaps? Or would it be reasonable to add a callback in drm_driver?
I don't think there's any sane way to allow the driver to remap these. How would generic userspace know which component order the driver actually picked?
By using addfb2. That seems the only option, and it'll likely result in a bunch more "nouveau is crap" forum posts when people try to use 30bpp with generic userspace on nouveau. Best we can do is drop a info_once message into dmesg that userspace should consider using addfb2.
Ilia said he's ok with more "nouveau is crap", and that's about the only option we have any.
Wrt implementation: A flag in drm_mode_config that overwrites the choice in drm_addfb_ioctl (so that we can avoid going through all the drivers), plus the same hack in the fbdev probe callback in nouveau is probably the least invasive. Core one with a very huge comment ofc. -Daniel
dri-devel@lists.freedesktop.org
-
Chris Wilson -
Daniel Vetter -
Ilia Mirkin -
Ville Syrjälä