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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
