ioctl number 0xF3

ioctl number 0xF3

[Thomas Winischhofer]

I would like to reserve ioctl's 0xF3 00-40 for the SiS framebuffer 
device driver (2.4 and 2.6).

Any oppositions?

Thomas

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

Re: ioctl number 0xF3

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On Sat, 2004-05-22 at 14:08, Thomas Winischhofer wrote:
> I would like to reserve ioctl's 0xF3 00-40 for the SiS framebuffer 
> device driver (2.4 and 2.6).
> 
> Any oppositions?

well you don't say what you want to use it for.... so nobody can see if
those ioctls should become generic, if they are 32/64 bit safe etc etc.
Might be a good idea to post the ioctl interface to the list as well.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ioctl number 0xF3

[Thomas Winischhofer]

Arjan van de Ven wrote:
> On Sat, 2004-05-22 at 14:08, Thomas Winischhofer wrote:
> 
>>I would like to reserve ioctl's 0xF3 00-40 for the SiS framebuffer 
>>device driver (2.4 and 2.6).
>>
>>Any oppositions?
> 
> 
> well you don't say what you want to use it for.... so nobody can see if
> those ioctls should become generic, if they are 32/64 bit safe etc etc.
> Might be a good idea to post the ioctl interface to the list as well.

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. The goal is to be able to write a 
program similar to what sisctrl is for X (see my website for details on 
sisctrl).

I have no list yet as I first wanted to know if somebody opposes for 
reasons like 0xf3/0x0-0x40 being used by another driver already. I 
quickly grep-ed but found none.

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).

Thomas

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

Re: ioctl number 0xF3

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

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?

> 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 ?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ioctl number 0xF3

[Thomas Winischhofer]

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

Re: ioctl number 0xF3

[Francois Romieu]

Thomas Winischhofer <thomas@winischhofer.net> :
[...]
> Don't get me wrong.. did you ever write a driver for graphics hardware? 

He can surely tell when an egg stinks. However Arjan is not a chicken.

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

Reserving a generous ioctl range without any clear interface will make
some people nervous. If you can not specify the interface now, try to
separate the generic/specific part of it and use sub-ioctl for the really
scary things as it will make the future life easier.

If you have some pointers to the existing code, that may help too.

--
Ueimor

Re: ioctl number 0xF3

[Thomas Winischhofer]

Francois Romieu wrote:
 >He can surely tell when an egg stinks. However Arjan is not a chicken.

I didn't mean that as any sort of insult. I am just tired of the XFree86 
people telling me "implement a generic interface". I write one single 
driver and want the users of this driver to have some sort of comfort. 
Waiting until someone comes up with some generic solution (for a design 
of which I don't have time nor the required knowledge about a zillion 
different systems) I am old and grey.


> Thomas Winischhofer <thomas@winischhofer.net> :
>>Is 64 out of, what's that, 65536 too much to ask? Well, I could live 
>>with 32 as well...
>
> Reserving a generous ioctl range without any clear interface will make
> some people nervous. If you can not specify the interface now, try to
> separate the generic/specific part of it and use sub-ioctl for the really
> scary things as it will make the future life easier.
> 
> If you have some pointers to the existing code, that may help too.

Well, before I start implementing it (further), I thought it would be 
smart to be able to rely on certain things. As long as I don't even know 
if I get the numbers I don't write code... but frankly, the current 
development sisfb version available on my website has a very few of the 
intended ioctls already implemented.

The interface I intend to use matches the one the X driver has (using 
the Xv extension as an ioctl replacement) and will be documented. Since 
I develope both the SiS kernel framebuffer driver as well as the SiS X 
driver this will reduce duplicate code and ensures good cooperation. 
Furthermore, there could be a common library for both the framebuffer and X.

Hm. Were the matrox folks asked for a "clear interface" in advance when 
they started using the 'n' ioctls? Am I too polite? ;)

sisfb uses a few ioctls already, as an extension to the generic fb 
related ioctls. (Although the version currently in mainline 2.4 is not 
in any way 32/64 bit safe, and neiter is the mainline 2.6 version yet as 
regards the obviously required ioctl32 emulation stuff - investigating 
this at the moment).

Thomas

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

Re: ioctl number 0xF3

[Petr Vandrovec]

On Sat, May 22, 2004 at 05:37:57PM +0200, Thomas Winischhofer wrote:
> 
> Hm. Were the matrox folks asked for a "clear interface" in advance when 
> they started using the 'n' ioctls? Am I too polite? ;)

You are too polite. 

In the past ncpfs was using 'n' with 'all' subcodes assigned to it.
Back when I needed some numbers, I simple shrunk ncpfs to 0x00-0xDF, assigning
0xE0-0xFF to matroxfb (I maintain both, so it is simple...). It looks like that
someone visited ncpfs's assignment since then, as now ncpfs has only 0x00-0x7F
assigned to it (according to the ioctl-numbers; I have no idea who made this
0x80-0xDF hole in my nice range).

On other side, matroxfb uses standard VIDIOC_* v4l2 ioctls for exporting
TV-out's brightness/saturation/... to the userspace. And it causes neverending
pain. Currently Debian's /usr/include headers contain VIDIOC_S_CTRL
definition:

#define VIDIOC_S_CTRL           _IOW  ('V', 28, struct v4l2_control)

while kernel uses

#define VIDIOC_S_CTRL           _IOWR ('V', 28, struct v4l2_control)

and so no apps built with /usr/include headers on Debian do work on matroxfb's
(or anyone else's) v4l2 interface :-( Better to not give description of your ioctls to anyone,
or they'll "fix" them.
						Best regards,
							Petr Vandrovec
 

Re: ioctl number 0xF3

[Francois Romieu]

Thomas Winischhofer <thomas@winischhofer.net> :
[...]
> The interface I intend to use matches the one the X driver has (using 
> the Xv extension as an ioctl replacement) and will be documented. Since 
> I develope both the SiS kernel framebuffer driver as well as the SiS X 
> driver this will reduce duplicate code and ensures good cooperation. 
> Furthermore, there could be a common library for both the framebuffer and X.

As you apparently manage the utility, you are at the first place to handle
the incompatibilities as well. Fine :o)

> Hm. Were the matrox folks asked for a "clear interface" in advance when 
> they started using the 'n' ioctls? Am I too polite? ;)

Nonononono. It is just a bit optimistic to hope for an instant solution
here if there has not been one so far on the xfree/friends side. Imo
there are some grey areas:
- what does the common part need;
- who can/want/will do the dirty work.
Looking at the code, there is no instant answer and things won't be set
in stone today. The best you can do is to minimize the pain in the future:
use as few ioctls as possible so that you can control/verify the changes
of interface trough a single point and design this interface so that it
takes into account that things will change. No silver bullet.

[...]
> sisfb uses a few ioctls already, as an extension to the generic fb 
> related ioctls. (Although the version currently in mainline 2.4 is not 
> in any way 32/64 bit safe, and neiter is the mainline 2.6 version yet as 
> regards the obviously required ioctl32 emulation stuff - investigating 
> this at the moment).

Consider reusing these ? It may be a bit academic as you control the main
utility anyway.

--
Ueimor