> 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. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
