> 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 agree. We had the same issue with fbdev and fbcon. From the
fbcon layer you can call stty to change the resolution. In that case the
mode change came from fbcon to fbdev. Easy problem to handle. Well some
people still wanted to be able to able to change their console resolution
with fbset. Not only change the resolution on one VC (virtual consoel) but
in some cases change the resolution on all the VCs mapped to that fbdev.
Now some times the user wanted to change the resolution for say a game (using
SDL for example) and then expected the fbcon resolution to be restored
when they exited. In that case we wanted the resolution change not to be
propagated up to the fbcon layer. The way the fbdev changes are propagated
with a notifier chain. Now the issue of mirroring is another thing which
was never settled on.
Considering now the KMS layer is not so bad as it seems. The fbdev
emulation layer already changes the drm mode (fbdev -> kms) plus in that
case you get the benefit of automatically sending a signal to the fbcon
layer to keep it in sync. In the case of kms -> fbdev you need to update
the fbdev state. This could be done pretty easily plus if done right would
update the fbcon state as well.
------------------------------------------------------------------------------
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
