> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
