[lkml]   [2004]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ioctl number 0xF3
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

#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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:03    [W:0.058 / U:0.072 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site