> 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. > Designing an unified multihead fbdev extension interface would > probably take quite a bit of typing and time. It would also help to > have something working to compare to. IMNSHO the fbdev to ctrc mapping should be the standard way to handle the fbdev layer. Plus it is a KISS approach. Mirroring would need to be finally dealt with. -- 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
