Понадобились старые дрова xserver-xorg-video-all, из Debian Testing, для Xorg ABI 1.11 (Xorg 1.11.3.901 за 19 января 11 году)

Последний видимо был вот этот http://packages.qa.debian.org/x/xserver-xorg-video-vesa/news/20110627T163916Z...

Как его, и вообще, возможно ли найти старые версии testing пакетов.

С недавнего времени перестал работать git с kernel.org...

# export GIT_TRACE=1;
# git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
trace: built-in: git 'clone' 'git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git'
Cloning into 'linux-stable'...
trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 11942 on localhost'
trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 11942 on localhost'
trace: built-in: git 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 11942 on localhost'
remote: Counting objects: 2899206, done.
remote: Compressing objects: 100% (453229/453229), done.
remote: Total 2899206 (delta 2433956), reused 2882999 (delta 2418221)

На другой консоли

# ps ax | grep [g]it
16184 pts/1    S+     0:00 git pull
16185 pts/1    S+     0:00 /bin/sh /usr/lib/git-core/git-pull
16203 pts/1    Sl+    0:00 git fetch --update-head-ok
16662 pts/1    S+     0:01 git index-pack --stdin -v --fix-thin --keep=fetch-pack 16203 on localhost --pack_header=2,2899206

После выкачивания двух гигов, процесс «git index-pack» клинит. Обновления git ни из дистра, ни из последних исходников не помогло. 

Трейс процесса git index-pack

# strace -p 16662 
Process 16662 attached
read(0, 0x7672c0, 4096)                 = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn()                          = 0
read(0, 0x7672c0, 4096)                 = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn()                          = 0
read(0, 0x7672c0, 4096)                 = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn()                          = 0
read(0, 0x7672c0, 4096)                 = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn()                          = 0
read(0, 0x7672c0, 4096)                 = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn()                          = 0
read(0, 0x7672c0, 4096)                 = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn()                          = 0

Такой глюк возникает на проектах с большим количеством объектов,примерно от 20000 и дальше.
Ядро 3.2.35 и 3.7, кстати глюк появился ещё в октябре, лень писать было. :)
OpenSuSE 12.2
sysctl не трогал
на дисках места навалом
/tmp как tmpfs или xfs - пофиг, не забивается.
xfs, reiserfs3, ext2/3/4, btrfs, jfs - пофиг.
другая сетевуха - пофиг

Имеется веб-камера. Через венду и usbsnoop поймал нужные байты,
посылаемые вендовой програмкой...

Теперь проблема всунуть эти байты в Linux приложение,
желательно через V4L2 ioctl(fd, VIDIOC_S_CTRL, &ctrl); VIDIOC_S_CTRL - или другой
Или, как вариант, всунуть в драйвер uvcvideo.

С помощью libusb этот запрос выглядит так:

#define LED_ON «\x02\x00\0x01\0x00\0x00\0x00\0x00»
#define TYPE (USB_TYPE_CLASS | USB_RECIP_INTERFACE)

memcpy(buf, LED_ON, 0x7);
usb_control_msg(devh, TYPE, 1, 0x600, 0x400, buf, 0x7, 1000);
...

Сама ж..а - это 0x600 и 0x400. Как их всунуть в устройство через V4L API нипанятна...

---

В USB Device Class Definition for Video Devices написано:

2.3.6 Extension Unit
The Extension Unit (XU) is the method provided by this specification to add vendor-specific building blocks to the specification. The Extension Unit can have one or more Input Pins and has a single Output Pin. Although a generic host driver will not be able to determine what functionality is implemented in the Extension Unit, it shall report the presence of these extensions to vendor-supplied client software, and provide a method for sending control requests from the client software to the Unit, and receiving status from the unit.

--- Их есть у нас, аж две штуки

VideoControl Interface Descriptor:
bLength 26
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {7033f028-1163-2e4a-ba2c-6890eb334016}
bNumControl 8
bNrPins 1
baSourceID( 0) 3
bControlSize 1
bmControls( 0) 0x0f
iExtension 0
VideoControl Interface Descriptor:
bLength 26
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 5
guidExtensionCode {3fae1228-d7bc-114e-a357-6f1edef7d61d}
bNumControl 8
bNrPins 1
baSourceID( 0) 4
bControlSize 1
bmControls( 0) 0xff
iExtension 0

С помощью скрипта из libwebcam эти XU превращаются в ...

#ifndef UVC_GUID_USER_HW_CONTROL_ONE
#define UVC_GUID_USER_HW_CONTROL_ONE { \
0x28, 0xf0, 0x33, 0x70, 0x63, 0x11, 0x4a, 0x2e, \
0xba, 0x2c, 0x68, 0x90, 0xeb, 0x33, 0x40, 0x16 \
}

#endif

#ifndef UVC_GUID_LOGITECH_USER_HW_CONTROL_TWO
#define UVC_GUID_LOGITECH_USER_HW_CONTROL_TWO { \
0x28, 0x12, 0xae, 0x3f, 0xbc, 0xd7, 0x4e, 0x11, \
0xa3, 0x57, 0x6f, 0x1e, 0xde, 0xf7, 0xd6, 0x1d \
}

Как их запихнуть в камеру, тоже непанятна...