[Dri-devel] Three proposed new generic DRM IOCTLs

[Jon S. <jon...@ya...>]

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
jon...@ya...

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com