search for: display_target

.... nouveau works because > it only exposes the desired RGB format for the hw. But with other gallium > drivers for some SoC's or future gallium drivers it is not so clear if the > right thing will happen. E.g., freedreno seems to support both BGR and RGB > 10 bit formats as PIPE_BIND_DISPLAY_TARGET afaics, so i don't know if by > luck the right thing would happen? FWIW freedreno does not presently support 10bpc scanout. > > Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs to > DRIconfigs, so we could probably implement dri_loader_get_cap(screen, > D...

...then back into the server/mesa >>> code-base? >> >> >> Can all of this be solved by a healthy dose of "don't do that"? i.e. >> make sure that the DDX only ever exposes one of these at a time? And >> also make the mesa driver only expose one as a DISPLAY_TARGET? >> > > Yes, if "don't do that" is consistently possible on all future drivers. I don't think it'd be undue burden for a driver to have to decide on one ordering which is The Way To Do It (tm) for that hw, even if the hw supports both. Could also drop some logic i...

...because >> it only exposes the desired RGB format for the hw. But with other gallium >> drivers for some SoC's or future gallium drivers it is not so clear if the >> right thing will happen. E.g., freedreno seems to support both BGR and RGB >> 10 bit formats as PIPE_BIND_DISPLAY_TARGET afaics, so i don't know if by >> luck the right thing would happen? > > FWIW freedreno does not presently support 10bpc scanout. > >> >> Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs to >> DRIconfigs, so we could probably implement dr...

In case anyone's curious about 30bpp framebuffer support, here's the current status: Kernel: Ben and I have switched the code to using a 256-based LUT for Kepler+, and I've also written a patch to cause the addfb ioctl to use the proper format. You can pick this up at: https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)