On 10 March 2010 22:04, Ville Syrjälä <syrjala@xxxxxx> wrote: > 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=fb_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. > I guess it's also possible that somebody would want the fbdev/fbcons cover multiple screens. This is not particularly useful with fbcons (although curses WMs exist) but might be somewhat useful for graphical fbdev applications. Multiple views of the kernel virtual consoles on different heads might be nice toy but it's probably too hard to be worth trying. And there are always applications like jfbterm which could be perhaps slightly adapted to use one of the other devices instead of a vc. Thanks Michal -- 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
