Hi, Jyri
sa...@kapsi.fi writes:
> So the trouble here is the 16bpp and 24/32bpp color wiring being
> crossed, right? I'd just like to remind that there is another option
> to overcome the issue by editing device tree files. The current
> configuration from some 8 years back supports RG16, BG24,
March 17, 2024 at 9:18 PM, "Frej Drejhammar" mailto:frej.drejham...@gmail.com?to=%22Frej%20Drejhammar%22%20%3Cfrej.drejhammar%40gmail.com%3E
> wrote:
>
> Hi Kevin,
>
> Kevin Hao writes:
>
> >
> > But after kernel commit c91acda3a380, the FB will not be created
> > successfully due to the
Hi, Kevin
Kevin Hao writes:
> 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
On Sun, Mar 17, 2024 at 08:18:57PM +0100, Frej Drejhammar wrote:
> Hi Kevin,
>
> Kevin Hao 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 =
Hi Kevin,
Kevin Hao 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
The commit c91acda3a380 ("drm/gem: Check for valid formats") adds a
check for valid pixel formats on drm_gem_fb_create(), but this breaks
the X server on the beaglebone black board.
We have set 'DefaultDepth' to 16 in our xorg.conf. In the X modesetting
driver, the drmmode_get_default_bpp() is
