Messages in this thread | | | Date | Sun, 23 May 2004 03:35:37 +0200 | From | Petr Vandrovec <> | Subject | Re: 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 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |