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

["Ville Syrjälä" <syrjala@sci.fi>]

On Wed, Mar 10, 2010 at 06:11:29PM +0000, James Simmons wrote:
> 
> > 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.
> 
> Only because that is the only way to do it. The other options was to have 
> x86emul in the kernel. That was not going to happen.
>  
> > 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.
> 
> Still would have to deal with the issue of keeping the graphical console 
> in sync with the changes.
>  
> > There are other drivers that support multihead already (matroxfb, any
> > other?) and have their own driver-specific inteface.
> 
> Each crtc is treated as a seperate fbdev device. I don't recall any 
> special ioctls. Maybe for mirroring which was never standardized.

matroxfb does have a bunch of custom ioctls to change the crtc<->output
mapping. omapfb is another multihead fb driver and it's more complex
than matroxfb. Trying to make it perform various tricks through the
fbdev API (and a bunch of custom ioctls, and a bunch of sysfs knobs)
is something I've been doing but I would not recommend it for anyone
who has the option of using a better API.

I don't think the CRTCû_info makes much sense if the main use
case is fbcon. fbcon will use a single fb device and so you can't see
the console on multiple heads anyway which makes the whole thing
somewhat pointless. And if you're trying to do something more complex
you will be a lot better off bypassing fbdev altogether.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/