Where are framebuffers/visuals created?

[Bengt Ahlgren]

Theron <theron.tarigo at gmail.com> writes:

> On 9/26/18 9:32 AM, Bengt Ahlgren wrote:
>> I'd like to try to debug and find the cause of this issue with Kwin, but
>> I don't know where in the graphics stack to start digging:
>>
>> https://mail.kde.org/pipermail/kde-freebsd/2018-April/027704.html
>>
>> In short, after an update of Mesa, Kwin complained about not finding the
>> appropriate framebuffer, and refused doing compositing with opengl.
>>
>> So, my question is: where in the graphics stack are the
>> framebuffers/visuals created?
>>
>> Bengt
>> _______________________________________________
>> freebsd-x11 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
>
> Try what others have suggested, but here is one thing to consider: Is
> this is really a framebuffer issue?
>
> From Greg Rivers's Xorg.0.log:
> [    54.162] (==) intel(0): Depth 24, (--) framebuffer bpp 32
> [    54.221] (==) Depth 24 pixmap format is 32 bpp
> Indicates it is indeed a 32-bit framebuffer, so the relaxation of this
> requirement is moot.  Depth 24 is the three out of four channels
> actually used for display.
>
> "Could not find a framebuffer configuration ..." is a very common
> error message across GL applications in case of misconfigured or
> incompatible OpenGL for the reason that opening the framebuffer is the
> first GL-related action performed; it could be a more general OpenGL
> problem not specific to the framebuffer.

Could be.  I have however noticed that when parts - don't know which -
of the graphics stack is updated, the set of X11 visuals change.  For
example, at one time I had BGR visuals that screwed up blue/red display
with some GL applications.  Now there are only RGB visuals on the same
hardware according to xdpyinfo.  But where in the stack are the visuals
created?

Bengt