Hi On 19.10.20 22:28, Sam Ravnborg wrote: > Hi Kevin. > > On Mon, Oct 19, 2020 at 09:43:08PM +0200, Kevin Brace 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. > Maybe posting what you have now - and explain that it has this defect. > Chances are that you will receive feedback that may help you on your way > to fix this. > > With all the infrastructure improvements made the last years I would be > suprised if you have managed to include it all and maybe some of the > infrastructure may help you. > > Also I know we have seems some cursor plane related discussions the last > months so maybe there are something to gain from the people involved > there.
I'd be interested in this as well. If you could share an URL to the repo, I'd take a look. I think I even have a Via machine somewhere to give it a try. Best regards Thomas > > >> 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. >> Perhaps, I should post a question to dri-devel regarding this issue. >> I really do not know what I should do at this point. > Likewise. > > But obviously you shall not post it to dri-devel unless you are prepared > to handle the feedback that you *may* get. > > I promise to take a look - but that will cover mostly trivial stuff. > You have to rely on others for all the stuff around atomic modestetting > and the memory handling etc. - the areas where you have challenges now. > > Sam > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
