Hi On Fri, Mar 7, 2014 at 10:58 PM, One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx> wrote: >> - The renderer supports *any* RGB target, from 8bit to 32bit with >> big-endian and little-endian support. The related pixel-renderer will >> probably never win a beauty-contest, but it works.. Again, who cares >> for debug-log rendering speed? > > Debug log writing performance is extremely important when you are using > the log for debugging work rather than for panic display. I don't think > that is a show stopper because having a logger makes sense and someone > can write a better render engine if they care. I don't do damage-based rendering (useless if you don't do hw-scrolling), therefore you can easily configure the higher-level API to render in a 50ms (or even 500ms) interval if anything changed. This should be suitable for other use-cases and avoids hogging the CPU like VTs do. Furthermore, you can just avoid rendering until something useful happened that you *want* to see. Last but not least, when something goes wrong, the panic-handler will always print the latest log, so that should contain all useful information. Anyhow, I need specific use-cases to comment on that. > Supporting any target is also going to be useful but you do need to > support non linear framebuffers. A GMA500 with something like an X > display in use for example does not have a linear mapping of the > framebuffer memory. I don't believe its exactly unique in this. Should be fairly easy to do. But as long as you can atomically flip to a linear FB, that's not needed as you can use a separate FB for the render-log (which is also what we currently do for fbdev-fallbacks). But imho most drivers allow you to easily map it linearly via the GTT, so I haven't bothered supported tiled setups. If drivers need that, they can tell me what formats exactly to support and I can add that. > What I am more dubious about is tying it to DRM. Yes it uses DRM > constants but it doesn't appear functionally to have a single tie to > either DRM or even framebuffer. > > It's potentially useful in cases where neither framebuffer or DRM are > compiled into the system. Using the four-cc constants makes sense, imho. Apart from that, drm_log.c will stay generic as it is now. There is nothing DRM-specific in there. All the higher-level helpers are separate in drm_log_helpers.c (which is not posted here). However, I've spent enough time trying to get the attention of core maintainers for simple fixes, I really don't want to waste my time pinging on feature-patches every 5 days to get any attention. If someone outside of DRM wants to use it, I'd be happy to discuss any code-sharing. Until then, I'd like to keep it here as people are willing to take it through their tree. Cheers David _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
