Hi Daniel. > > > > > > *Any* hints why modetest fails when my driver reports the correct formats? > > > > Every driver to date supports XR24. So modetest uses that by default. > > But this fails with your driver since it's an unsupported format. > > Something like: > > > > modetest -M atmel-lcdc -s 34:800x480-60Hz@XB24 > > > > should do the trick. The quirk covers drivers that use AddFB(). > > However modetest is fancy and uses AddFB2, which takes an explicit > > format. > > Yeah I thinki for fbdev the correct fix is to look whether the driver > enabled atomic and if so, consult the fourcc format list of the > primary plane of the first crtc to figure out what you might actually > have set. Without atomic you can't realy on the format list being > correct since for drivers who get the default primary plane that > drm_crtc_init sets up the format list is garbage. I do not follow you here. # modetest -M atmel-lcdc -p Planes: id crtc fb CRTC x,y x,y gamma size possible crtcs 31 32 35 0,0 0,0 0 0x00000001 formats: XB24 BG24 BG16 # modetest -M atmel-lcdc -a -p Planes: id crtc fb CRTC x,y x,y gamma size possible crtcs 31 32 35 0,0 0,0 0 0x00000001 formats: XB24 BG24 BG16 So with or without atomic (-a option) the driver reports the same formats. # modetest -M atmel-lcdc -a -s ... does not work btw. It just exists without anything shown on the panel. > Reworking the entire > fbdev emulation to use fourcc codes would be even more awesome I > guess. To take the bait I would need a little bit more guidiance on this. Is it something like: - New variant af drm_fbdev_generic_setup() that takes a fourcc code, not a preferred_bpp - drm_fb_helper_initial_config likewise - drm_fb_helper_fbdev_setup likewise - drm_fb_helper_single_fb_probe likewise And then work through all the code until we no longer rely on preferred_bpp?? Sam _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel