On Sun, Mar 17, 2024 at 08:18:57PM +0100, Frej Drejhammar wrote: > Hi Kevin, > > Kevin Hao <haokexin@xxxxxxxxx> writes: > > > But after kernel commit c91acda3a380, the FB will not be created > > successfully due to the check of the valid pixel format. Then the bpp > > is set to 24, but the 'depth = 16' and 'bpp = 24' combo is not a valid > > pixel format. > > > > Fix this issue by explicitly setting the preferred_depth in this driver. > > With this change, the modesetting driver would choose the correct > > depth/bpp combo based on our setting in xorg.conf. > > Check the fix in [1], with it not only does the X-server work with a > color depth of 16 bits, it also enables the use of a 24 bit color depth. Thank you, Frej. I didn't notice your patch before sending mine. > > As I'm the author of the solution in [1] I'm partial to it as it is a > more general solution to the regression. Agreed. >I have no standing in this > community as [1] is my first contribution to the DRM system, but if I > had, I would NAK this patch as it only fixes the regression for one > driver and does not enable the use of a 24 bit color depth which is > something the hardware is capable of. I had also thought about a similar modification before, but personally, I considered such changes a bit aggressive for a patch that needs to be backported to a stable kernel (especially for a LTS kernel such as v6.6 which I am working on). That's why I opted for minimal changes to fix this regression, reducing the risk when we backport it to the stable kernel. Additionally, my patch and your patch don't conflict semantically, and setting a driver's preferred_depth shouldn't cause any other issues. Thanks, Kevin
Attachment:
signature.asc
Description: PGP signature
