The final goal of this code is DRI drivers that can control the hardware without needing to map either the registers or framebuffer. All direct hardware interaction will be handled via the DRM device driver.
The code for the proposed IOCTLs is written and tested. They would be added one at a time. The IOCTLs are designed to support multiple video cards in the same box. 1) GET_VBIOS -- gets a copy of the board's video BIOS ROM. It is implemented generically with a driver specific callout for dealing with bugs like the radeon has. A special case needs to be made for primary video cards. benh and I have talked about adding a kernel PCI quick that records the active video card at boot time; this hasn't been implemented yet. When the quirk gets implemented, calling GET_VBIOS will check this quirk to see if this is the boot card. If so, the ROM image at C000 will be returned. This is needed because some laptops store the VBIOS ROM in the system ROM instead of on the card. Secondary cards will always return the ROM image from the card itself. 2) VGA_ENABLE -- this is used to control the active VGA card in the system. Multiple DRM drivers communicate to ensure only a single VGA card is ever enabled. PCI bridge routing is adjusted when the active VGA card changes. This has two main purposes. First it simply lets you change the active VGA adapter. VGA console will automatically use the active VGA device. Second is for when a secondary adapter is reset. Resetting a secondary adapter enables it's VGA port. This is a problem if you end up with multiple VGA devices enabled. The video-reset program uses this IOCTL to first used to disable the original VGA adapter, the secondary card is then reset, it's VGA port is disabled, and the original VGA port is restored. 3) BLANK - simple call to allow Vesa power management to blank the display. A fourth call will be a driver specific call for setting the video mode. I am implementing this by completely computing the register values needed to set the mode in user space. I then pass these as a struct to the IOCTL and the driver sets the mode. Doing it this way moves about 100K of code (in the radeon case vs framebuffer) out of the kernel and into user space. This call works but it is not clean enough for inclusion yet. ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
