[Spca50x-devs] gspca1 freezing when device in use is removed.
- Date: Mon, 5 Nov 2007 16:45:15 -0300
- From: Cláudio da Silveira Pinheiro <taupter@xxxxxxxxx>
- Subject: [Spca50x-devs] gspca1 freezing when device in use is removed.
Em Seg 05 Nov 2007, você escreveu:
> Le Lundi 5 Novembre 2007 04:51, vous avez écrit :
> > 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
> > 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
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
> > 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
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Spca50x-devs mailing list