On 3 March 2010 10:23, Dave Airlie <airl...@gmail.com> wrote: >>> >>> >>> 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.
I don't think so. There is another driver which does this - vesa/uvesa. For these it is not possible to change the resolution from fbdev, it just provides some framebuffer on top of which fb applications or fbcons run. You set the proper options on the proper layer - fonts in fbcons, resolution in fbdev or the driver (which sucks but so far nobody came up with a modesetting solution universal enough to work with all drivers), and some hardware-specific options in the driver as well. Still if most framebuffer drivers are converted to KMS there would not be interface discrepancies. KMS would be used to set resolution and fbdev to draw on the screen. > > 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. > I guess equivalent of xrandr would be what people would want but the current fbdev capabilities are far from that. Since KMS provides these capabilities already I would think adding a tool that manipulates KMS directly (kmset?) is the simplest way. There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Designing an unified multihead fbdev extension interface would probably take quite a bit of typing and time. It would also help to have something working to compare to. Thanks Michal ------------------------------------------------------------------------------ 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
