What about modifying the existing fbdev API? You could start with one fbdev device per CRTC and then add a new IOCTL to control the output device. I haven't seen anything yet that justifies abandoning the existing fbdev API.
Then you can't aribtrate properly output hooking is a root level thing, you cannot allow the user in multiseat to just pick his own outputs, if you claim to want a truly flexible interfaces, also the crtc->output mappings aren't always simple, there are limitations on most hw about which crtc can map to which output and when you can clone etc.. putting policy for this stuff in-kernel would heavily restrict what the user can do... At the moment, you can with a small userspace app add two framebuffers, link them to crtcs and link those to outputs, then users can use /dev/fb/* to do what they need, we haven't linked up mode setting so that fbset works yet I don't think, but if people really wanted that we could probably do so... so far we just have enough fbdev to support fbcon... Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
