gspca1 freezing when device in use is removed.

Cláudio da Silveira Pinheiro taupter at gmail.com
Mon Nov 5 20:45:15 CET 2007


Em Seg 05 Nov 2007, você escreveu:
> Le Lundi 5 Novembre 2007 04:51, vous avez écrit :
> Claudio,
>
> > Hello,
> >
> >
> > I'm having a problem with the gspca driver. If a program is accessing an
> > usb webcam supported by the gspca driver and meanwhile the webcam is
> > removed, the program freezes.
>
> the program need to close the video node if nothing happen after some times

The program is unable to do so because it freezes, not returning from the 
ioctl call.

> > It's a problem because I cannot get around the freeze in a sane way.
> > Other drivers, as the uvc, return an EINVAL (22), allowing a program(mer)
> > to take the proper measures to handle the error.
>
> The best way seem to start a thread in user space and close the webcam node
> after sometimes if somethings goes wrong.

Doing so in a sane way is not feasible, because it will head the 
multithreading program to memory leaks and instability. The frozen capture 
thread will have to be killed by force, and it will put memory allocated by 
the thread in the memory leak limbo, buffer pointers will go berserk and it 
will meed a mutex hell to avoid race conditions. It would be a beast to 
develop/debug/maintain, akin to making a roller coaster full of loops just to 
cross a street.
A cleaner way imho would be to make gspca1's ioctls return an EINVAL error 
instead of block and freeze. Return values are made to allow programs react 
according to the results of some procedure. If such procedure doesn't even 
return at all it becomes very difficult to the program to recover itself.
gspca1, as a kernel module, is currently unable to handle the disconnection of 
a device in use. Other modules, uvc as an example, can handle it just fine 
and return EINVAL when called. I just can't see the logic of writing a 
multithreaded workaround in userspace if we can fix it in gspca1 where the 
bug really is.
Mr. Santovito seems to be trying to fix this issue. I'd ask you to add his 
workaround to gspca1's codebase as soon as it's stable enough for general 
use.
I'd like to thank you for enabling som many webcam users to enjoy their 
devices in Linux, and ask you how's the current status of v4l2 support. Some 
projects, such as Kopete, have to maintain a v4l compatibility layer just to 
handle gspca1, and removing such redundant code is in our project goals. One 
good way to do so would be making the gspca support v4l2 calls, and some 
developers (me and Lúcio included) would be very pleased to help you in such 
a task.

> > KDE4 uses Solid, a device discovery with hotplugging support that, in
> > Linux, uses hal to do it's job. Currently it detects the present v4l/v4l2
> > devices, and issues alerts when devices are connected/disconnected.
> > If a device is disconnected while in use, it doesn't issue an alert until
> > the device's file handle is closed, by means of a close() call of killing
> > the program (as it closes program's all open files). So a program should
> > get an error condition to be able to detect the device was disconnected,
> > then close the file handle and handle gracefuly the disconnection, and
> > hal would update its info about connected devices. It's how it works with
> > uvc drivers. But with gspca driver, it blocks when the device is no
> > longer present, freezing the application, so it's unable to close the
> > file handle, and hal will not be updated until we kill the frozen process
> > by hand. I cannot see any easy (or at least feasibly) way around this
> > problem, so I'm asking for your help.
> > Kopete is the KDE dafault IM program, and thousands of people use it
> > daily. Finding a way to resolve this issue (maybe making gspca return an
> > EINVAL when it can no longer access the device instead of blocking - it
> > doesn't recover when you plug the device again) would benefit not only
> > those users, but all Linux users who rely on hal. It would open a way to
> > fix long time old bugs about programs not handling device disconnection,
> > and allow us all to present a better experience to our (gspca, KDE and
> > Linux in general) userbase.
> >
> >
> > Thanks in advance,
> >
> >
> > Cláudio da Silveira Pinheiro
> > KDE/Kopete developer
> > http://kopete.kde.org
> > +55(85)8702-0060




More information about the Phonon-backends mailing list