From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Simmons Date: Wed, 10 Mar 2010 18:11:29 +0000 Subject: Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video Message-Id: List-Id: References: <21d7e9970911202027l1d4deec6p5750b8425cd6bb3f@mail.gmail.com> <21d7e9971003022102v232c099r441b0bd843b30313@mail.gmail.com> <21d7e9971003030123q2e5d073dj68a81d612e26dc94@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michal Suchanek Cc: Linux Fbdev development list , DRI development list , Paulius Zaleckas > 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.