On Sat, Feb 4, 2012 at 10:47 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > On Fri, Feb 03, 2012 at 10:04:27AM +0000, Dave Airlie wrote: >> On Wed, Feb 1, 2012 at 10:38 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: >> > The fb helper uses fixed size arrays for the associated crtcs. >> > This is an unnecessary limitation, so instead use a list to >> > store the crtcs and allocate them dynamically. >> >> I need more reasons on why this is a unnecessary limitation, for what? >> >> Its a lot less cache friendly to use a linked list here for not much gain, > > How often do you change modes? This code is run when the user changes > virtual terminals, which is not very performance critical. But why make it worse unless you have a good reason? > I am working on a mid layer to connect simple framebuffer devices to > kms and it would be convenient to just add a crtc to a drm device once > it appears. This works fine for connectors and encoders, why not also > for crtcs? I'd like to see the midlayer before changing the core too much, I hate midlayers as they always cause more pain in the long run than they solve, the DRM is one of the worst examples of midlayer design and I'd rather not propogate it any further. Hopefully you meant to say you are working on a set of helper functions that kms drivers for simple framebuffers can use, btw what is going to count as a simple framebuffer device? 1 crtc/connector? I've got to write a bunch of "simple" kms drivers but I'd really rather this developed the other way. Write a drivers for two simple devices, then carve the common code into helpers. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
