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

[Michal Suchanek <hramrach@centrum.cz>]

On 3 March 2010 10:23, Dave Airlie <airlied@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&#174; 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