Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[Dave Airlie <airlied@gmail.com>]

>>
>>
>> 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
--