Re: ioctl number 0xF3

[Thomas Winischhofer <thomas@winischhofer.net>]

Arjan van de Ven wrote:
> On Sat, May 22, 2004 at 02:39:47PM +0200, Thomas Winischhofer wrote:
> 
>>I intend using them for controlling SiS hardware specific settings like 
>>switching output devices, checking modes against output devices, 
>>repositioning TV output, scaling TV output, changing gamma correction, 
>>tuning video parameters, and the like.
> 
> 
> That doesn't in principle sound SiS specific. Sure the implementation will
> be but the interface?

Don't get me wrong.. did you ever write a driver for graphics hardware? 
Different graphics cards have widely different features and 
restrictions, for example what output devices are supported and which 
output devices can be "mapped" to what CRT controller, what modes are 
supported on what output device if it's mapped to what CRT controller, 
whether the CRTCs really are independant or of they need "cooperation" 
in specific modes (because one of the CRTCs is crippled like in my case) 
etc etc etc.

Not that this would be much of an excuse, but not even the Windows folks 
have a unique interface for vendor specific things, like setting up dual 
head, video mirroring, etc. IMHO a generic interface will 1) force 
restrictions to supported features, 2) be bloated with stuff that will 
require a ton of checks and thereby lead to a requirement of smart 
userland applications that from the beginning will need to know about 
the specific hardware and its features - again.

What we are talking here are no essential things. What I want is simply 
a few ioctls for mostly (but, granted, not exclusively) very hardware 
specific things (at least as regards the possible arguments to the 
various ioctls).

>>And rest assured, they will be 32/64 bit safe. Not sure what you mean by 
>>"ioctl interface" here but have a look at the Matrox framebuffer driver 
>>which uses some 'n' ioctls for similar stuff (which in that way do not 
>>apply to the SiS hardware which is why I can't reuse them).
> 
> 
> Ok this is exactly the point I was trying to make. Would it be possible to
> have the "new" ioctl interface be such that they CAN be used by both matrox
> and Sis ?

The framebuffer drivers are - I am trying to say this nicely - a chaos 
as regards custom implementations for ioctls and extensions to the 
standard fb ioctls. I do not intend to wait until all the 
maintainers/authors agree on a unique interface which they haven't been 
able to in years.

These ioctls I intend to implement (and partly already have implemented) 
are nothing userland will need to know much about. They are going to be 
used by stuff like DirectFB (which needs a driver for specific hardware 
anyway), my config tool and the X driver (in order to restore the 
hardware state properly, including changes done during the X server 
session while switching back to another VT).

Is 64 out of, what's that, 65536 too much to ask? Well, I could live 
with 32 as well...

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net          http://www.winischhofer.net/
twini AT xfree86 DOT org