>> >> >> I've only really got two answer for this: >> >> (a) hook up another /dev/dri/card_fb device and use the current KMS >> ioctls to control the framebuffer, have the drm callback into fbdev/fbcon >> to mention resizes etc. Or add one or two info gathering ioctls and >> allow use of the /dev/dri/control device to control stuff. >> > > What about writing a drmfbset or something and have fbset call it when > it detects a drm framebuffer and warn that it does not support drm > framebuffers fully? >
My main problem with calling the drm underneath the fbdev is it seems like a layering violation. Then again some of code in the kernel is also contributing to this violation. I'd really like to make fbdev more like an in-kernel version of what X driver have to do, and leave all the initial modepicking etc to the fbdev interface layer. If we take the layering as fbcon -> fbdev -> kms -> hw I feel calling ioctls on the KMS layer from userspace to do stuff for fbcon or fbdev is wrong, and we should rather expose a more intelligent set of ioctls via the fbdev device node. This points at quite a bit of typing. So we'd need to add a bunch of KMS fb specifc ioctl like some of the other fbdev drivers do, and then a new fbset could tkae advantage of these. I'm not sure how much different to the current kms interface or how powerful we really need to make tihs interface though, and I feel kinda bad implementing it without some idea what users would want from it. Dave. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
