On Tue, Oct 20, 2020 at 1:17 PM Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > > On Mon, Oct 19, 2020 at 3:43 PM Kevin Brace <kevinbrace@xxxxxxx> wrote: > > > > Hi Sam, > > > > Thanks for asking the question. > > The current OpenChrome DRM code has these two major issues. > > > > 1) It does not support atomic modesetting > > > > I do internally have working code to support atomic modesetting, but it is not ready for committing into the upstream OpenChrome DRM repository. > > In particular, it suffers from a freeze relating to a cursor plane. > > The freeze is a bad kind that kern.log does not really tell me what is wrong. > > If I disable hardware cursor, the atomic modesetting based OpenChrome DRM appears to work okay. > > In other words, I am getting close to getting atomic modesetting working, but I am stuck. > > > > > > 2) Double allocation of visible portion of frame buffer > > > > This is a big problem left behind from the previous developer who developed OpenChrome prior to me. > > For some reason, the developer wanted to allocate visible portion of the frame buffer to be the maximum possible size supported by the detected monitor when initializing the frame buffer inside OpenChrome DRM code. > > I believe Radeon DRM does something similar to that. > > The problem is, OpenChrome DDX allocates an equal sized frame buffer visible portion during the DDX's initialization. > > This means that we got two same sized visible portions allocated, but OpenChrome DDX and OpenChrome DRM combined should really be allocating only one. > > At this point, OpenChrome is not supporting double buffering. > > This double allocation of a visible portion of the frame buffer contributes to a X Server crash when the screen is resized and 16 MB or less (i.e., 8 MB) shared frame buffer is reserved by the system via BIOS setup. > > I personally think letting OpenChrome DRM allocate the visible portion of the frame buffer is the way to go, but if so, how do I get the DDX or shadow FB to access the frame buffer visible portion allocated by OpenChrome DRM? > > Any suggestions on what to do about this issue will be greatly appreciated. > > All drivers do this. You have one buffer for the fbdev console and > then userspace allocates buffers it needs in addition, otherwise, > you'd overwrite your console. You can disable it by not enabling the > fbdev emulation if you don't want a console. I don't think disabling fbdev emulation is a practical thing to do for standard PCs. Not sure what the capabilities of the underlying hardware are, but on nouveau, we use 16bpp/8bpp framebuffers by default (for fbdev) on boards with limited VRAM (64/32/16 MB, I don't remember precisely). You'd have to add C8 drm format support for this, but assuming you have that, the core supports it OK. Ideally you'd have logic which is able to manage buffers and move them between GPU-accessible and GPU-inaccessible memory (e.g. TTM, or perhaps some evolution of it, I'm not up on all the latest). Cheers, -ilia _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
